Embedded AI Delivery Team vs Project Consulting: UK Guide

A transformation lead with one AI use case in production can buy delivery the way most firms buy any change: scope a project, run it, close it. The trouble starts at the third or fourth placement. Each project team leaves at go-live, each leaves a slightly different evaluation set-up behind, and the people who understood why the system behaves the way it does are on another client's programme by the time it drifts. The AI delivery problem stops being a build problem and becomes an ownership problem.

The pattern shows up in the research. MIT NANDA's State of AI in Business 2025, reported by Fortune in August 2025, found that 95% of companies in its dataset were falling short on generative AI implementation, with most pilots delivering little to no measurable impact on profit and loss. McKinsey's State of AI (November 2025) finds 88% of organisations using AI in at least one business function, yet only 33% have AI in production and about 6% are AI-mature enough to capture material EBIT impact. The gap between using AI and running it is where the delivery model matters.

This guide is about one decision inside that gap: whether to keep buying AI delivery as a series of one-off consulting projects, or to stand up an embedded delivery team that builds alongside your people and then hands the capability over. It is written for the transformation lead weighing internal build capacity against a retained partner. It deliberately cedes the general pilot-to-production method to our enterprise AI consulting guide, the voice-specific build-versus-vendor question to the in-house versus vendor operating model comparison, and the run-team RACI to the voice AI delivery team roles guide. It contains no fee figures, because the decision turns on ownership, not on a rate card.

This guide is shipped by the team behind DATS, the five-stage AI consulting system from DILR.AI, delivered by senior practitioners who ship code, not decks. Or see AI operating model design, which sets the governance, RACI and lifecycle a delivery team works inside.

What is the difference between an embedded AI delivery team and project consulting?

An embedded AI delivery team works inside the client organisation over a long engagement, building production AI placements alongside internal staff and transferring the capability as it goes. Project consulting buys a defined deliverable over a fixed period, after which the supplier leaves. The difference is not duration alone: it is who holds the knowledge to run, change and switch off the system once the engagement ends.

The UK government's Consultancy Playbook, published by the Cabinet Office and the Government Commercial Function on 5 September 2022, draws a line that is worth writing into any private-sector AI contract. Its Table 1 separates consultancy, where skills are not available in-house, the engagement is time-limited and the supplier is responsible for defined deliverables or outcomes, from contingent labour, where the role already exists in the organisation, named individuals perform it and the client keeps day-to-day management. The Playbook was written for central government departments, but the distinction transfers cleanly to an enterprise AI programme, and it helps locate a third model, our own construct rather than the Playbook's, that sits between the two.

The table is the whole argument in miniature. A project buys capability and takes it away again. Contingent labour buys capacity and leaves the capability question unanswered. An embedded team is only worth its longer commitment if it is built, from the first week, to end with the capability inside your team. That design choice is what the AI execution office model exists to make explicit, and it is why the operating model has to come first: a team cannot hand over ownership of a system nobody has been named to own.

Why do one-off AI projects stall once a business runs several production use cases?

One-off AI projects stall at scale because an AI system is not finished at go-live. Evaluation sets age, model behaviour drifts, upstream data changes and regulators ask new questions, so each production placement needs a standing owner with the context to respond. A series of separately scoped projects hands that context back to the supplier at every close, leaving the client with systems it runs but does not fully understand.

The MIT NANDA research is specific about where the failure sits. Fortune's account of the report puts the core issue down to a "learning gap" for both tools and organisations, and says the research points to flawed enterprise integration rather than the quality of the models. The study was based on 150 interviews with leaders, a survey of 350 employees and an analysis of 300 public AI deployments, and it found only about 5% of AI pilot programmes achieving rapid revenue acceleration. Fortune's account describes generic tools that do not learn from or adapt to workflows. In our reading, a delivery model that ends at go-live has a similar weakness at the organisational level, because much of what a team learns about a live system arrives after launch.

