Why partner routes are separated
Agencies, consultancies, managed service providers, software vendors and recruiters all bring specialists into client work, but they buy differently. An agency has a signed client requirement and needs delivery capacity inside it. An MSP has a recurring service relationship and needs something it can offer repeatedly. A software vendor needs its own product deployed successfully at customer sites. A recruiter has an approved vacancy and needs a fast fit check.
Each needs a different agreement about who owns the client, who contracts, who delivers and how money moves. Treating them as one “partner programme” blurs exactly the accountability these arrangements depend on. So each route has its own page:
- Agencies and consultancies: transparent co-delivery on a client engagement you hold, with a responsibility matrix and specialist approval process.
- Managed service providers: a jointly owned AI adoption service you can offer clients after the licence sale.
- Software vendors: named support for customer deployments of your AI product, with product gaps reported back to you rather than hidden.
- Recruitment agencies and contract desks: a direct route for an approved contract role, with a capability pack and role intake rather than a consulting sales process.
The principles on every route
Disclosed by name. The end client knows I am doing the work and has agreed to it. This is co-delivery, not white-label staffing.
Client ownership written down. Before work starts, we record who owns the client relationship, who sets priorities, who accepts deliverables and who handles commercial conversations. Usually that is you, and I stay out of commercial discussions with your client unless you ask me in.
One contracting chain. I contract with one party, normally you, and your client’s terms on confidentiality, IP and data flow down through that contract. The chain is stated, not implied.
Specialists approved in advance. If another specialist would help, they are named, their role and basis are described, and they start only after written approval. There is no bench of interchangeable engineers behind any of these routes.
Payment follows the contract. The engagement is priced on the contract day rate or as scoped delivery, invoiced to whoever I contract with, on terms agreed in writing before work starts. The engagement models page sets out how each model is scoped and paid.
Capacity checked per brief. I work personally, so capacity is limited and is confirmed against each specific brief before anything is committed.
What I bring
I have worked as a principal architect inside a regulated UK fintech and in hands-on AI engineering leadership roles, and I have written about forward-deployed engineering: building AI systems that survive contact with a real organisation. That is the role in partner work: the person who makes the AI part of your engagement actually work in production, inside your delivery.
Next steps
Pick the route above that matches how you sell and send a short brief. For contracting details your procurement team will ask about, see procurement and supplier information. For how engagements are scoped and paid, see engagement models.