Introduction

A few months ago a CIO showed me his Claude Enterprise dashboard. Two thousand seats, rolled out in six weeks, single sign-on through the corporate identity provider, a usage policy signed off by Legal and acknowledged by every employee at first login. Then he scrolled to the second tab. Weekly active users: 14%.

The most common prompt: “summarise this email.” The second most common: “rewrite this in a more professional tone.” Not one connection to the ERP, the data warehouse or the document repositories. Not one agent in production. Three floors below us, the accounts payable team was opening supplier PDFs one by one, reading the invoice number, the amount and the cost centre, and typing them into the finance system by hand — roughly a hundred invoices a month, about a day and a half of someone’s time.

I have stopped finding this surprising. I now think it is the default outcome of how enterprises buy AI, and I want to be blunt about why.

We have collectively decided to treat frontier models like software: procure the licence, provision the seats, run a webinar, move on. That worked for email and for CRM, because the value of those tools was inside the tool — the inbox was the product, the pipeline view was the product. The value of a frontier model is not inside the model. It is in the distance between the model and a specific company’s data, permissions, habits and processes: whether the model can see last quarter’s sales by SKU, whether it knows that “net revenue” in this company excludes trade spend, whether a sales director has ever once used it on a question she actually had to answer that week.

Nobody in the organisation is paid to close that distance. IT owns the tenant and measures uptime. The business owns the use cases and measures nothing. The vendor owns the roadmap and measures seats. The space in between belongs to no one, and that space is where the value lives.

My conviction, after a year of walking into companies at the 14% moment, is that this space is a discipline in its own right. It is not change management with better slides, and it is not systems integration with a new API. It is engineering, data, security and adoption work done together, inside the client, by people who also sit inside the lab’s roadmap and who are accountable for an outcome rather than a deliverable. I call it the deployment layer, and this article is my argument for why it matters more than the next model release.

Why enterprise AI stalls after the licence is signed

The pattern is the same in banking, in consumer goods, in real estate and in telecoms, and it unfolds in a recognisable sequence. A pilot succeeds: a small team in marketing or customer service, a sympathetic sponsor, a clear use case, a demo that makes the executive committee lean forward. A second pilot succeeds in another function. Leadership approves an enterprise rollout, often with a target like “AI for everyone by Q2.” The rollout happens. Adoption rises for three weeks on novelty, flattens at the level of a better search engine, and the agents that were supposed to follow the rollout stay on a slide titled “Phase 2.”

The usual explanations are wrong.

  • It is not that employees resist change; the ones I meet are desperate for the tool to work on their actual job and frustrated that it cannot see the spreadsheet they are looking at.
  • It is not that the models are immature; they were capable of most of this two generations ago, and the gap between what Claude or GPT can do and what the organisation asks of them has only widened since.
  • And it is not a lack of use cases. Every workshop I have run produces eighty of them in a morning, half of which are variations of “stop making me re-key this.”

It stalls because three questions have no owner:

  • What does the model know about us? Which systems can it see — the warehouse, the document stores, the ticketing system, the HR platform? Under whose permissions does it see them: the service account’s, or the person asking? And when it gives a number, can anyone trace it back to the table or the document it came from?
  • Who is accountable for adoption in each department? Not for licence counts — for the Monday-morning habit of using the tool on real work in Sales, in Finance, in Legal, in Operations, each of which has different data, different vocabulary and a different definition of “useful.”
  • Who builds the agents, and who maintains them when the consultants leave? An IT backlog that is already eighteen months deep, an external vendor on a time-and-materials contract, or people who sit in the business and understand the process they are automating?

I have yet to see a programme succeed where these questions were answered by a steering committee. They are answered by people doing the work, in the building, with authority to decide.

The Deployment Layer: the capability nobody budgets for

Between the model and the business sits a layer of work that is neither pure IT nor pure change management. I think of it in four parts, and I hold a strong view on each.

Deploy. The platform itself — Claude Enterprise, Claude Code and Cowork, or ChatGPT Enterprise and Codex — rolled out properly. In practice that means a licence model that allocates seats by role, area and seniority rather than first-come-first-served; identity through the corporate SSO with group-based access; a usage policy that says in plain language what may and may not be pasted in, and a best-practice guide that says what good looks like; and cost governance that shows, per department, who is using what, from the first week. This is the part most organisations do reasonably well, and it is the least valuable part on its own. A perfectly provisioned tenant with nothing connected to it is a very expensive chat window.

Ground. The context layer that makes the model answer with the company’s own truth. Concretely: a single MCP server, running in the client’s own cloud tenant, that exposes the structured data (the sales tables in Fabric or Snowflake, the budgets, the KPI marts) and the unstructured repositories (contracts, policies, board decks and procedures in SharePoint or Drive) through one governed door. On top of it, a business knowledge layer: the official glossary, the KPI definitions as Finance writes them, the business rules (“a quarter closes on the 25th”, “exclude intercompany from net sales”), and a semantic description of every document so the model can find the right file and read it in full rather than guess from a snippet. Access mirrors each employee’s existing permissions, so the model sees for you only what you could already open yourself. And every answer carries a citation: the table, the row filter, the document, the page. I believe this is where enterprise AI is won or lost, and it is the part almost everyone skips because it looks like plumbing. Without it the model is a brilliant stranger. With it, it is a colleague who has read everything and can prove it.

