The demo where an agent runs a whole process leaves out what happens when it gets something wrong. Why we keep our agents small, and what that costs us.
You have seen the demo. An agent reads an incoming email, looks up the contract, raises an invoice and books the payment, without anyone touching a thing. It looks convincing, and the question that follows is a fair one: what happens on the day it gets something wrong? Our position is that an agent earns its place by doing a narrow task well, not by acting on its own.
What the demo leaves out
An autonomous process run from start to finish leaves a trail of steps, but no explanation. Afterwards, nobody can say for certain why the agent chose that supplier, ignored that clause or granted that discount. You can reread the prompt and the intermediate outputs, but what you reconstruct is still a guess about the reasoning. For an auditor, a lawyer or a customer filing a complaint, that is not enough.
The second problem is one of proportion. An agent that handles a pile of routine cases correctly saves hours. One payment to the wrong account, or one commitment to a customer that the company cannot honour, costs more than all those hours put together. A language model also rarely gets things wrong hesitantly: the error arrives with the same confidence as the right answers, and in a chain without checks the next step takes it on without question.
What we build instead
The agents we deploy in companies today are given a clearly bounded job. They read incoming documents, classify them, extract the fields, route them to the right place and flag whatever they are unsure of. Anything that touches money, contracts, legal claims or a commitment to a customer goes to a person. That boundary rests on three design choices.
A fixed boundary: an explicit list of systems and fields the agent may read or write, and nothing else
A confidence threshold per field, below which the agent passes the case on rather than guessing
An approval step that takes a few seconds, because the agent shows the source with every proposal: the page, the sentence, the table cell
That last choice does most of the work. A reviewer who sees the highlighted line from the invoice right next to the proposed amount has nothing to look up and can decide at a glance. We pay a price for this: our demos are less spectacular, and tuning thresholds on real documents takes a lot of time.
An agent that knows when to stop is worth more than an agent that can do everything.
The strongest counter-argument
Approval steps slow the process down, and someone who clicks approve all day eventually stops looking. We take that objection seriously. A check that people sign off blindly is worse than no check at all, because it suggests a certainty that is not there. That comes down to how the approval is designed, though, and the design can be different.
In our systems, the reviewer sees only the cases below the threshold and the cases that touch the agent's boundary. The rest goes through and is spot-checked. We also track how often the reviewer rejects the agent's proposal: if that figure drops to zero, either the threshold is too cautious or people are rubber-stamping, and the spot checks tell us which. If you want to deploy an agent, start with one document stream and that measurement, and only then look at how much can run without a person.
Have a project in mind?
Tell us what you're trying to build. A sentence is enough to start the conversation.
