Agent demos are impressive because the failure cases are not shown. In production, an agent that can call tools is a system that takes actions with real consequences based on probabilistic reasoning, and the engineering that makes that acceptable is mostly about constraint rather than capability.
01Narrow beats general, every time
A general-purpose agent with fifteen tools and an open-ended instruction fails in ways nobody predicted, and each failure requires investigation because the reasoning path was different. A narrow agent with three tools and a specific job fails in a small number of ways you can enumerate and handle.
The productive pattern is several narrow agents rather than one capable one. Each is testable, each has a bounded blast radius, and when one misbehaves you know exactly which part of the system to look at.
| Decision | Broad agent | Narrow agent |
|---|---|---|
| Failure modes | Unbounded | Enumerable |
| Testing | Very hard | Feasible |
| Debugging a bad run | Reasoning archaeology | Small search space |
| Blast radius | Whatever the tools allow | Deliberately bounded |
| Prompt maintenance | Grows indefinitely | Stays small |
02Classify tools by reversibility
Reading data is safe. Writing to a draft is nearly safe. Sending an email to a customer, moving money, or deleting records are not, and the difference should be structural rather than left to the model's judgement.
Reads run freely. Reversible writes run with logging. Irreversible actions require confirmation, either from a human or from a deterministic rule that the model cannot argue with. That taxonomy, applied consistently, prevents most of the incidents that make organisations abandon agents entirely.
03Bound the loop
Agents get stuck. They repeat a failing tool call, oscillate between two approaches, or pursue a plan that cannot succeed. Without limits this continues until something else stops it, generating cost and occasionally side effects the whole time.
Cap iterations, cap wall-clock time, cap total token spend per task, and detect repetition explicitly. When a limit is hit, fail clearly and hand off to a human with the full trace rather than trying one more time.
| Limit | Typical value | Prevents |
|---|---|---|
| Max iterations | 8-15 | Infinite reasoning loops |
| Wall clock | 30-120s | User-facing hangs |
| Token budget per task | Task-specific | Runaway cost |
| Repeated identical tool call | 2 | Stuck retry loops |
| Distinct tools per run | Task-specific | Unexpected capability chaining |
04You need the trace, not the answer
When an agent does something wrong, the output alone tells you nothing about why. You need the full sequence: every model call, every tool invocation with arguments and results, and the reasoning between them. Without it, debugging is guesswork.
Store traces for every production run, not just failures, because the interesting question is usually 'why did this one go differently from the hundred that worked'. Make them searchable by user, task and outcome. This is the single highest-value piece of infrastructure for anyone operating agents.
05Design the handoff before you need it
Some tasks will exceed the agent's competence, and the system should recognise that and hand over gracefully rather than producing a confident wrong result. That means a defined escalation path, with the full context transferred so the human is not starting from nothing.
Track the handoff rate as a headline metric. Rising means the agent is encountering situations outside its scope, which is either a scoping problem or a signal that the world has changed. Falling to zero is not necessarily good news - it can mean the agent has stopped recognising its own limits.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer