A working agent demo takes an afternoon. A production agent takes real engineering, because production is where the interesting failures live. The demo has one happy path and a friendly audience. Production has every input a real user can type, every API that can time out, and every edge case nobody thought to script.
Tools are contracts
Every tool an agent can call is a contract with your systems. We define tight input and output schemas, validate both, and fail loudly instead of letting the agent improvise around a broken call. A tool that returns an ambiguous error teaches the agent to guess, and a guessing agent in a system with side effects is exactly the failure mode you built the guardrails to prevent.
The instinct in a demo is to make tools flexible and forgiving, accepting loosely structured input so the happy path always works. In production that flexibility is a liability. A tool that silently accepts malformed input and does something reasonable-but-wrong is far more dangerous than one that rejects the call outright and forces the agent to retry with a correct request.
Keep a human in the loop
For anything consequential, the agent proposes and a person approves. We wire approvals into the workflow so the human step is fast and unavoidable, not an afterthought bolted on after the first incident. The approval has to be genuinely low-friction, or people will start rubber-stamping it, which defeats the purpose entirely.
The right question is not whether to have a human in the loop, it is where in the loop the human sits. Reviewing every single tool call does not scale and does not happen in practice. Reviewing only the irreversible, high-stakes actions, while letting the agent move freely through everything reversible and low-stakes, is what actually gets used.
- Scope the agent to a narrow, well-defined job rather than a vague mandate.
- Instrument every step so you can replay a failure exactly as it happened.
- Add approval gates before irreversible or externally visible actions.
- Set hard ceilings on loops, token spend, and tool calls so a bad run stops itself.
Scope beats capability
It is tempting to build one agent that can do everything: answer questions, take actions, escalate issues, generate reports. That agent is nearly impossible to test, because the space of things it might do is unbounded. An agent scoped to one job, with a clearly defined success condition, is testable, debuggable, and far more likely to behave the same way twice.
When a broader capability is genuinely needed, composing several narrow agents behind an orchestration layer produces more predictable behavior than one agent with a sprawling mandate and a long list of tools it rarely uses correctly.
The best agents feel boring in production. Boring means predictable, and predictable is what earns trust.
Observability is not optional
When an agent does something surprising, you need to see exactly what it saw and why it chose what it chose. We log the full trace of every run, including the tool calls, the intermediate reasoning, and the final action, so debugging is reading a transcript rather than guessing at a black box.
That trace is also how you improve. Real runs surface the prompts, tools, and edge cases that no amount of upfront design would have predicted, and each one becomes a fix or a new guardrail. Teams that skip this step end up debugging agent behavior from user complaints instead of from logs, which is slower, less precise, and far more stressful for everyone involved.
Set limits before you need them
Every agentic loop needs an exit condition that does not depend on the agent deciding to stop. A hard ceiling on iterations, on tool calls, and on token spend turns a runaway loop from an incident into a non-event. These limits cost nothing when the agent is behaving well and save you when it is not, which is exactly the kind of guardrail that is easy to skip until the day you need it.
None of this is what makes a good agent demo. It is what makes an agent something you can leave running unattended, which is the actual bar for production.
Failure recovery has to be designed, not assumed
Agents fail differently than traditional software. A traditional service either returns a result or throws an error, and both are easy to handle. An agent can return something that looks like a valid result but is subtly wrong, or it can get stuck in a loop that technically makes progress on every iteration without ever reaching the goal. Neither of those failure modes trips a conventional error handler.
Designing for this means deciding upfront what a stuck agent looks like and building a detector for it, not waiting to notice the pattern after it has already happened in production. It also means deciding what happens after detection: does the agent retry with different context, escalate to a human, or roll back whatever partial work it already did. Leaving that decision undefined means it gets made ad hoc, under pressure, during an actual incident.
Start narrower than feels necessary
Teams that have shipped a production agent successfully almost universally say the same thing in hindsight: the first version should have done less. The instinct is to build toward the full vision immediately, because the full vision is what got everyone excited in the first place. But an agent that does one narrow thing reliably earns the trust that makes it possible to expand its scope later.
An agent that tries to do everything from day one, and gets some fraction of it wrong in ways nobody predicted, spends its early production life eroding trust instead of building it. The narrow version is not a compromise, it is the actual fastest path to the broader capability, because it is the version that survives contact with real usage.