Enterprises have agents. Almost none have outcomes — and a smarter model won't fix it.

The demo is not the milestone

There has never been a better time to make an agent look brilliant. A well-chosen task, a clean prompt, a live audience, and the demo lands. What the demo doesn’t show is the part that decides whether any of it matters: what happens on the ten-thousandth run, at 2am, when an upstream system times out halfway through.

The verdict on that second part is blunt. Capgemini’s 2026 Data-powered Innovation Review sums it up in five words, “Every enterprise has agents. Few have outcomes”, and explains why: most of what got built is artisanal AI, “brilliant in the hands of one engineer, unrepeatable across a program”. It demos beautifully and then stalls on the way to production, where a notable share of the time it was meant to save is quietly eaten back up by validation, correction and rework.

Read that as an executive, not an engineer. Almost everyone can now build the demo. Very few can turn it into something that runs, repeatably, where the business actually operates. The distance between “it worked in the room” and “it runs the process” is where the value is won or lost. Today, for most, it is lost.

Why agents die in production

The failures are rarely dramatic. An agent is not usually defeated by a hard reasoning problem; it is defeated by the ordinary mechanics of production work.

A step half-completes and the agent retries it, and because nothing made the action idempotent, the order is placed twice. A run crashes midway and there is no saved state to resume from, so it starts over, or worse, leaves the world half-changed. An action is taken and no durable record is written, so when someone asks a week later what happened and why, the answer is a shrug. A new prompt or model version ships straight to live work with no evaluation gate in front of it, and a quiet regression degrades every run until a human notices. None of these is exotic. All of them are fatal to trust, and trust is the thing an agent needs most.

Capgemini names the same pattern from the other side. In its 2026 review it observes that “every enterprise has agents; few have outcomes”, because most built artisanal AI, “brilliant in the hands of one engineer, unrepeatable across a program”. The demo is a craft object. Production needs an industrial one.

A smarter model is the wrong purchase order

The natural reflex, when a pilot disappoints, is to reach for a more capable model. The evidence argues almost the opposite. What stalls artisanal AI on the way to production is rarely that it is too dumb; it is that it is static and unaccountable: it doesn’t retain what it learns, it doesn’t recover when a step fails, and no one can see what it did. Those are properties of the harness around the model, not of the model itself.

That reframes the buying decision. If the constraint were capability, waiting for the next model would be a strategy. Because the constraint is durability and learning, the next model changes little. A more eloquent agent that still double-charges the order, loses its state, and leaves no receipt is not progress. On this reading, the layer that decides outcomes sits around the model, not inside it, which is also why it should be model-agnostic: the harness has to survive you swapping the model underneath it.

What a durable execution platform is

If the constraint is the harness, then the harness is what matters. That is what Operstead is designed to be: a horizontal, model-agnostic layer for reliable, verifiable execution of agent and workflow work. Operstead is designed to execute only work authorised elsewhere; it neither makes the business decision nor grants the authority to act. Concretely, as designed and validated locally:

• Durable execution. Operstead is designed to run work with retries, idempotency and resume-after-failure, so that a timeout or a crash need not double an action or lose the thread. The intended unit of reliability is the workflow, not the prompt.
• Receipts. Each run is designed to produce a durable record of what was done and what came back, so “what happened and why” has an answer rather than a shrug.
• Evaluation gates. A new prompt, tool or model version can be checked against a known set before any separately authorised promotion. Operstead is designed to make that check; it does not itself hold promotion or runtime-activation authority.
• Isolation, policy and a human gate. Tenant isolation and role-based policy are design controls. High-authority steps are designed to stop for a human rather than run unattended.
• Connectors. Connector interfaces are designed as managed adapters rather than brittle one-off integrations that break on the next change.

All of the above is what Operstead is designed to do. It executes only work authorised elsewhere; it does not itself hold execution or promotion authority.

What changes for the executive

The shift is in what you measure and what you buy. A demo optimises for the moment; a durable platform optimises for the ten-thousandth run. So the questions that matter are not “how good was the pilot” but “does it survive production, does it repeat across teams, and does it improve”, three operating questions the cited market evidence makes worth asking.

The intended effect is fewer stranded pilots and more work that actually runs. The direction is clear enough to act on now: the enterprises that keep buying capability will keep collecting impressive demos that don’t survive Monday. The ones that buy durability (the harness, not the model) give their agents a chance to become outcomes.

Where this leaves you

Almost everyone has agents. The scarce thing is the layer designed to let an agent run where the business runs, recover when it stumbles, leave a record, and get better. That layer is buildable today, and it is model-agnostic by necessity. If your agent programme is long on demos and short on production, the gap is probably not the model, and the honest next step is a conversation about the harness, not another pilot.

We are looking for design-partner discussions and are glad to walk through the local runtime evidence behind what is claimed here.