The Production Readiness Checklist for Agentic Workflows

Agents are the difference between AI that assists and AI that acts. They're also the difference between a system you can operate and a system that operates you.

The agentic workflow is a step change from the single model call. The model call asks one question and gets one answer. The agent chains calls together, makes decisions between them, calls tools, loops until it's done, and acts on the results. The model call has one failure mode: the wrong answer. The agent has many: the wrong decision, the infinite loop, the tool call that does something irreversible, the chain that goes off the rails one step past the point anyone was watching.

The checklist below is the one I use before an agent touches real workflows. Twenty points, five categories. If the agent clears them, it's ready for production. If it doesn't, it's an experiment with a deployment.

The agent acts. That means the agent has permissions — and the permissions have to be scoped like any other actor in your system.

The first four points: the agent has its own identity, not a shared human's. The identity is least-privilege — the agent can do what its task requires and nothing else. The permissions are scoped by task, not by role. And every action the agent takes is attributable — the audit trail shows which agent, which run, which request, which action. An agent that acts with a human's credentials, with broad permissions, unattributed, is a liability that hasn't happened yet.

The agent is a process, not a single call, so it needs process-level visibility.

The next four points: the agent's steps are logged, not just its final output. The agent emits the five signals, confidence, latency, escalation, override, and drift, at the step level, so the failing step is visible instead of the whole run being a mystery. The agent's state is inspectable mid-run, so you can see what it's doing while it's doing it. And the agent has a budget: a maximum number of steps, a maximum cost, a maximum duration. The agent that loops forever is an agent with no budget, and the budget is what turns the infinite loop from an incident into a log entry.

The agent is a system inside your system. It gets its own identity, its own limits, and its own telemetry — or it doesn't get production.

The agent acts, so the control surfaces have to be real.

Four more points: the agent has kill switches at every boundary: pause, rollback, hard stop, per the earlier article. The agent's irreversible actions, the sends, the deletes, the purchases, the external calls, are gated behind a human approval unless the stakes are proven low. The agent has escalation paths built in, so when confidence drops or the task leaves its lane, it hands off to a human instead of pushing through. And the agent has a blast-radius design: the failure of one run can't cascade across every other run.

The agent is a system that will fail, so the failure modes have to be designed for.

Four more points: the agent retries transient failures with backoff, and stops retrying when the failure is permanent. The agent handles partial failure — the tool call that succeeded and the one that didn't, handled explicitly, not by accident. The agent's outputs are validated against the schema and the quality bar before they act — the malformed output is caught before it becomes a malformed action. And the agent is idempotent where it matters: the retried run doesn't double-send, double-charge, double-create.

The agent runs continuously, so the governance has to run with it.

The final four points: the agent's behavior is versioned: the prompt, the model, the tool definitions, and the config are all under version control, so a change is a diff, not a mystery. The agent has a review cadence, meaning its outputs are sampled and reviewed by a human on a schedule, not trusted by default. The agent's decisions feed the eval suite, so every run is a data point and the suite catches the degradation before the customers do. And the agent has an owner — a named human accountable for its behavior, with a budget, who reviews it on the cadence. The ownerless agent is the one nobody notices until it does something expensive.

The question that closes the checklist

Twenty points is a lot to hold. The closing question condenses them: if this agent did something wrong right now, how would we know, and how fast could we stop it?

The answer is the checklist in one sentence. If the answer is "the audit log would show it, the signal would flag it, and the kill switch would stop it" — the agent is ready. If the answer is a pause — the agent needs more work, and the pause is the finding.

The agent that acts needs identity, limits, telemetry, control, reliability, and governance — twenty points, five categories, one closing question. Run the checklist before the agent touches real workflows. The agent will still surprise you. The checklist is how the surprises stay small.

Think this argument fits your event? Tell me about the room — the calendar is selective.