Every enterprise agent conversation I sit in eventually reaches the same question, and it is almost always asked wrong. Someone says: should the agent be allowed to act, or just recommend?

That framing has two options in it. The real design has five, and the gap between two and five is most of what separates an agent system that reaches production from one that stalls in a steering committee.

The interesting boundary is not where you think

We have collectively agreed that agent reasoning is unreliable in ways that require handling. Hallucination, brittleness, prompt injection — the discourse is mature and the mitigations are well known. Ground it, scope its context, validate its output, allowlist its tools.

But notice what all of that governs: the production of an output. Almost none of it governs what happens next. An agent produces a claim with some internal confidence, and then the system does something with it — and in most implementations, what it does is a single boolean decided at design time. Either this agent writes to the system of record or it doesn’t.

That boolean is where enterprise agent programmes actually die. Set it to false and you have built an expensive suggestion box; users try it twice and go back to the spreadsheet. Set it to true and you have handed a probabilistic component write access to a system of record, which no risk function will approve twice, and which will eventually be correct to have refused.

The boolean is not a governance failure. It is a modelling failure. We modelled a continuous variable as a flag.

A ladder instead

Replace the flag with a disposition ladder — a decision the system makes about each individual output rather than a decision an architect makes about each agent:

  1. Show it as information. Below the bar for action, still worth a human’s attention.
  2. Propose it as a recommendation. Advisory, with reasoning attached.
  3. Convert it to a task. Actionable, assigned, tracked — but a human owns the doing.
  4. Execute it, within a bounded policy. The system acts, and verifies that it acted.
  5. Route it to human review. Low confidence, failed validation, or policy-sensitive.

The inputs to that decision are not just confidence. They are confidence and the authority of the invoking actor and the risk of the action and segregation-of-duties rules. The same claim, at the same confidence, from the same agent, resolves differently depending on who asked and what it would touch. That is not a complication — that is how every human approval hierarchy in the enterprise already works, and agent systems keep trying to be the exception.

Note that step five is not a failure branch. It is a first-class disposition, and its existence is what allows the other four to be tight. Systems without a review path have to make every other path permissive enough to handle the ambiguous cases, which is exactly backwards.

Exception over silence

One rule does more work than the rest combined: an ambiguous or failed result must surface as a visible exception, never as silent continuation.

Silent continuation is the worst failure mode an autonomous system has, and it is worse than a crash. A crash is noticed. A pipeline that quietly skipped the rule it couldn’t evaluate produces a clean-looking report with a hole in it, and the hole is discovered — if it is discovered — by an auditor, months later, at maximum cost. The same logic is why a validation system should answer every rule on every run including “cannot check”, rather than omitting what it couldn’t determine. An omission and a pass look identical downstream. Make refusal loud.

Progressive, and configured by the customer

The ladder also solves the adoption problem, which is really a trust problem, and trust is earned by evidence rather than granted by architecture.

So autonomy should be progressive: advisory first, then approval-based, then bounded-autonomous — with the thresholds held as tenant configuration rather than code. A cautious customer starts at advisory across the board. As outcomes accumulate, they widen the policy for the narrow, low-risk, high-volume decisions where the system has demonstrably been right, and they keep everything material on approval. Nobody forks the product. Nobody ships a new release. The dial moves because the evidence moved.

This is also the honest answer to a question customers ask and vendors dodge: what happens when it’s wrong? The answer is not “it won’t be.” The answer is: wrong outputs land at a rung where being wrong is survivable, every action is verified after the fact, unresolved failures become tasks rather than retrying forever, and the policy that let it act is a number your administrator set and can lower this afternoon.

Why this is a zero-trust argument

I have written before that zero trust is the right frame for the AI era, and this is the same argument one layer up.

Zero trust says: verify every request, grant least privilege, assume breach. The disposition ladder says the same about an agent’s conclusions rather than its network calls. Do not trust an output because it came from a component you trust — evaluate this specific output, against this specific actor’s authority, for this specific action’s risk, and grant it the least consequential disposition that is still useful. Assume some outputs will be wrong, and make wrongness recoverable by construction.

An agent that can only do what its invoking user could do, only when confidence and policy agree, only with an audit record of the evidence and the model version behind it, is not a diminished agent. It is the only kind that gets to keep running.

Autonomy is a dial. Ship the dial, not the switch — and let the customer turn it.

Reference implementations of the disposition ladder and exception-over-silence live in agent-governance-patterns — each pattern with a note on when not to use it.