The AI Playbook for the UK Government, published on 10 February 2025, makes the same point as a principle. Principle 5 asks teams to understand how to manage the full AI life cycle, and Principle 9 asks them to have the skills and expertise needed to implement and use AI solutions, including the skills to use, design, build and maintain them. Maintenance is in that list for a reason. Projects price the build; the life cycle is what is left on your books.

There is also a compounding cost that does not show up in any single statement of work. When the third placement is built by a different team from the first, it rarely reuses the first placement's evaluation harness, logging conventions or governance board. Each project reinvents its own chassis. We see the voice version of this in AI voice pilot purgatory, where programmes stall between demo and decision, and the cure is the same in every channel: shared infrastructure owned by someone who will still be there next year. Among the six enterprise AI solutions we have named are evaluation and observability for production agents and AI cost control, both problems that only exist once something is running.

How do you tell a capability gap from a capacity gap in AI delivery?

A capability gap means your organisation does not yet know how to do the work, for example designing an evaluation harness for a regulated agent. A capacity gap means you know how but lack the hours. The two are easy to confuse, and the Consultancy Playbook's answer is direct: consultants for capability, contingent labour for capacity, with the knowledge transfer planned either way.

The Playbook puts it in one sentence that every AI sourcing decision should be tested against. On its guidance for umbrella contracts and delivery partner arrangements, it says that "external consultants should be used to fill specific capability gaps, rather than capacity shortages, which are better suited to contingent labour" (Consultancy Playbook, Version 1.1, September 2022). It adds that consultancy engagements should be time-limited with clearly defined deliverables and outputs, and that lotting large requirements helps avoid over-reliance on one firm. A long embedded engagement is consistent with that guidance only if it is still bounded: defined placements, a defined end state and a dated exit, rather than an open-ended call-off.

Applied to AI, the test produces three honest answers rather than one:

• You lack capability and will keep needing it. You have no one who has run an AI system through a model change, an incident and an audit. This is the case for an embedded team whose explicit job is to build that capability inside your organisation and leave.
• You lack capability once. A single, bounded build with a clear end state, such as a document-classification model that will rarely change. A well-scoped project is cheaper and simpler.
• You lack capacity only. Your engineers know how to do the work and simply have too much of it. Contractors or a contingent workforce fit, and paying a consultancy for capability you already have is an avoidable waste.

The same diagnostic logic underpins our AI placement work under DATS, which ranks where AI belongs before any delivery model is chosen, so the sourcing question is asked about a specific placement rather than about "AI" in general.

When does an embedded AI delivery team beat a series of consulting projects?

An embedded AI delivery team beats a run of consulting projects when the organisation expects several production placements that should share one evaluation, governance and operations chassis, when the systems will keep changing after launch, and when the business intends to own the capability rather than rent it indefinitely. With one bounded use case and no plan to build more, a project is usually the better buy.

Five conditions make the case in practice. Each is observable before you sign anything:

1. More than one placement on the roadmap. The second and third placements are where a shared chassis pays back, because they reuse the first one's evaluation harness, incident tooling and sign-off route instead of rebuilding them.
2. Systems that will change. Agents connected to live policy, pricing or product data change whenever that data does. Someone has to own the regression suite that proves each change is safe.
3. A regulatory evidence burden. Where an auditor, or a regulator such as the FCA or the ICO, can ask how a decision was reached, the evidence has to be produced by the running system, not reconstructed by a departed supplier.
4. A hiring market you cannot win alone. If you cannot hire the senior AI engineers you need in the time you have, pairing your existing engineers with practitioners who have shipped production AI is a faster route to the same capability.
5. A sponsor who will own the outcome. An embedded team without a client-side owner becomes an expensive outsourced function. The AI operating model names that owner before the team arrives.

The partnership evidence leans the same way. According to the MIT NANDA findings as reported by Fortune, purchasing AI tools from specialised vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often. The finding is about buying tools and forming partnerships, not embedded consulting teams as such, so treat it as directional rather than direct evidence. Read that way, it is not an argument for permanent dependence on a partner. It is an argument for a partnership whose end state is your own team running the system, which is exactly the end state a one-off project cannot reach and a pure internal build reaches slowly. The same report found more than half of generative AI budgets going to sales and marketing tools, while the biggest returns sat in back-office automation, which is where a long-lived placement with a named owner tends to land.

