Article

The Production AI Agent Checklist: 8 Controls Before It Touches Real Work

A concrete, evidence-backed checklist for deciding whether an AI agent is ready to run real business work—not just a good demo.

8 min readWatch the video →

A working demo and a production system are not the same object, even when they're built from the same code. A demo has to succeed a handful of times in front of an audience. A production system has to fail safely, thousands of times, when nobody is watching. Confusing the two is one of the more expensive mistakes a business can make while adopting AI agents — and it's an avoidable one.

This article lays out eight controls to check before an AI agent touches real work: a bounded job, an accountable owner, the simplest adequate orchestration, controlled sources and tools, a truth set with evaluations, a human promise boundary, durable state with idempotency, and monitoring paired with an economic and lifecycle decision. These controls are a practical synthesis drawn from current research and engineering guidance — not a checklist published verbatim by any single source cited below.

Why a demo isn't a production system

The gap between a demo and production is structural, not cosmetic. A demo is run by someone who knows exactly what to type. Production is used by people who don't, encountering edge cases nobody scripted, hitting the system during outages, rate limits, and retries. An agent that looks flawless across ten scripted scenarios has told you almost nothing about how it behaves across the ten thousand unscripted ones it will actually face.

That's the practical reason a checklist matters more than a demo. The refreshed definition of what agentic AI actually is separates agents from chatbots and code-defined workflows; start there if you're still deciding whether an agent is the right category of tool for the problem.

What the adoption data actually shows

It helps to be precise about where the industry actually stands, because the framing shapes expectations. In the survey data summarized in Stanford's 2026 AI Index, 88% of respondents said their organization used AI in at least one business function, up from 78% in 2024. That's self-reported survey data — directional evidence of a trend, not a census of every company in existence.

The more important number sits right next to it. The same report shows scaled AI-agent use remaining in the single digits for nearly all of the business functions measured, with the technology sector standing out as a notable exception in several of them. Read those two figures together and a clearer picture emerges: using AI somewhere in the business has become common. Running an agent at scale, unattended, on a real workflow has not. That second gap is what this checklist addresses.

Why AI projects stall before they scale

Before building out the controls themselves, it's worth understanding the failure patterns they're designed against. RAND interviewed 65 experienced data scientists and engineers working on AI projects and identified a recurring set of root causes: teams misunderstanding the actual problem they were solving, optimizing the wrong metric, poor fit between the AI system and the existing workflow, inadequate data, and a technology-first approach rather than starting from the user's actual need.

These are planning and design failures, not exotic model limitations — which is exactly why they're addressable with structure rather than a bigger model or more compute. For a deeper look at this pattern across AI initiatives generally, see why AI programs fail. This article picks up where that one leaves off: assuming the project is worth doing, what has to be true before the resulting agent is safe to run on real work.

The eight controls

The following table lays out the eight controls in sequence. Each one closes a specific failure mode identified above.

#	Control	What it means in practice
1	One bounded job	An exact trigger, input, output, and definition of "done" — not an open-ended mission.
2	One accountable owner	A named person who maintains the agent and owns its exceptions.
3	The simplest adequate orchestration	A deterministic workflow before open-ended autonomy; add flexibility only where the job requires it.
4	Controlled sources and tools	Authoritative inputs, least-privilege access, reversible actions where possible.
5	A truth set and evaluations	Representative cases, deliberately hard edge cases, and explicit graders — checked before deployment.
6	A human promise boundary	A stop-or-escalate rule for decisions that are consequential, ambiguous, irreversible, relational, or that move money.
7	Durable state and idempotency	Retries can't duplicate writes or erase the audit trail.
8	Monitoring, recovery, economics, and lifecycle	Health checks, drift detection, incident response, a working kill switch, a cost/accuracy baseline, and a retirement rule.

One bounded job and one accountable owner