Adopt. Training, department by department, on live company data. I have become allergic to the generic “prompting masterclass” with its sample emails and its imaginary company: it produces a week of curiosity and then silence. The sessions that work look different. Sales spends two and a half hours on one real question about last quarter. Finance reconciles a real month-end file. HR rebuilds a real absenteeism report. Legal reviews a real NDA against the company’s own playbook. Each participant leaves with a Claude Project that holds their department’s rules and a working artefact they will open again on Monday. The difference is not pedagogy. It is whether the model was grounded before anyone was trained on it.

Build. Production agents, developed in short sprints by engineers who sit with the client’s team, on a framework the client keeps. The unglamorous work — reading supplier invoices into a schema and flagging unmatched lines, drafting meeting minutes and actions from a Teams transcript, checking an NDA against the house guidelines and summarising the liability and termination clauses, extracting the numbers from a stack of PDFs into the underwriting template — is where the hours are, and it is where most agent programmes never arrive because they start with something impressive instead of something useful.

These four are a system, not a menu, and I would go further: doing one of them without the others is often worse than doing nothing. Training without grounding teaches people that the tool hallucinates, and they are right. Grounding without training builds a cathedral nobody enters. Agents without a platform produce a dozen disconnected automations with no shared governance, and the security team eventually, rightly, shuts them down.

The arithmetic I keep coming back to is simple:

Value = Model × Deployment Layer.

The model is a very large number. Multiply it by zero and you get zero. Every release from the labs makes the first factor bigger and the second factor more decisive.

And here is the uncomfortable part for anyone hoping to buy their way out: the deployment layer cannot be purchased as software. The labs sell the model and the platform, and they are right to stop there. The context, the permissions, the department-level habits and the first agents are specific to each company’s data and politics — to which system is the source of truth for a customer, to who is allowed to see margin by product, to how the finance team actually closes a month. They have to be built in the building, by people who understand both the model’s roadmap and the client’s systems. There is no shortcut, and I am suspicious of anyone who sells one.

Example — Who answers the sales question?

Consider a simple question a commercial director might ask on a Monday morning: “How did Skala perform year-over-year last quarter, and where did we lose share?”

At Bora Brasil, the haircare group formed from Skala Brasil and Lola From Rio, that question used to travel. From the director to an analyst, from the analyst to a BI extract, from the extract to a spreadsheet, from the spreadsheet to a deck, and back to the director three days later, by which point the follow-up question had changed. Meanwhile fifteen early adopters were already using Claude informally, connected to their email, calendar, Teams and files, getting plausible answers that nobody could trace to a source and that sometimes used a definition of “share” nobody in Finance recognised.

Leadership’s three requirements were exactly the three questions above: answers grounded in the group’s own data, access that respects existing permissions, and a governed environment so that sensitive commercial information stopped drifting into unsanctioned tools. That is the 14% moment, seen from inside.

What changed over nine weeks was not the model. Three streams ran in parallel: a bottom-up adoption stream, a top-down roadmap stream and a governance stream.

  • The engineering work produced a context platform on Azure, approved by the group’s own technical leadership, that exposes Microsoft Fabric (sales, KPIs, budgets) and SharePoint (contracts, policies, presentations) through a single MCP server.
  • A business knowledge layer holds the glossary, the KPI definitions and the business rules, with a semantic description of each document so Claude can locate and read the full file.
  • Access mirrors each employee’s existing permissions, and every figure cites its source table or document.

In parallel, interviews with the directors of Commercial, Marketing, Innovation and R&D, Operations, Finance and HR produced 83 opportunities, scored on business value and technical complexity, narrowed to 24 and then, in a leadership workshop, to five for the year-one roadmap.

Then — and only then — came the training, on exactly that sales question. In a 150-minute session each participant set up a Claude Project with the business rules, pulled the KPI definitions from SharePoint, planned the query before running it against Fabric, built an interactive sales dashboard as a shareable artefact and checked the source of every number. The faster ones turned the dashboard into a weekly scheduled routine in Cowork before the session ended. The facilitator’s guide, itself built with Claude, tracked each participant’s progress step by step.

Sixty-two employees are live today, scaling to 150, with licences allocated by role and area, an AI Office at the centre and a Champion in each business area. The first thirty licence holders report at least four hours saved per week on average; seven in ten save three hours or more. One HR payroll data-load conversion took 90 minutes instead of the 40 consultant hours quoted externally. A timekeeping report that used to take eight hours of manual checking now runs on a schedule.

I tell this story not because the numbers are large — they are early and self-reported — but because the sequence is the lesson. Ground first. Train on the grounded thing. Hand the habit to someone who stays. Reverse the order and you get a webinar.

The forward deployed operating model

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.

  • 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.
  • 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.
  • And, for engineering teams, enablement 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:

  • accounts payable (80% less time per invoice, over 90% of line items matched automatically),
  • NDA review (three days to under two hours),
  • underwriting initialisation (25 hours to under three)
  • and 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