What Actually Breaks When You Deploy Agents

I run agents in production across five businesses. Automation that reconciles invoices, pipelines that turn satellite passes into farmer advisories, research agents that read tender documents, a trading agent that sizes its own positions. Some of it works well enough that I no longer think about it. Some of it cost me money to learn.

The talks I get invited to give usually want the first half of that sentence. This essay is the second half.

An agent demo is a system with one happy path and an audience that will not test it.

The first failure is looping. An agent given a goal and a set of tools will, when it cannot achieve the goal, keep trying. It will rephrase, retry, call the same tool with slightly different arguments, and convince itself it is making progress. Nothing in its design tells it to stop and admit defeat. I have watched an agent spend real money doing this overnight. Every agent needs a step budget, a cost ceiling and an explicit way to fail loudly. Build the exit before you build the capability.

The second is tool calls with no failure path. In a demo the API returns. In production the API times out, or returns an empty array, or returns something structurally valid and factually wrong. A model handed a bad tool result will usually carry on and reason confidently from it, because nothing marks it as bad. So every tool needs to distinguish between no result, a failed call and a successful call, and the agent needs different instructions for each. This is unglamorous plumbing and it is most of the work.

The third is cost. Nobody models it. A workflow that costs a fraction of a cent per run looks free until it runs on every row of a table with thirty thousand farmers in it, several times a day, with a retry policy. I now estimate cost per run and multiply by realistic volume before building anything, because the difference between a viable product and an expensive hobby is often one order of magnitude in call count.

The fourth is verification. The output goes somewhere. A document, a message, a decision. If nobody checks it, the first time you find out it was wrong is when a customer tells you. The question I ask now is not whether the agent is accurate. It is what happens when it is wrong, who notices, and how fast. If the answer is nobody and never, the agent should not be writing to that destination.

Autonomy is not the goal. Correct output at acceptable cost with a known failure mode is the goal.

There is a fifth failure that is specific to operating here, and it is about latency and connectivity. An agent chain with six sequential model calls is fine on a fibre connection in an office. It is unusable for a field officer on a phone with two bars who needs an answer now. My rule has become that anything a user waits on runs in one call, and anything that needs a chain runs in the background and delivers its result later through a channel that tolerates delay.

So what does work?

Narrow scope beats general capability. An agent that does one job with three tools is reliable. The same model given fifteen tools and a vague mandate is not. Almost every system I have that runs unattended got there by being made smaller.

Deterministic code around a probabilistic core. The model does the part that genuinely needs judgment, which is usually reading unstructured input or drafting language. Everything before and after it, the routing, the validation, the arithmetic, the writing to a database, is ordinary code. n8n is useful to me precisely because it makes that boundary visible.

Humans at the point of consequence. Not reviewing everything, which defeats the purpose, but standing at the moment where an action becomes irreversible. Money moving, a message sending, a record being deleted. The agent prepares, a person approves. That single pattern has prevented more problems than any prompt I have written.

And build for the failure you expect. If the model is unavailable, what does the user see? If the answer is a spinner, you have not finished.

The teams getting value from this are not the ones with the best prompts. They are the ones who assumed it would break and designed for that.

None of this is a reason to wait. The capability is real and the leverage for a small team in a market like ours is genuinely large. I have shipped things with two people that would have needed twenty five years ago. But the leverage arrives through engineering discipline, not through the model, and the sooner that is understood the fewer expensive nights there are.