Partners · Agencies and consultancies

Senior AI delivery inside your client engagement, with accountability split on paper

If your agency or consultancy has won, or is close to winning, an AI requirement and lacks senior implementation capacity, I join the engagement as a disclosed subcontractor. Before work starts we agree a responsibility matrix, a client-facing scope with acceptance criteria, and a specialist approval process. You keep the client relationship and commercial lead; I own the AI technical work assigned to me.

This is a good fit if…

  • You have a signed statement of work, or a near-final proposal, that includes AI implementation such as retrieval, agents, workflow automation or evaluation.
  • Your team covers strategy, design or software delivery, but nobody has taken an AI system to production.
  • You need someone who can sit in client workshops and speak honestly about technical risk and feasibility.
  • You want your own engineers to build AI capability during the engagement, not rent it indefinitely.

Look elsewhere if…

  • You want staff supplied under your brand without the client knowing. I do not do white-label work.
  • You have a single contract vacancy to fill. Use the recruitment agencies route instead.
  • Your clients need a repeatable adoption service bundled with their licences. Use the MSP route instead.

What you get

Co-delivery responsibility matrix, client-facing scope and specialist approval process

  • A co-delivery responsibility matrix your client has seen, covering relationship, scope, architecture, delivery, data access, acceptance and handover.
  • A client-facing scope with acceptance criteria that both you and I can stand behind.
  • A written specialist approval process, so nobody joins the engagement unannounced.
  • The AI work delivered through your engagement governance and your client's review process.
  • Handover to your client's owner, with your team able to support and extend what was built.

How it runs

  1. 01

    Requirement review

    Under NDA, I review the client requirement, proposal or statement of work and tell you plainly what is feasible, what is risky and what I would change before you commit.

  2. 02

    Responsibility matrix and scope

    We agree who owns each part of the engagement, and I draft the AI technical scope and acceptance criteria for you to put in front of the client.

  3. 03

    Client introduction

    You introduce me to the client by name and role. The client approves the subcontracting arrangement and the scope before delivery starts.

  4. 04

    Delivery and handover

    I deliver inside your engagement governance, reporting to your engagement lead, and hand over to the client's owner with your team alongside.

What needs to be in place

  • A signed or near-final client requirement that includes AI work.
  • A named engagement lead at your firm with authority over scope and client communication.
  • Your client's consent to a named subcontractor, and the confidentiality, IP and data terms that must flow down.
  • Payment terms between us agreed in writing before work starts.

Not included

  • White-label or undisclosed delivery.
  • Commitments to your client on AI scope, timing or outcomes that I have not reviewed.
  • Supplying other engineers as a staffing service.
  • Account management or commercial negotiation with your client, unless you ask me in.
  • Guaranteed accuracy, adoption or business outcomes.

The situation

Digital agencies and consultancies are increasingly winning work that includes AI: a knowledge assistant inside a client portal, an automated document workflow, an agent that handles part of a service process. The proposal was written by people who understand the client’s business. The delivery needs someone who has taken an AI system into production and knows where it fails.

Hiring for that takes months, and the work cannot wait. The usual alternatives each carry a risk: a white-label subcontractor the client never meets, a staffing supplier who swaps engineers mid-engagement, or the existing team learning on the client’s time. The question is how to bring senior AI delivery into the engagement while keeping accountability clear, to you and to the client.

How the co-delivery works

Who owns the client. You do. You lead the relationship, the commercial conversation and the engagement governance. I do not discuss commercial terms with your client unless you ask me to.

Who contracts. You contract with your client; I contract with you as a disclosed subcontractor. Your client’s terms on confidentiality, IP, data protection and security flow down to me through our agreement.

Who delivers. Your team delivers the engagement. I deliver the AI technical work assigned to me in the responsibility matrix, such as retrieval design, agent controls, evaluation and integration, through your client’s review and change processes. Your engineers pair with me so the capability stays with your firm.

How specialists are approved. If another specialist would help, for example a security reviewer for a penetration test or a data engineer for a large migration, I name them, describe their role and basis, and they start only after you and the client have approved in writing. They appear in the responsibility matrix like everyone else. There is no bench of unnamed engineers behind this.

How payment works. I invoice you, on the contract day rate or as scoped delivery with milestones tied to deliverables, on terms agreed in writing before work starts. You invoice your client on your own terms. Expenses are pre-approved.

The signature deliverable, illustrated

The responsibility matrix is the document everyone signs up to. Illustrative example, not taken from a client engagement:

AreaAgencyDipankarClient
Client relationship and commercial termsOwnsInformed—
Scope and acceptance criteriaOwns and agrees with clientDrafts AI technical scopeApproves
AI architecture decisionsConsultedOwns, within agreed scopeApproves where it affects their systems
ImplementationOwns non-AI workOwns assigned AI workReviews through their process
Data access approvalsRequestsUses only as approvedOwns
Specialist approvalApprovesProposes, by nameApproves
HandoverCoordinatesDelivers technical handoverNames the internal owner

The client-facing scope that accompanies it states the AI deliverables, acceptance tests, data the work depends on, exclusions and the change process.

How acceptance is judged

The client accepts against the criteria in the client-facing scope, through your engagement governance. For AI work that usually means an evaluation run on an agreed set of cases, controls demonstrated live, and documentation handed to the named owner. You accept my work against the same criteria, so there is one definition of done.

Ownership and handover

The delivered system belongs to the client as your contract specifies. Technical handover goes to the client’s named owner with your team present, so you can offer continuing support if the client wants it. My involvement ends at handover unless you extend it.

When to choose something else

If you are filling a single contract role, the recruitment agencies route is faster. If you are an MSP wanting a repeatable adoption service, see AI enablement partner for MSPs. To draft the client-facing scope, the project scope and acceptance template helps. All partner routes are compared on the partners overview.

Questions buyers ask

Why not white-label?

Because AI work raises questions that need a named, accountable answer: how client data is used, why a model behaves as it does, who decided an acceptance threshold. If the client does not know who did the work, those questions land on your engagement lead with no direct route to the person who can answer them. Disclosure protects your relationship with the client.

How is it priced and paid?

On the contract day rate for capacity inside your engagement, or as scoped delivery with milestones where the AI work is a distinct deliverable. I invoice you; you invoice your client on your own terms. Payment terms between us are agreed in writing, and any dependency on your client paying you is discussed explicitly, not assumed.

What happens if the client changes scope?

Changes go through your engagement's change process. I tell you the technical and effort consequences, you agree the change with the client, and our scope is updated in writing before the changed work starts. That keeps your client-facing scope and our subcontract aligned, so acceptance never depends on an informal promise made in a meeting.

Can you help us win the work?

Yes, within limits. I can review the AI part of a proposal for feasibility and risk, and join a client conversation as the named technical lead. I will not put my name to commitments I think are unrealistic, and capacity for any resulting work is confirmed before you submit.

Who owns the IP?

It follows your client contract. Normally, deliverables created for the engagement pass to the client as your contract specifies, and my pre-existing tools and know-how remain mine, licensed for use where needed. We write the position down in our subcontract so it matches what you have promised the client.

Discuss a delivery partnership

A short, non-confidential description is enough to start. I read every brief personally and reply within two business days, including when the answer is that I am not the right fit.

Step 1 of 2 · The basics