The conditions also tell you when not to embed. A firm with one use case, stable data and a strong internal engineering bench should buy a scoped project, or build it, and spend the difference elsewhere. Our approach to placing AI starts from that honesty: proving where AI belongs before choosing who builds it.

What should knowledge transfer look like inside an embedded AI team?

Knowledge transfer inside an embedded AI team should run from the first sprint, not arrive as a handover pack in the final month. Client engineers pair on the build, run the evaluation harness themselves, take shifts on incident response and gradually lead changes while the embedded practitioners review. The UK government's own guidance finds blended teams significantly increase the effectiveness of transfer, and that it must happen throughout.

That guidance is the government's Knowledge and Skills: Generation, Transfer and Sharing note, dated September 2022, which builds on chapter three of the Playbook. It defines knowledge transfer as turning the knowledge inside people's heads into content, tools and processes that others can use, or passing it person to person. It states that working as part of a blended team with consultants significantly increases the effectiveness of knowledge and skills transfer, and that transfer should not be treated as something that happens only at the end of the project life cycle.

Two of the note's transfer options map most directly onto concrete AI artefacts:

• Codified knowledge. The note lists methodology, tools, manuals, handover notes and process maps. In AI delivery these are the evaluation harness in your repository, the runbook for a model change, the incident playbook, the decision log and the prompt and retrieval configuration under version control.
• Learning from others. The note lists mentoring, shadowing, coaching and on-the-job learning. In AI delivery this is pair-building the first placement, your engineer leading the second with review, and your team taking the on-call rotation before the embedded practitioners step back.

The ownership side of this is where AI differs from ordinary software. An agent that acts on its own needs someone who can show what it did and why. For agent work, Cognibl, from DILR.AI is our work management line, and the wider discipline is set out in our AI agent work management guide. Onboarding the people who will inherit a live system is its own craft, which the voice AI run team onboarding guide covers for one channel.

What contract and IR35 questions does an embedded AI team raise?

An embedded AI team raises three contract questions a project rarely does: whether the supplier is accountable for outcomes or simply supplying named people, who owns the code, prompts and evaluation assets built inside your stack, and how exit and handover will be proven. Where contractors work through their own limited companies, the UK off-payroll working rules, known as IR35, also decide who must assess their employment status for tax.

Start with what you are actually buying. The Consultancy Playbook's distinction matters commercially as well as operationally: if the contract describes named individuals performing roles under your day-to-day direction, it reads like contingent labour, whatever it is called. If it describes deliverables, a supplier-led team and a defined end state, it reads like a managed engagement. An embedded AI team should be the second, with the transfer of capability written into the deliverables.

Then settle tax status where it applies. HMRC's guidance on understanding off-payroll working records that the rules changed from 6 April 2021. Where they apply, the client is in most cases responsible for determining the worker's employment status for tax and should produce a status determination statement; for a small client outside the public sector, the worker's own intermediary decides. The rules apply only where a worker provides services through their own intermediary, and agencies and other suppliers in the chain carry some responsibilities too, so a team supplied by a consultancy needs the same question asked of its supply chain. This is a reason to know which model you are buying before procurement, not legal advice, and your own advisers should confirm the position for any contract.

Finally, write the exit into the contract on day one. The Playbook's manage stage includes a plan for contract exit and handover of deliverables, and the AI Playbook's Principle 8 asks teams to work with commercial colleagues from the start. For AI, the exit clauses that matter are concrete:

• Intellectual property. Code, prompts, evaluation sets and runbooks built in your environment are yours and live in your repositories.
• Evidence of handover. The client team runs a model change, an incident and a release without the supplier, and that is recorded.
• No hidden dependencies. No production path relies on a supplier-held account, credential or private tool.

Our AI execution office is built on this shape: embedded delivery, with production placements the client owns.

