From AI Pilot to Production: Architecture, Evaluation, and Operating Requirements

A production AI system must complete real work when inputs, dependencies, and people are imperfect. A prototype can establish that a model performs a promising task. Moving into production requires an application and operating model that define identity, authority, evidence, state, review, recovery, and continuing ownership.

The transition should be organized around a specific release decision. Which cases will the system handle, for which users, with what authority, and under which operating conditions? A bounded answer makes it possible to gather useful evidence and expand deliberately. A general claim that the pilot “worked” does not establish every future capability.

This guide follows an illustrative internal service workflow from draft preparation to controlled execution. It is a design example, not a client case or promised implementation schedule. The objective is a reviewable path from a useful prototype to a system the business can operate.

Decide what the pilot must prove

A pilot should resolve an uncertainty that changes the implementation decision. Examples include whether the available data supports reliable extraction, whether retrieval can find controlling evidence, whether a model can handle the relevant exceptions, or whether reviewers can use the output efficiently. State the uncertainty and the decision it informs before building more features.

Define the baseline. That might be the current manual process, a deterministic workflow, or a simpler model-assisted application. Compare the proposed system on the same task boundary and case mix. If the pilot changes several operating conditions at once, document them so the result is not attributed entirely to the model.

Use the Workflow Discovery Template to capture triggers, steps, sources, actions, exceptions, and owners. The AI Agent Readiness Checklist helps identify gaps that should become discovery work rather than assumptions embedded in the prototype.

The pilot's completion record should say what was tested, what was observed, what remains uncertain, and the next permitted scope. This makes a limited success useful without overstating it. A draft-only workflow can be valuable while automatic execution remains a separate decision.

Define the first production boundary

Scroll horizontally to see all columns.

Implement exclusions as real behavior. If unsupported cases should return to the service team, provide that route and the context the team needs. A statement in the project document is not sufficient if the application attempts every incoming request anyway.

Keep the first release useful. Narrow scope should preserve a meaningful end-to-end task rather than producing a demo fragment that users must manually connect to the rest of their work. Define the handoff clearly when the initial system ends at a draft or recommendation.

Replace prototype credentials with an access design

Prototype code often runs with a developer's broad access. Production needs an explicit identity model for users, services, and tool execution. Record which identity reads each source and which may change each target object. The application should carry the current request's scope through those operations.

Separate technical connectivity from authorization. An API being reachable does not establish that the workflow may use every operation. Provision the narrow access required by the first release and verify both permitted and denied cases. Include revocation and changes during a waiting state.

Keep credentials outside model-visible context and ordinary diagnostic output. Use the established secret-management and rotation mechanisms for the environment. A permission change should be enforceable without relying on the model to remember a new instruction.

The AI Agent Security guide develops the trust-boundary review. Bring the security owner into the actual data and tool design so the release evidence covers the application being deployed.

Turn integrations into reliable contracts

Document each interface's inputs, outputs, authentication, limits, failure modes, and completion evidence. Validate both the shape and business meaning of a proposed operation. A syntactically valid payload can still reference the wrong customer or request an invalid transition.

Separate reads, proposal creation, and external writes. A model can draft an action while the application checks permission and policy before execution. Return structured results that distinguish rejection, temporary failure, pending work, and unknown completion. Those distinctions determine safe recovery.

For writes, establish a stable operation identity and a way to recognize prior completion. A lost acknowledgment can leave the caller uncertain even when the target changed. Do not enable blind retries because a prototype succeeded when the network was healthy. The long-running agents guide explains the resulting state and reconciliation requirements.

Test the actual integration contract in an appropriate sandbox or controlled environment. Test doubles are useful for application behavior, but record where the real service can differ. Include authentication expiry, rate limits, malformed responses, and relevant schema changes in the integration inventory.

Separate model context from business state

The production application needs a durable record of case progress. Store the request identity, stage, evidence references, proposal version, approval, action attempts, and confirmed result. Conversation history can support diagnosis and interpretation, but it should not be the sole source for deciding what already happened.