Scope discipline is the foundation everything else depends on. Anthropic's engineering guidance on building agents notes that its most successful customer implementations used simple, composable patterns rather than complex frameworks, and recommends starting with the simplest solution that meets the actual need. A tightly bounded job is what makes the rest of the checklist testable — an open-ended mandate can't be evaluated the same way a defined task can.

Ownership matters just as much. OpenAI's guide for business leaders working with agents lists purpose, scope, ownership, coordination, and lifecycle as the basic questions a team needs to answer before deployment. If there's no specific person accountable for what the agent does when it hits something unexpected, the agent isn't ready — regardless of how well it performed in testing.

Controlled sources, tools, and evaluation before launch

An agent's outputs are only as trustworthy as its inputs and its access. OpenAI's practical guide to building agents recommends layered guardrails combined with authentication, authorization, and access controls — deliberate design of what the agent can reach and what it can do, rather than default permissions.

Evaluation deserves particular care with agents, because the standard playbook for grading a single AI response doesn't transfer cleanly. Anthropic's guidance on evaluating agents points out that multi-turn agents modify state as they operate and can compound small errors into larger ones over the course of a task — which makes evaluation meaningfully more complex than single-response grading. A truth set built for a chatbot won't catch the failure modes specific to an agent that takes multiple actions in sequence.

The human promise boundary

This control is frequently misapplied in both directions. Some teams try to keep a human in the loop for every action, which defeats the purpose of automation. Others remove human oversight entirely because the demo never needed it. Neither is right. The boundary should be set by consequence and reversibility: decisions that are ambiguous, irreversible, relational, or that move money warrant a stop-and-escalate rule. Routine, reversible, low-stakes actions generally shouldn't.

Durable state, idempotency, and the retry problem

This is the control most often skipped because it doesn't show up in a demo at all. A demo rarely tests what happens when a network call times out and the system retries automatically. In production, that's routine. If a retry can duplicate a write — send a duplicate order, issue a duplicate charge, send a duplicate message — the agent will eventually cause a real, visible error, and it will do so silently until someone notices the duplicate. Idempotent operations and a durable audit trail are what prevent that failure from compounding unnoticed.

Monitoring, recovery, economics, and the lifecycle decision

Deployment isn't the finish line. NIST's AI Risk Management Framework calls for testing before and during operation, post-deployment monitoring, the ability to override or deactivate a system, incident response, recovery, and change management, organized around four functions: Govern, Map, Measure, and Manage. NIST is explicit that this framework is voluntary and not intended as a simple ordered checklist — the eight controls in this article are a practical synthesis informed by that framework, not a restatement of it.

OpenAI's guide adds a specific, actionable detail here: baseline time, cost, and accuracy before launch, and check performance again across multiple cycles rather than assuming day-one results hold steady. Pair that with a defined retirement rule — a point at which the agent gets re-evaluated, retired, or replaced — and the agent has an actual lifecycle instead of an indefinite, unexamined run.

A cross-sector reference point

It's worth noting that structured accountability for automated decision systems isn't unique to private-sector AI vendors. GAO's AI Accountability Framework, built for federal agencies, organizes accountability around governance, data, performance, and monitoring. It was developed for the public sector and isn't private-sector law, but the structural pattern — govern, verify data, measure performance, monitor continuously — echoes the same shape found in NIST's framework and in the vendor guidance cited above. That convergence across government and industry sources is part of why these eight controls hold up as a synthesis rather than a single vendor's opinion.

Applying the checklist to a real decision

None of these eight controls guarantee safety, compliance, profitability, or a successful deployment. What they provide is a specific, checkable question in place of a vague one. Instead of asking "is this agent good enough," a team can ask: which of these eight controls does it actually have, and which is it missing?

That question is more useful earlier in the process than later. If you're deciding where to start rather than how to harden something already built, how to pick your first AI project is the companion piece for that earlier decision point. And if the team wants a working session on applying controls like these to a specific workflow, that's the focus of the Agentic AI, Practically training.

Sources and further reading