Executive summary & recap:

In Part 1, we showed how enterprise AI stalls at 14% adoption when bought like SaaS. In Part 2, we mapped the four capabilities of the Deployment Layer (Deploy, Ground, Adopt, Build) and demonstrated why grounding must precede training. In Part 3, we present the operational structure required to make it stick: embedded squads pairing strategists and engineers, the chaos that emerges without them, and the real-world proof from Chancerygate.

If the deployment layer is built by people rather than bought as a product, the question becomes which people, organised how. My answer borrows deliberately from how the labs themselves work with their largest customers, and it is an answer most consulting firms, including mine until recently, were not structured to give: small teams, embedded, accountable for an outcome rather than a deliverable. Three verbs describe it.

Embed

Pair a forward deployed strategist with a forward deployed engineer and put both inside the client, physically where possible, for the duration.

  • The strategist owns the business outcome and the operating model: which processes, which departments first, which of the eighty use cases make the year-one roadmap, how the AI Office is staffed, how value is measured and reported to the executive committee.
  • The engineer owns the platform, the context layer and the agents: the MCP server and its connectors, the permission model, the agent framework, the integration with whatever the client already runs.

A typical week has the strategist in the Finance director’s office in the morning and the engineer pairing with the client’s data team in the afternoon, and both of them in the same stand-up. Neither works from a slide deck, and neither is allowed to leave a recommendation behind as the deliverable. The deliverable is the thing working.

I am convinced the pairing matters more than the seniority. A strategist alone produces a roadmap that waits for IT. An engineer alone produces a platform that waits for the business. Together they produce a Monday-morning habit.

Train

Adoption is run department by department, on live data, and it is handed over rather than delivered. Three roles make it stick:

  1. AI Champions in each business area, chosen for curiosity rather than title, who run weekly office hours, collect the questions people could not get the tool to answer, and feed the next use cases back to the squad.
  2. An AI Office at the centre with four functions: leadership and governance, which owns the portfolio and the licences; a use-case squad that builds; a platform team that runs the context layer, security and the core tools; and an adoption function, working with HR, that owns training and change.
  3. Engineering Enablement for technical teams on Claude Code and Codex — hackathons, office hours, a governance workstream for access and cost — measured in daily sessions per developer rather than in seats.

The test I apply is simple: if the forward-deployed team disappeared tomorrow, would usage keep rising? If not, nothing has been adopted yet.

Build

Agents ship in two-week sprints. Day one is a hands-on “how to build an agent” workshop with the people who own the process, so that by lunchtime the accounts payable clerk has seen an invoice turned into structured fields and knows what the agent will and will not do. The rest of the sprint is build, test and iterate against real documents, with a demo to the business on the last day.

Each agent leaves with a reusable framework — in a Microsoft shop, typically Power Automate flows that ingest the documents and call the Claude API with the schema and the reference material, returning a structured dossier for human review — plus prompt templates, short videos, a named business owner, a test user and a maintainer who shadowed the build.

The measure of success is not the four agents we ship. It is the twenty the client builds afterwards without us. If that number is zero, we built a dependency, not a capability.

Running through all three is the relationship with the labs. I think the deployment layer only works when the people building it can see the roadmap six months out, can escalate directly to the lab’s solutions team when a connector misbehaves, and can put the lab’s engineers in the same room as the client’s executives and builders. That proximity is not a commercial nicety. It is what lets a deployment absorb MCP, Skills, Cowork or Codex the month they ship rather than the year after.

What could go wrong without it?

Picture the same CIO eighteen months from now, having renewed the seats and skipped the deployment layer.

The seat count has grown to three thousand; the active-user rate has not moved. The employees who wanted more have quietly moved their real work to personal accounts, where the company’s draft contracts, customer lists and next year’s forecast now live in chat histories nobody governs and nobody can delete. Three departments have each bought a point solution with its own embedded model, its own connectors and its own permissions — one for contract review, one for customer service, one for procurement — none of which agree on what a customer or a margin is, and each of which now needs its own security review.

A handful of enthusiasts have built agents on their own, in a no-code tool, over a weekend. Some are good. None has an owner, a test user or a log, and one of them has been sending supplier payment reminders with last year’s bank details. The security team, called in late and shown a landscape it did not design, responds the only way it can: by locking everything down, which sends the enthusiasts back to their personal accounts and the organisation back to the start.

The lab’s account team sees a customer with flat usage, no reference story and no technical counterpart to talk to, and allocates its scarce solutions engineers to someone else. The organisation has paid for the frontier and received a chatbot.

I want to be precise about the blame here, because it is usually misplaced. None of this is a failure of the technology, and very little of it is a failure of the employees. It is the predictable result of treating a capability as a procurement, and of nobody being accountable for the distance between a licence and a habit.

What we have decided to do about it

I will end with what this conviction has meant in practice, because an opinion that does not change how you organise is just commentary.
At Artefact we have stopped treating deployment as a phase at the end of a strategy engagement and made it a discipline with its own team. We call it DeployCo: forward-deployed engineers and strategists whose only job is the deployment layer, working with Anthropic and OpenAI, organised by lab and by region across Europe, the Middle East and Africa, each region with a business lead and a technical lead for each lab. We intend to be a hundred of them by 2027. That is a bet, and I am comfortable stating it publicly because I think the alternative — selling strategy and leaving the plumbing to someone else — is how the industry got to 14%.

The bet rests on a few positions I hold firmly:

  • That grounding comes before training, always, and that a training session without the client’s own data in it is theatre.
  • That an agent without a named owner and a maintainer is a liability, not an asset, however clever it is.
  • That the client’s team must out-build ours within a quarter, or we have failed.
  • And that the people doing this work need to sit close enough to the labs to see what is coming, which is why we spend our time in rooms with them — in October alone in Munich, Zurich and Casablanca, with client executives and their builders on one side of the table and the Anthropic and OpenAI teams on the other, working through real deployments rather than listening to keynotes.

Chancerygate, a London industrial developer and asset manager with around 700 tenants and some £1.2 billion under management, is the clearest evidence I have that the third position holds. A spring workshop had surfaced the usual back-office drag: a hundred supplier invoices a month re-keyed by hand, an hour and a half to validate the minutes of every large meeting, NDA reviews with inconsistent coverage of the risk clauses, underwriting models built by copying numbers out of PDFs.

In a two-week sprint inside their Microsoft environment, one joint team shipped four Claude-powered agents against exactly those four problems:

  1. Accounts Payable: 80% less time per invoice, over 90% of line items matched automatically.
  2. NDA Review: three days to under two hours.
  3. Underwriting Initialisation: 25 hours to under three.
  4. Meeting Notes: an hour and a half to thirty minutes.

Each left with an owner, a test user and a maintainer. Since then their own people — about 25 trained, around ten using the agents daily — have built more than twenty further agents, each in under half a day, and are now wiring the AP agent directly into NetSuite and the NDA agent into DocuSign. “The Artefact team was brilliant,” said Phil Price, their Head of FP&A, and “left us in a good place to continue building and expanding on our own.” The first half of that sentence is kind. The second half is the point.

The frontier is no longer the model. It is the distance between the model and your Monday morning. If you hold Claude or ChatGPT licences and cannot yet answer the three questions in this article — what the model knows about you, who owns adoption in each department, and who builds and maintains your agents — then you do not yet have an AI capability. You have a subscription.

The good news is that the distance can be closed in weeks, not years, by people who have decided that closing it is their job.

I would be glad to hear where you disagree: remi.sabonnadiere@artefact.com