Building AI agents that do real work, not demos

TL;DR — A demo agent talks. A production agent acts — through narrow, well-named tools, least-privilege permissions, idempotent operations, retries, an evaluation loop, full logging, and a human checkpoint before anything irreversible. The model is the smallest, least important part. The plumbing around it is the work.

It’s easy to film an agent doing something impressive once. Wire a language model to a few APIs, give it a clever prompt, hit record, and it books a meeting or drafts an invoice. That clip gets the reactions. Then you put it in front of real inputs — a malformed email, a duplicate request, a name with an apostrophe — and the magic curdles. The gap between a demo and a system you’d actually leave running is not a smarter model. It’s everything around the model: the tools it can reach, the rails that keep it from doing harm, and the loop that tells you whether it’s still working. Here’s how we build agents we’re willing to trust with a real workflow.

Tools and actions, not conversation

A chatbot’s output is text. An agent’s output is change in the world — a row written, an email sent, a refund issued. That shift is the whole game, and it lives in how you define tools.

Good tools are narrow and unambiguous. “Manage the calendar” is a wish; create_event(start, end, title, attendees) is a tool. Each one does a single thing, validates its inputs, and returns a structured result the model can reason about. A scope this tight does three favors: the model picks the right tool more reliably, you can test each action in isolation, and a bad call fails small instead of cascading.

# A tool the model can't misuse much
name: refund_order
description: Issue a refund for a single order. Amount cannot exceed order total.
input:
  order_id: string      # required, must exist
  amount_cents: integer # required, > 0, <= order total
  reason: string        # required, free text for the audit log
returns: { refund_id, status }

Make every action idempotent wherever you can. Networks drop, timeouts fire, the model retries. If “send invoice” runs twice, the client shouldn’t get billed twice — pass an idempotency key, or check existing state before writing. This single discipline removes a whole category of 2 a.m. incidents.

Guardrails and least privilege

The most dangerous agent is the one with broad credentials and a friendly tone. Treat the model like a capable contractor you’ve known for a week: give it exactly the access the task needs, and nothing it doesn’t.

• Scope the credentials, not the prompt. A read-only report agent gets a read-only key. “Please don’t delete anything” in the system prompt is not a security control.
• Constrain at the tool boundary. Cap the refund amount, allowlist the recipients, reject writes outside the expected table. Enforce limits in code, where the model can’t talk its way past them.
• Separate dangerous tools. Reading data and deleting data should not live behind the same permission. Most workflows need far less write access than they’re given.
• Assume the input is adversarial. Prompt injection is real: a webpage or email can carry instructions aimed at your agent. The tool layer — not the model’s good intentions — is what stops it.

The model is the least trustworthy component in the system. Engineer everything else as if it will, eventually, be confidently wrong.

Verification, evaluation, and observability

A demo is judged by one good run. A production agent is judged by the thousand runs you never watch. You need to know it’s still working without staring at it — which means logging and evaluation are features, not afterthoughts.

Log every step: the inputs, the tool calls, the arguments, the results, the final action. When something goes wrong — and it will — you want a trace you can replay, not a shrug. Treat these logs as you would any sensitive data: they often contain customer information.

Then close the loop with an eval set — a fixed collection of real and tricky inputs with known-good outcomes. Run it on every prompt tweak, model swap, or tool change. Models drift; a new version that’s better at poetry can be worse at picking your refund_order tool. Without evals, you discover that drift in production, from a customer. With them, you catch it before deploy. Track a few honest numbers: task success rate, wrong-tool rate, and how often a human had to step in.

Human checkpoints for the irreversible

Full autonomy is the wrong default for anything you can’t undo. The reversible/irreversible line is the most useful one you can draw through an agent’s actions.

Reversible work — drafting a reply, tagging a ticket, proposing a schedule — can run unattended; the cost of a mistake is a quick correction. Irreversible work — sending money, deleting records, emailing a client, signing a document — should pause for a human until the agent has earned trust on that specific action, measured by your evals. The pattern is simple: the agent proposes, a person approves, the action fires with the human’s decision logged alongside it.

This isn’t a lack of ambition. It’s how you ship something real this quarter instead of chasing a fully autonomous version that never quite arrives. Move the checkpoint earlier as the data justifies it.

The takeaway

An agent worth trusting isn’t a smarter chatbot — it’s a small, well-instrumented machine. Narrow tools with validated inputs. Idempotent actions and retries. Least-privilege credentials enforced in code. Logs you can replay and an eval set you run on every change. A human in the loop for anything you can’t take back. Get that scaffolding right and a modest model does genuinely useful work, reliably, while you sleep. Skip it, and the smartest model on the market still only gives you a great demo.