Moving an AI agent PoC into production requires five evidence-bearing handovers: workflow value, production-shaped context, real authority, operational recovery, and adoption with full cost. Give each gate a named owner, an exit test and an artefact the next stage can inspect. Production begins when those interfaces work together under representative conditions.
A successful demonstration leaves many of the expensive questions unanswered. Sample documents may carry no live permissions. A developer account may hide the identity model. Manual supervision may absorb exceptions without appearing in the result. The path to production has to replace each convenience with an operating mechanism the company can support.
Why does a successful PoC still need production work?
A proof of concept tests a hypothesis under a narrow boundary. Production introduces changing source material, real users, concurrent cases, permission revocation, tool failures, support obligations and recurring cost.
Microsoft’s agent development lifecycle separates discovery, experimentation, build, deploy and operational steady state. It also advises teams to experiment with current models and real-world data because synthetic or limited test data increases the risk of different production behaviour.
The practical gap sits in the handovers between those phases. A prototype team can prove that an agent drafts a useful account brief. Deployment still needs to establish which CRM fields and documents it may read, how conflicting evidence is handled, which user can request the brief, where reviewer changes go, and who responds when the CRM write succeeds but the agent records a timeout.
Treat those handovers as release gates. Leaving them on a hardening list until the end pushes identity, recovery and ownership problems into the most expensive stage.
Gate 1: prove one workflow outcome
The first gate fixes the unit of value. Name the event that starts the work, the terminal state that completes it and the system that verifies the result.
For a Product × GTM planning workflow, the unit may be one accepted planning artefact built from authorised product and commercial evidence. The baseline should capture preparation time, reviewer time, material revisions and elapsed time to acceptance. Activity such as messages generated or tools called can explain performance, but it cannot establish business value on its own.
OpenAI’s practical guide to building agents directs agents towards work involving complex judgement, difficult rules or unstructured data, and recommends validating that fit before committing. Apply that filter at the workflow level. Stable transport, validation and write-back remain cheaper and easier to test as deterministic automation.
The gate clears when the sponsor can answer four questions with evidence:
- Which cases are eligible?
- What observable state counts as accepted?
- Which errors stop the release?
- Does the accepted result improve on the current baseline?
The AI agent pilot success criteria guide provides a scorecard for that decision. Carry its case definitions and acceptance results into production work so the release builds on evidence already accepted by the workflow owner.
Gate 2: replace demo context with production-shaped context
A PoC can work because its inputs were selected, cleaned and placed within one easy retrieval boundary. Live company knowledge has owners, versions, conflicting claims, restricted records and deletion events.
List every required source and record:
- the system owner and authoritative fields;
- eligible users, groups and agent identities;
- freshness and synchronisation expectations;
- treatment of conflicting or superseded material;
- evidence retained beside consequential output;
- behaviour when a source or permission check is unavailable.
Run representative cases through the same identity and retrieval route intended for deployment. A test folder with copied documents cannot prove that source permissions survive retrieval, nor that revocation removes later influence from cached or derived material.
This gate also exposes preparation work. Missing metadata, contradictory pricing rules or undocumented operating exceptions belong to named owners. The agent cannot resolve organisational ambiguity by producing a fluent answer; it can only make that ambiguity cheaper to overlook.
The exit artefact is a source-and-authority map tied to test results. It should show which evidence entered each accepted output, which policy allowed access and how a conflict reached a reviewer.
Gate 3: bind every action to identity and approval
Production authority changes the commercial risk. Reading an account record, drafting an update and sending it to a customer require separate controls even when one agent can perform all three.
Create an action register with the initiating user, operating identity, allowed scope, evidence requirement, approval point and valid destination state for each tool call. Test the denied paths as carefully as the successful route.
A shared developer credential conceals whether the production agent acts as itself, on behalf of a user or through a service identity. That choice determines whose permissions apply, what appears in the destination audit trail and who can revoke access. Approval must bind a reviewer to the exact action and current evidence; any material payload change should require a new decision.
Use progressive authority. Start with recommendation or draft output, add approval-gated writes after repeated accepted cases, then widen the boundary only when the new action class has its own evidence. A broad autonomy setting compresses several business decisions into one technical switch.
The gate clears when eligible actions succeed, prohibited actions fail closed and the audit record joins the requester, agent, evidence, approval and resulting system state.
Gate 4: prove operation and recovery
A deployment plan needs an owner after go-live. Monitoring without response responsibility produces a dashboard while the business still improvises during failure.
Define service expectations around the consequence of the workflow: case completion, accepted outcome, latency, tool reliability, review queue, restricted-access attempts and cost per accepted case. Set alerts that route to someone with authority to contain the problem.
Then force failures before launch:
- remove a required permission between planning and action;
- time out a tool after the destination has applied the change;
- deliver the same event twice;
- reject or expire an approval;
- change a source or model version and replay the evaluation set;
- interrupt a run after one external write;
- disable the workflow and verify that new actions stop.
Each case should end in a verified business state. A successful retry log cannot prove that the CRM, payment system or customer record is correct.
The AI agent rollback plan sets out operation IDs, action ledgers, reconciliation and compensation for partial work. When the failure source remains unclear, the troubleshooting guide traces the first divergence across context, judgement, tools, authority, handoffs and outcomes.
Microsoft’s organisational operating guidance recommends phased expansion, continuous feedback, lifecycle management, cost controls and retirement of unused agents. Those duties need to exist for the first production workflow, even when the initial user cohort is small.
Gate 5: show that the changed workflow survives contact with users
Technical deployment can succeed while operators keep doing the old work in parallel. That protects them from an untrusted result and erases the labour saving assumed in the business case.
Run a controlled cohort inside the channel where work already happens. Train users on eligible cases, evidence inspection, correction, escalation and stop controls. Record abandonment, repeat use, active review time, material rework and work completed outside the agent path.
Corrections need a destination. Some reveal a weak prompt or test case; others expose missing source ownership, policy ambiguity or a broken handoff. Route each correction to the owner who can change its cause, then replay the case before the next release.
Calculate full cost per accepted outcome across model and tool usage, licences, infrastructure, review, exception handling, support and recovery. The AI agent unit economics guide connects those costs to the business result at case level.
This gate clears when the target users repeat the workflow, accepted outcomes stay within the agreed quality and risk boundary, and the operating cost supports the sponsor’s scale decision.
Use a handover record between every stage
A useful production plan makes evidence portable. Keep one record that gains detail as the workflow advances:
| Gate | Decision | Required evidence | Accountable owner |
|---|---|---|---|
| Workflow value | continue, revise or stop the use case | baseline, eligible cases, accepted outcomes and hard-stop errors | business workflow owner |
| Production context | approve sources and retrieval boundary | source map, permission tests, conflict cases and provenance | data or knowledge owner |
| Authority | approve each action class | identity map, action register, denied-path tests and approval records | release owner |
| Operations | accept support and recovery duty | telemetry, alerts, runbook, forced-failure results and verified recovery | technical and support owners |
| Adoption and economics | expand, restrict or retire | repeat use, review labour, accepted outcomes and full case cost | sponsor |
Do not pass a gate through meeting consensus alone. Attach the test set, trace, source snapshot, reviewer decision or destination query that supports it. The next team can then inspect the assumption it inherits.
Set the timeline from the critical path
A generic four-week or twelve-week promise hides the variable work. Build the schedule backwards from six dependencies:
- access to representative cases and baseline data;
- source, identity and tool integration;
- availability of workflow owners and reviewers;
- evaluation volume and required edge-case coverage;
- recovery engineering for consequential actions;
- user cohort and enough live work to judge repeat use.
Parallelise work where the interfaces are already defined. Evaluation cases can be prepared while the source integration is built. Support owners can design incident routes while users test draft-only output. Permission and outcome definitions need earlier agreement because every later test depends on them.
The release date becomes credible when unresolved dependencies, owners and evidence thresholds are visible. Calendar pressure can then change scope deliberately by narrowing the case segment or action boundary, without quietly weakening the acceptance standard.
Make production a bounded operating decision
A PoC earns investment by reducing uncertainty about feasibility. Production approval requires a stronger conclusion: this company can operate the workflow under real context, authority, failure and adoption conditions.
Model Operator is implementing and validating these contracts through hands-on AI Initiative Consulting and its governed company operating layer. The Design Partner engagement applies them to one recurring Product × GTM Planning Room workflow across Slack and Google Drive or SharePoint, with evidence, accepted truth, decisions, approvals and repeat-use measures inside a strict scope.
For an agent PoC approaching live work, bring the workflow, its accepted outcome and the most expensive failure to Model Operator or email alexander@modeloperator.io. The first task is to expose the handovers the demo currently hides.