Agents That Actually Work

A demo proves that an agent can complete a task once. A working system proves that it can complete the right task repeatedly, explain what it did, recover when the world changes, and know when to stop.

That difference is where most agent projects either become useful or quietly disappear. The model matters, but reliability comes from everything built around it: the mandate, tools, memory, permissions, evaluations, and path back to a person.

Increase autonomy only as fast as you increase evidence, control, and reversibility.

The demo-to-production gap

Demos happen in clean environments. The prompt is known, the happy path is visible, and a person is watching every move. Real business environments are untidy. Customer records are incomplete. APIs time out. Policies conflict. A seemingly harmless action can affect money, reputation, or a relationship.

Impressive demo	Reliable agent
Completes one curated task	Handles a defined class of tasks repeatedly
Optimizes for a convincing answer	Optimizes for a measurable business outcome
Assumes tools and data are available	Detects missing context and degraded systems
Hides the path behind the result	Leaves an attributable, reviewable trail
Depends on a person watching	Escalates deliberately when judgment is required

Start with a bounded mandate

Reliable autonomy begins with a precise job description. Define the outcome, the systems the agent may touch, the decisions it may make, and the conditions that require a human. A useful mandate answers five questions:

What does done mean? Use a testable outcome, not a vague instruction such as “handle the request.”
What context is authoritative? Name the records, policies, and sources the agent can trust.
What actions are allowed? Separate reading, drafting, recommending, and executing.
What is off limits? Make legal, financial, security, and reputational boundaries explicit.
When must it escalate? Define uncertainty, value, sensitivity, and exception thresholds before launch.

The strongest agents are not those given unlimited freedom. They are the ones given enough context and authority to finish a well-defined job.

The five layers of a production agent

1. Orchestration

The orchestrator turns an outcome into steps, maintains state between them, and decides what happens next. Keep plans inspectable. Long, invisible chains make failures difficult to reproduce and almost impossible to improve.

2. Constrained tools

Each tool should have a narrow purpose, typed inputs, validated outputs, and the least privilege needed. Prefer “create a refund draft” and “approve refund” as separate tools. That separation creates a natural control point.

3. Durable state

Agents need more than chat history. Store the task state, facts collected, actions attempted, approvals received, and artifacts produced. Durable state allows a run to resume without guessing after a timeout, handoff, or deployment.

4. Evaluation

Test the complete workflow, not only the final prose. Did it choose the right tool? Did it preserve constraints? Did it stop after success? Build an evaluation set from real tasks, edge cases, and every meaningful production failure.

5. Human control

A human handoff is part of the product, not evidence that the agent failed. Escalation should include the goal, work completed, evidence gathered, uncertainty, and the exact decision required. Never make the person reconstruct the run from raw logs.

Guardrails should shape the path

Weak guardrails reject a bad final answer. Strong guardrails make unsafe paths difficult to enter. Combine controls at several levels:

Identity: use scoped, short-lived credentials and attribute every external action.
Access: allow-list systems, records, destinations, and tool operations.
Economics: set cost, time, token, and transaction limits for each run.
Structure: validate generated data before it reaches another system.
Approval: require confirmation before consequential or irreversible actions.
Content: detect sensitive data, policy conflicts, prompt injection, and suspicious instructions.
Recovery: make writes idempotent and provide a rollback or compensating action.

A guardrail should produce a useful next state. When an action is blocked, the agent should know whether to revise, collect more evidence, request approval, or stop.

Observe outcomes, not activity

A long trace can prove that an agent was busy without proving it was useful. Capture the plan, tool calls, state transitions, model and prompt versions, costs, latency, approvals, and final outcome. Then connect that trace to business measures.

Useful operating metrics include task completion, human correction rate, escalation quality, repeat attempts, time to resolution, cost per successful outcome, and the frequency of each failure class. Review representative traces alongside the numbers so metrics remain connected to real behavior.

Design for failure

Retries, timeouts, idempotency, and graceful degradation belong in the original architecture. Classify failures so the system can respond appropriately:

Transient: retry with limits and backoff.
Missing context: retrieve more information or ask a focused question.
Policy conflict: stop and escalate with the conflicting evidence.
Unsafe or irreversible: require explicit approval.
Unknown: preserve state, fail closed, and make diagnosis easy.

Production agents must fail predictably, not creatively.

Earn autonomy in stages

Begin with a workflow that is frequent, measurable, and forgiving. Let the agent prepare work before it performs work. Increase authority only when the evidence supports it.

Observe: the agent watches the workflow and recommends actions.
Draft: it prepares outputs for human review.
Act with approval: it executes after an explicit checkpoint.
Act within limits: it handles low-risk cases and escalates exceptions.
Operate autonomously: it completes the bounded workflow with sampled review and continuous monitoring.

This ladder makes autonomy reversible. If quality falls or the environment changes, move the system down a level without abandoning the entire investment.

Production-readiness checklist

The task has an unambiguous definition of done.
Every tool has validated inputs, outputs, permissions, and failure behavior.
External actions are attributable and reviewable.
High-impact changes are reversible or require approval.
The agent recognizes uncertainty and escalates with context.
Runs can resume safely after interruption.
Success and failure are measured against a representative evaluation set.
Costs, latency, and retry behavior have explicit limits.
Production failures feed the evaluation set and improve the next release.
An owner can pause the system quickly.

The real goal

The goal is not maximum autonomy. It is dependable leverage: a system that completes useful work, makes its reasoning and actions inspectable, and preserves human control where judgment matters. When those qualities are designed in from the beginning, agents stop being demonstrations of possibility and start becoming part of how a business operates.