Define the lifetime of each state element. A proposal may expire, a source may be superseded, and a user's access may change. On resumption, validate the facts that matter to the next action. Do not assume that a stored conversation remains a valid representation of the current business situation.

Plan for active cases during deployments. Record model, prompt, policy, tool, and state-schema versions where relevant. Decide how pending work stays compatible with a new release and what rollback means for it. Reverting application code does not undo an external record update.

The agent architecture guide provides a component-level view of these responsibilities. A graph or workflow engine can help implement them, but the business-state contract still needs to be designed.

Build evaluation around accepted outcomes

Create a representative case set with normal work, difficult inputs, missing evidence, conflicting records, unsupported requests, and boundary violations. Define correct completion, appropriate escalation, and unacceptable behavior before running the final candidate. Record the configuration and dataset version with the results.

Use direct checks for observable outcomes and structured values. Use domain review or calibrated model-assisted grading where interpretation is needed. Inspect the actual target-system state when the task requires an external action. A generated message saying the task is complete is not sufficient evidence.

Anthropic's agent evaluation guidance describes evaluating the model and surrounding harness together, combining grading methods, and examining outcomes as well as traces. Apply those ideas to the business task and retain the failed cases, not only the most successful demonstrations.

The AI Agent Evaluation article explains case design, repeated trials, and release criteria in more detail. Use the pilot to produce a maintainable evidence base that can be rerun when the application changes.

Make human review part of the product

A reviewer needs the request, relevant facts, source evidence, exact proposal, and unresolved questions. The interface should make approval, revision, rejection, and escalation understandable. Capture those decisions as structured outcomes rather than free-form comments that the model must interpret as authority.

Bind approval to the proposal version and intended action. If the payload or material facts change, determine whether new approval is required. Recheck current permissions and target state immediately before execution. These controls make the human decision actionable and prevent an old approval from being stretched to cover different work.

Measure reviewer effort and queue behavior. A draft that saves generation time but creates extensive checking may not improve the workflow. A review queue without coverage can make a technically functioning system operationally incomplete. Define expiration and reassignment so waiting cases have a clear owner.

Use the human-in-the-loop controls guide to specify the review workflow. The production scope should include the interface and operating coverage necessary for that control to work.

Rehearse failure and recovery

Interrupt the workflow at consequential points: before an action, after submission but before acknowledgment, during a review wait, and after one of several external effects succeeds. Inspect what the application records and how it resumes. Verify that recovery does not repeat completed actions or revive cancelled work.

Test duplicate events and concurrent changes. If a reviewer approves while a user edits the request, the application needs a rule for which proposal is current. If the target record changes while the case waits, the next action should reflect that change or stop for a new decision.

Prepare a manual recovery path for conditions the system cannot resolve automatically. Preserve enough evidence for an operator to understand the case, while respecting access and retention requirements. The recovery interface should enforce authority just as the normal execution path does.

Record the recovery rehearsal as release evidence. A written runbook is useful, but a procedure that has been exercised against the deployed design provides stronger support for the operating decision. Repeat relevant parts when infrastructure or integration behavior changes.

Connect monitoring to accountable action

Monitor business outcomes and failure categories, not only model latency. Useful signals include incorrect accepted results, unresolved cases, review backlog, integration failures, retries, denied actions, and source freshness. Each signal should connect to an owner and a response decision.

Use structured events to identify the case, release, relevant transition, and outcome. Minimize sensitive content in logs and control who can inspect detailed evidence. A trace should help distinguish model, retrieval, policy, integration, and workflow-state problems so the team changes the right component.

Define who can pause new actions, revoke a tool, route work manually, and restore service. The operational owner needs the authority and information to act. A dashboard without a response path is observation without an operating capability.

