The agent that does less

The most reliable agent I've shipped could do almost nothing, and that's exactly why people trusted it.

The most reliable agent I've shipped could not do anything that mattered on its own. It couldn't issue a refund, cancel a subscription, or change a single field in production. It read, it explained, it drafted, and then it stopped and handed the work back to a person. We almost killed it in planning for being too timid. It became the only agent in that product people actually left running.

That outcome stopped surprising me once I understood what we'd built. We hadn't shipped a smaller version of an autonomous agent. We'd shipped a different thing entirely: a tool that was honest about the exact size of its mandate, and never once exceeded it. Capability is easy to add and almost impossible to take back. The agents that survive contact with real users are the ones that did less than they could, on purpose.

The blast radius is the product

When you give an agent the ability to act, you are also giving it the ability to be wrong at scale. A model that drafts a reply that's 90 percent right is useful — a human reads it, fixes the last 10 percent, sends it. A model that sends that same reply is a liability, because the 10 percent it got wrong is now in a customer's inbox with your name on it, and there is no step where anyone looked.

The math people skip is that an agent's value is its competence multiplied by how much you let it touch, but its risk is its error rate multiplied by the same number. Scaling autonomy scales both. Most teams only model the upside. They imagine the 95 percent of cases the agent handles cleanly and forget that the 5 percent now ships unsupervised, at machine speed, before anyone notices a pattern.

The agent that does less shrinks the second number to near zero without touching the first. It still reads everything, still reasons over the whole case, still produces the answer. It just doesn't pull the trigger. You keep the competence and delete the blast radius.

Autonomy is a cost you pay in trust, and most products can't afford the bill.

What "less" actually looked like

The support agent I keep coming back to had exactly one job: read an incoming ticket, pull the relevant account state and policy, and draft a response with its reasoning attached. That's it. Every draft landed in the agent's queue, not the customer's inbox. A human approved, edited, or rejected it.

The discipline was in what we refused to build. No auto-send, even for cases the model rated trivial. No silent account lookups the agent couldn't show its work on. No action that couldn't be read in full before it happened. When the model wasn't confident, it said so in plain language and pointed at exactly which fact it was unsure about, rather than smoothing the uncertainty into fluent prose.

• →It surfaced the policy clause it relied on, quoted, not paraphrased.
• →It flagged the one field it couldn't verify instead of guessing past it.
• →It never took an action a human couldn't see, inspect, and reverse.

The confidence handling mattered more than anything else in the system. A low score didn't trigger some clever fallback chain. It just routed the case to a person with a note about why. The logic that did the most work was almost embarrassingly small.

const draft = await agent.draft(ticket);
if (draft.confidence < 0.7 || draft.touchesBilling) {
return escalateToHuman(draft);
}
return queueForApproval(draft);

The whole escalation policy. No fallback chain, just a handoff.

Notice what isn't there. There's no branch where the agent decides, on a borderline case, to act anyway because acting is faster. Borderline always means a person. The agent's freedom is bounded by a constant we chose, not by the model's mood on a given input.

Why restraint reads as trust

Here is the part that took me years to see clearly. Users don't trust a system because it's powerful. They trust it because they can predict what it will do, and because the worst case is something they can live with. An agent that might, on some unlucky input, take an action you can't undo is one you have to supervise constantly — which means it never actually saves you the work it promised.

The agent that does less is predictable by construction. Its mandate is small enough to hold in your head. You know the failure mode — a bad draft you'll catch on review — and you know it can't get worse than that. So you stop watching it like a hawk. You let it run. And the moment people stop supervising an agent, it finally starts paying for itself. The whole return on the thing was unlocked by the capability we deliberately withheld.

The teams shipping fully autonomous agents into high-stakes work are mostly discovering this in reverse. They launch with broad permissions, hit one expensive, unsupervised mistake, and quietly add the human back into the loop — except now it's a patch bolted onto a system designed to run without one, and it shows. It's far easier to widen a narrow mandate once trust is earned than to claw back a wide one after it's broken something.

Earn the next capability

None of this is an argument against autonomy forever. It's an argument about order. Start with the smallest mandate that's genuinely useful, prove the model is right as often as you claimed, and let the approval queue become your evidence. After a few thousand drafts you'll know precisely which case types the model nails every time — and those, specifically, are the ones you can let it send on its own. You'll have earned that with data instead of asserting it in a launch post.

The agent that does less isn't a compromise you settle for. It's the only version that gets to grow up. Restraint isn't the absence of ambition. It's how you ship something people will still be running next quarter.

Full-stack engineer and product designer. Writes about building products where the engineering and the design are the same job.