Autonomy is not the hard part

The standard agent demo is a long unattended run. A goal goes in, the screen fills with steps, and some minutes later a finished thing comes out. It is genuinely impressive, and it is the wrong thing to be impressed by, because the demo is run against an account with nothing to lose.

Capability got cheap; consequence did not

Two years ago, getting a model to plan a multi-step job and call tools in order was the whole problem. It is now close to a commodity: the same loop can be assembled in an afternoon from parts anyone can install. What has not moved at all is the cost of a wrong action against a real customer, a real ledger or a real inbox.

So the interesting question stopped being how far an agent can run on its own. It became how much damage a run can do before a person sees it.

Blast radius is the measure that matters

Blast radius is the set of things an agent can change that you cannot easily undo. It is a property of the permissions and the policy, not of the model, and it is the number you should be able to state before you connect an account. Four questions get you there:

• What can it change without asking, and can that change be reversed in one step by a person who notices an hour later?
• What is the largest single action it could take right now, in money and in reach? One email is not one hundred emails, and a draft is not a send.
• How much can it spend before something stops it, and is the stop a hard one or a warning in a log nobody reads?
• Who is on the other side of a mistake: an internal document, a colleague, or a customer who will remember it?

The three failures that actually happen

In practice, the trouble is rarely a dramatic misunderstanding of the goal. It is one of three dull things.

1. The right action to the wrong recipient. A correct, well-written message that lands with a person it should never have reached. Nothing in the model's reasoning looks wrong, because nothing in it was.
2. Confident wrong content. A number that came from the wrong column, a policy quoted from an old page, a name that belongs to a different account. Fluent and plausible is exactly what makes it expensive.
3. A quiet overrun. A run that retries, reads more than it needed, and costs several times its estimate without ever failing. Nobody notices until the invoice.

What we bound, instead of the autonomy

Delagents does not try to make agents less capable. It makes the edges of a run explicit, in three places.

• Budgets with a real stop. Every delegation carries a cap. At eighty percent of it the agent files a checkpoint; at one hundred percent it stops. It never finishes quietly over budget, and each step's price appears as it happens.
• Access that is granted, never requested. A connection holds the scopes an admin approved, and each agent gets a subset of those. An agent cannot widen its own access, and its first run is draft-only whatever its instructions say. See integrations and scopes.
• A floor under every policy. Eight kinds of action always stop for a person: a first message to an outsider, a payment, a deletion, a permission change, a new integration, signing or buying, publishing, and acting in another workspace. A workspace can tighten that list; nobody can loosen it. It is set out on the security page.

The demo that should impress you

Not the run that goes all the way. The one that stops halfway, shows you a message it is about to send, tells you what the run has cost so far, and waits. That is harder to build than the unattended version, because it requires the system to know which of its own actions are consequential, and to describe one of them to a person in a few seconds of reading.

Autonomy is a slider. Where you put it is a business decision, and for most of the work that matters it belongs well short of the end. What you cannot move afterwards is whether the product was built to stop at all.

Related: the approval is the product on why the checkpoint, and not the builder, is the centre of a delegation tool.