Separate ongoing application quality from infrastructure availability. A service can be reachable while producing worse results because a source changed. Conversely, high-quality model behavior does not resolve a failing integration. Assign both responsibilities in the handoff.

Roll out with a decision rule

Choose an initial audience and case scope that can produce useful evidence while keeping operations manageable. Define the observation window, comparison method, and stop conditions before expanding. The release owner should know which result justifies continuation and which result requires investigation or a narrower boundary.

Google's canary-release guidance describes using a limited deployment and relevant comparison signals to inform broader release. For AI workflows, include output quality, review effort, and permissible behavior alongside service health. The rollout design should fit the traffic and consequences of the task.

Expansion can involve more users, more case types, new sources, or greater authority. Treat those as distinct changes. A release that handles more users at the same authority level may require capacity evidence; a release that begins writing records requires additional action and recovery evidence.

Use the Production AI Launch Checklist to assemble the release record. It connects evaluation, security, review, recovery, monitoring, and rollout in one decision artifact.

Worked transition: from draft assistant to controlled execution

The prototype reads a service request and generates a plausible resolution. The pilot narrows the task to one request category and uses approved sources. Reviewers judge evidence support, completeness, and effort. The application records cases and saves drafts, but no tool can update account permissions.

The first production release adds authenticated access, permission-aware retrieval, durable state, a review queue, monitoring, and a manual fallback. The team observes the completed workflow under real use. The release remains draft-only because that is the authority supported by the current evidence.

A later proposal introduces one specific record update after approval. The team defines the acting identity, target validation, operation identifier, completion check, and recovery behavior. It adds tests for stale proposals, revoked access, duplicate events, and lost acknowledgments. Only that operation is enabled after the additional evidence is accepted.

The operating record preserves the difference between these releases. It explains what changed, which cases were tested, and who owns the new responsibility. This prevents a successful pilot from becoming an undefined grant of broader automation authority.

Complete the engineering and operating handoff

The handoff should include architecture, deployed configuration, source and integration inventories, permission model, evaluation cases, release results, monitoring, runbooks, and known limitations. It should also identify the people who can approve source changes, policy changes, releases, and access changes.

Record where each artifact lives and how it is maintained. A test set that cannot be rerun or a runbook that no operator can access is incomplete in practice. Arrange a walkthrough using a normal case and a recovery case so the receiving team can demonstrate the operating process.

Keep a release decision log that survives handoff

For each release, record the decision owner, configuration identifier, included cases, permitted authority, evaluation evidence, operating coverage, and known restrictions. Link the decision to the actual artifacts used in review. The purpose is to let a later operator understand why this version was allowed to perform this work.

Include the decision to hold or narrow a release. If an integration cannot reliably confirm a write, the useful outcome may be a production draft workflow with execution disabled. Record the missing evidence and the owner of the follow-up. That preserves progress while preventing a temporary restriction from being forgotten during later feature work.

When the scope expands, describe the difference from the prior release. Adding a document source can change answer quality and access behavior. Adding a user group can change case mix and review demand. Adding a write operation changes authority and recovery requirements. Each change needs the relevant evidence, even when the model itself is unchanged.

Review the log during operating handoff with a normal case and a constrained case. Ask the receiving team to identify what the application may do and what must return to a person. If the answer depends on undocumented knowledge held by the original developer, improve the record or interface before treating the handoff as complete.

A maintained release log also helps interpret later incidents. The team can compare observed behavior with the accepted scope and determine whether a control failed, the environment changed, or an unsupported capability was introduced. That makes the response more precise and gives the next evaluation cycle a concrete starting point.

Use the next engagement to settle the next uncertainty

A Production Pilot is useful when a specific quality, integration, or operating question still determines the build. Custom AI Development can connect a defined scope to a production application. Managed AI Operations supports continuing responsibilities under an agreed service scope.

Bring the existing prototype, representative cases, observed failures, intended authority, and accountable owner. Those inputs make the next decision concrete and keep the implementation focused on a workflow the business can sustain.