The pattern everyone recognizes
A leadership team approves an AI roadmap. Budget follows. An implementation effort starts. Eighteen months later the organization has a pilot that works in a sandbox, several parties pointing at one another, and an operations team that was not in the room when the decision was made.
This is not a failure of intelligence or intent. It is a structural failure, and it repeats across utilities, financial services, and retail.
Advice and production are different kinds of work. A recommendation can be excellent and still die in the handoff to the people who have to run the system.
Five ways the handoff kills the agent
1. The engagement ends at the decision
Many programs are scoped to analysis, a target operating model, and a recommendation. Success is recorded when the leadership team accepts the deck. Production is a different success condition: an agent handling real work, with a record of what it did. If nobody owns that second condition, it does not happen.
2. Accountability is dropped at each handoff
The usual sequence is familiar. A team frames the opportunity. The enterprise commissions a build. A specialist produces a proof of concept. Internal operations inherits something it did not design. At each step, context thins out, governance is reinterpreted, and observability is postponed.
Production agents do not survive that sequence. They need one group that scopes the workflow, writes the evaluations, deploys on real traffic, and stays through the first incident.
3. Trust is treated as a policy, not a design
Executive teams understand the business, the operating structure, and the regulatory landscape. A production agent also needs tracing, retrieval design, evaluation, drift detection, and limits on what it is allowed to do. Those controls have to be in the build. They cannot be written afterward as a policy.
When that evidence is out of scope, governance stays a document. A board cannot audit a document that describes a system nobody is watching.
4. The roadmap is wide, and nothing is live
A broad map of use cases is the right tool for prioritization. It is a poor tool for execution. A production agent needs a narrow scope: one workflow, bounded actions, real traffic, a measurable outcome. Then the pattern can be repeated.
Ten use cases on a roadmap, with none of them in audited production, is a weaker position than one use case a risk committee can examine.
5. The clock is set for a transformation, not an operator
Large programs run on quarterly milestones and steering committees. An agent on real traffic needs a thin slice within weeks, a check before every change, and someone who can respond when it misbehaves. A governance calendar that cannot move at that speed will watch the pilot expire.
Shipping a demo is not the remedy
The other failure is a build that moves fast and skips what a regulated enterprise has to show:
| What you get | What's missing |
|---|---|
| Working chatbot demo | Action boundaries and escalation triggers |
| RAG prototype | Citation verification and audit-ready logs |
| Fast iteration | Regression evals before every deploy |
| Low initial cost | Observability, drift monitoring, FinOps |
| Technical delivery | Board and regulatory fluency |
That version is technically impressive and still unable to pass an audit, survive an incident, or satisfy a risk committee.
The one-team standard
The organizations that do reach production share one structural choice. The people who scope the problem stay with the system and own the outcome. I use this as the standard to put in front of an executive team:
The same people from decision to production
No long gap between the approval and the team that has to run it. Scope, build, deploy, and hand over as one line of accountability.
An outcome, not a stack of activities
Success is one agent in audited production, with observability, governance, and runbooks. Activity is not the result.
Evidence in scope from the start
Traces, evaluations, drift alerts, and cost are part of the build, not a later request.
Executive fluency without a multi-year pause
Board-ready reporting and regulatory awareness, on a clock an operator can actually keep.
Where the advisory work belongs
None of this is an argument against advisory work. It is the right work when the enterprise needs:
A clear view of where AI is worth doing, and where it is not
An operating model across business units
A framing a board can use, and a change program that matches it
A decision on what to build, what to buy, and what to stop
Use that work to make the decision. Then require one accountable line through to a system on real traffic. The last mile is one governed agent, with evidence. It fails when the decision and the system belong to different owners.
What to require
If you are a CIO, CDO, or operating leader with an approved roadmap and no production agent, this is the sequence that holds:
- Pick one workflow. Customer service, regulatory retrieval, or document processing. Not ten.
- Spend the first two weeks on readiness: which agents exist, what evidence the board will ask for, and what the controls have to be.
- Put a thin slice on real traffic inside the following two months, then harden it until it can be audited.
- Repeat the pattern, or keep a named owner on the monitoring.
About ninety days from the decision to something a board can examine. One line of accountability.
The gap that matters
I lead AI architecture and delivery for regulated-industry clients at PwC, especially in utilities, financial services, and retail. The useful question is not who wrote the roadmap. It is who owns the system after the roadmap is approved, and what evidence they can put on the table.
Views here are my own.
Related: The Operator Model for Enterprise AI · Agent Observability: What Boards Actually Need