How do you measure whether an embedded AI team is making itself unnecessary?

You measure an embedded AI team by how much of the running system your own staff now operate unaided: the share of changes merged by client engineers, the share of incidents resolved without supplier help, ownership of the evaluation harness and the on-call rotation. The right trend is downward supplier involvement over the engagement. Delivery velocity alone measures the supplier, not the capability you are buying.

The Knowledge and Skills note offers the simplest form of this test. Where internal team members are being coached during an assignment, it suggests that tracking the number of issues they are able to resolve, or tasks they can now complete, can be useful. Translated into an AI placement, that becomes a short scorecard reviewed at every quarterly checkpoint:

A team that is still indispensable at the end has delivered systems but not capability. That is a fair test to hold any embedded supplier to, including us, and it is why DATS states a delivery discipline of three shippable placements a year with a named owner per ship, a focus commitment rather than a contractual limit. The run-team roles behind a scorecard like this are mapped for one channel in the voice delivery team roles guide linked in the introduction.

What is the best way to buy AI delivery capacity in the UK in 2026?

The best way to buy AI delivery in the UK in 2026 depends on the gap. For a bounded, one-time build, a scoped project from a specialist or a large consultancy is right. For pure capacity, contractors or a contingent workforce fit. For a multi-placement programme you intend to own, an embedded senior team with capability transfer written into the contract usually wins, provided a client-side owner exists.

The criteria that separate suppliers are the same whichever model you choose: whether the people who scope the work are the people who build it, whether evaluation and governance are delivered as running systems rather than documents, whether knowledge transfer has deliverables and measures, and whether exit is defined before the start. In our assessment, large firms such as Accenture, Deloitte and PwC win where a programme needs a large team across many countries, a single global contract or deep systems integration across an ERP estate; a small embedded team cannot match that breadth, and buyers in that position should not pretend otherwise. UK digital delivery firms such as Kainos and Made Tech are also worth shortlisting where public-sector delivery standards and larger engineering teams matter. Contractor-led teams win on flexibility when the capability already exists in-house.

Where DATS fits is narrower and stated plainly. DATS runs three productised engagements: a four to six week placement diagnostic, operating model design over six to ten weeks, and a twelve-month-plus execution office, which is embedded delivery with production placements the client owns. It is delivered by senior practitioners who ship code, not decks. For a single placement with no plan to scale, we would point you to a scoped project instead. The wider comparison of UK consultancies sits in our UK AI consulting guide, and the build, orchestrate or buy choice for one channel is covered in voice AI build versus orchestrate versus buy. Regulated buyers can see the same evidence-first method applied to a specific cost line in our analysis of KYC review cost in UK banks.

Is an embedded AI delivery team the same as staff augmentation?

An embedded AI delivery team is not the same as staff augmentation. Staff augmentation supplies named people to fill roles under the client's day-to-day direction, which the Consultancy Playbook classes as contingent labour for capacity gaps. An embedded team is accountable for delivering production placements and for transferring the capability to run them, so its success is best measured by how little the client needs it at the end.

If a proposal you receive describes rates per person and leaves the end state undefined, it is staff augmentation, whatever the label says. That can be the right buy for capacity. It is the wrong buy for capability. Our strategy articles cover the operating decisions around it in more depth.

How long should an embedded AI delivery team stay?

An embedded AI delivery team should stay until a named client owner and their engineers can run, change and switch off each production placement without supplier help, and no longer. In practice that means at least one full cycle of build, evaluation, production and handover. DATS structures its execution office as a twelve-month-plus engagement, and in our view a placement's first year is when most of the drift and incident learning happens.

Longer engagements should add placements, not prolong dependence on the first one. If the first placement still needs the supplier to stay alive after a year, treat that as a finding about the engagement, not as a reason to renew. You can talk to the operators about how a graduation plan would apply to your roadmap, or read about DILR.AI and the team behind it.

Want to see this in production? Explore our DATS methodology, see the six productised AI solutions, see Dilr Voice, our voice AI platform, or read about our approach to placing AI inside enterprise systems.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.