A successful demo is the start of the review
An agent can look convincing while operating on a clean example with a developer watching every step. Production introduces incomplete requests, conflicting records, expired permissions, slow APIs, repeated events, model changes, and users who do not know how the system was designed.
Use this checklist before the agent can make production changes. The goal is not to remove all uncertainty. It is to define what the agent may do, measure how it behaves, and give the operating team a safe way to intervene.
The job and boundary are explicit
- The agent has one named job and an accountable business owner.
- The trigger, required inputs, allowed outcomes, and stop conditions are documented.
- The team has decided which decisions the agent can make, which require approval, and which remain entirely human.
- A deterministic workflow was considered before model judgment was introduced.
If the agent is expected to improve a broad department rather than complete a defined job, the release boundary is still too loose.
Representative evaluation cases exist
- The test set includes ordinary cases, difficult cases, missing information, conflicting information, and known failures.
- Acceptable outcomes and forbidden behavior are written down.
- Tool selection, tool inputs, final results, and escalation decisions are evaluated. The text response is only one part of the behaviour.
- Evaluations can be rerun when the model, prompt, retrieval, tool, or workflow changes.
- A person reviews a sample where automated scoring cannot establish quality.
Evaluation should reflect the distribution of real work. A set built only from successful demo examples creates false confidence.
Data access follows identity and purpose
- The agent receives only the context required for its job.
- User and service identities are authenticated and authorized before data is retrieved or changed.
- Sensitive fields are filtered, masked, or excluded where they are not required.
- Retrieval respects document and record permissions instead of treating the knowledge base as public to every user.
- Data retention and model-provider handling match the company's policy.
The agent should not become a new route around access controls that already exist in the product or organization.
Every tool is narrow and validated
- Each tool performs one clear action with a documented input and output contract.
- Inputs are validated in code before an external system is called.
- Read tools and write tools are separated where practical.
- Consequential or irreversible actions require approval or stronger authorization.
- Timeouts, retries, rate limits, partial failures, and duplicate calls have defined behavior.
- Every action produces an audit record with the relevant actor, inputs, result, and workflow identifier.
A model should choose from safe capabilities. It should not receive a general shell, unrestricted database access, or a broad API token because that is convenient during development.
Workflow state survives failure
- Each run has a durable identifier and visible status.
- Repeated events do not create duplicate work or repeated external actions.
- The system can resume, retry, cancel, or replay a case deliberately.
- Partial progress is preserved when a later step fails.
- A deterministic fallback or human queue exists for cases the agent cannot complete.
This is ordinary distributed-systems work, but it becomes more important when a model can choose different paths for similar inputs.
Operators can understand and control the agent
- The operating team can see what context the agent used and which tools it called.
- Uncertainty and escalation reasons are visible without reading raw logs.
- Reviewers can approve, correct, reject, or return the case.
- Support staff know how to stop the agent or disable a tool.
- Corrections are captured as evaluation evidence rather than disappearing in chat or email.
Human review only works if the reviewer receives the context required to make the decision and has a clear place to act.
Monitoring covers software and business behavior
- The team tracks completion, failure, escalation, correction, and replay rates.
- Model quality measures are tied to the workflow's acceptance criteria.
- Latency and cost are measured per completed outcome, not only per model call.
- Tool errors, permission failures, retrieval gaps, and policy violations create alerts appropriate to their impact.
- The business baseline remains visible so the team can tell whether the agent improved cycle time, manual touches, quality, or another intended result.
An agent that passes model evaluations but creates more review work is not delivering the operating outcome.
Release and rollback are deliberate
- The agent can begin with limited users, cases, tools, or action permissions.
- Release gates define the minimum quality and reliability required for expansion.
- Model and prompt versions are recorded for each run.
- A rollback can restore the previous system behavior without losing workflow state.
- The owner, on-call path, incident process, and change approval process are clear.
Production readiness is not a one-time certificate. The checklist should run again when the agent gains a new tool, data source, user group, or responsibility.
Ship the smallest safe production boundary
The first release should complete one useful path with evidence, controls, and an owner. Expansion should follow production behavior rather than a larger demo.
Read what changes between an AI prototype and production for the surrounding system, or see how OriginLines approaches custom AI agent development.