AI Agents in Production: Architecture Patterns

From demo to dependable

Demos reward autonomy: the agent figures everything out on stage. Production punishes it: an agent free to choose any action will eventually choose a wrong one, and at volume a small error rate becomes a daily incident. The design goal shifts from "can it act?" to "what can it be trusted to do, and how do we know when it should not?"

Pattern 1 — bounded tool use

Give the agent a small, typed, well-documented set of tools and nothing else. Each tool should do one thing, validate its inputs, and be safe to retry. A narrow tool surface is easier to secure, easier to evaluate and far easier to debug than an agent with a shell and an open API key.

Prefer many small tools over a few powerful ones. "Issue a refund up to $X for an order the user owns" is a tool. "Run any SQL" is a liability.

Pattern 2 — workflow over autonomy

Most production tasks are workflows, not open-ended missions. A deterministic orchestration — explicit steps, a defined state machine — with the model used at the specific steps that need judgement, is more reliable than a fully autonomous loop.

This is the reversal teams often resist: they want the agent to plan everything. In practice, the workflow knows the process and the model handles language and judgement within it, which bounds failure and makes behaviour testable.

Pattern 3 — plan, execute, verify

Where genuine multi-step autonomy is needed, separate the roles: one pass plans, another executes each step, and a verification pass checks the result against the goal before anything irreversible happens. Verification can be a model check against explicit rules, a deterministic assertion, or a required human approval.

The critical rule is that irreversible actions — payments, deletions, external messages — sit behind a gate, never inside the autonomous loop.

Guardrails: permissions, budgets and idempotency

• Permissions: scope every tool to the acting user’s rights; never let the agent exceed the user who triggered it.
• Budgets: cap steps, tokens, spend and wall-clock time per task so a loop cannot run away.
• Idempotency: make every mutating tool safe to call twice, because retries are inevitable.
• Approval gates: require a human for irreversible or high-value actions, with the proposed action shown clearly.

Observability and evaluation

You cannot operate what you cannot see. Record every step: the plan, each tool call with its arguments and result, the model’s reasoning where available, and the final outcome. That trace is how you debug, audit and improve.

Then maintain an evaluation set — real tasks with known-good outcomes — and run it on every change to the model, prompt or tools. Without it, you are shipping blind and discovering regressions in production.

Start narrow, then earn autonomy

The reliable path is to launch an agent that does one well-scoped job with a human checking its work, measure its accuracy against the evaluation set, and expand its autonomy only as the evidence justifies it. Autonomy is something an agent earns with a track record, not a setting you switch on.