Skip to content
← All insights
Agentic ExecutionFEB 19, 20265 min read

Agents propose. Systems decide.

The question is not how much an agent is allowed to do. It is what an agent is allowed to decide — and the answer should never include certifying its own work.

Algodyne

The useful division of labour with a stochastic system is not how much work it may do. It is which questions it may answer. An agent can open the work, write the change, run the checks, and argue for the result. Whether that result moves the system is a different question, and it belongs to something deterministic.

Collapsing those two produces most of the disappointment people report with agents. The model is genuinely capable at the first and structurally unsuited to the second, because anything grading its own homework will pass. The failure is not that the model lies. It is that fluency and correctness are only loosely correlated, and a system that accepts fluency as evidence has no way to tell the difference.

Four distinctions worth keeping apart

Automation is not autonomy. Automation removes keystrokes from a path someone already designed. Autonomy means the path itself is chosen at runtime. A team that automates and calls it autonomy will be surprised the first time the right answer was to do something else entirely.

Autonomy is not accountability. A system can choose its own path and still leave nobody answerable for the outcome. Accountability requires that a specific person or gate certified the result, and that the certification is recoverable afterwards.

Prompt quality is not system quality. A better prompt shifts the distribution of outputs. It does nothing to the floor. If the worst plausible output is unacceptable and nothing catches it, the prompt was never the problem.

A demo is not a product. A demo is a single traversal of the happy path, performed by someone who knows where the edges are. Each of these pairs is easy to conflate under deadline, and each conflation fails somewhere different — the first in scope, the second in blame, the third in reliability, the fourth in revenue.

Where the authority sits

A valid state transition needs five things: an allowed path from the current state, an evaluated gate, the required evidence, a persisted result, and an audit event. An agent supplies the work and proposes the transition. It is never the thing that certifies it.

This sounds like bureaucracy and is the opposite, because the cost profile is inverted from a human review process. The gate is code. It runs in seconds, it runs identically every time, and it does not get tired at the end of a long week. What makes review expensive is the human attention it consumes; what makes a gate cheap is that it consumes none until it fails.

Human override stays available, because judgment sometimes has to beat the instrument. It is explicit, recorded, and attached to the exception that justified it — a different act from quietly lowering the bar, and one that leaves a different trace. The distinction matters more than it looks: a recorded override is a decision the portfolio can learn from, while a moved threshold is a decision nobody will ever find again.

The economics underneath

Generation is close to free. Verification is not. That asymmetry is the single most important fact about building with agents, and almost every architectural choice follows from it.

If generation is free and verification is expensive, throughput is bounded by verification. Adding more generation capacity to a system with a fixed verification budget does not increase output; it increases the queue of unverified work, which is worse than no work, because unverified work looks like progress and is not.

The practical consequence is that agent autonomy can rise only as fast as validation quality rises. Those two numbers are coupled. Teams that treat them as independent end up supervising more than they automated, and conclude that agents do not work — when what actually happened is that they moved cost from generation to review without noticing.

Routing on the cost of being wrong

The useful question when deciding what an agent should touch is not whether the task is hard. It is whether the result has a cheap correctness check.

Where a result can be verified by running something — a test, a query, a build, a scan, a diff against a known-good artifact — agent output is close to free to accept or reject, and throughput rises sharply. The check is the product; the generation is incidental.

Where verification requires an expert to read carefully and think, the supervision cost usually exceeds the generation saving. This is not an argument against using agents on that work. It is an argument for knowing which regime you are in before you start, and for measuring the saving after the review cost rather than before it.

So work gets routed rather than dispatched. Classify the intent, estimate the risk, identify the context the work will need, choose an executor — local model, hosted model, deterministic script, or a person — set a budget, and attach the validation requirement up front. A router that only dispatches is a queue. A router that attaches validation is a control plane.

What this leaves for people

The obvious objection is that this reduces the human to a rubber stamp. In practice the opposite happens, because everything mechanical has been moved into gates and what remains is the part that was always the job: deciding which systems deserve to exist, which markets are worth entering, what good looks like, and when the evidence is strong enough to commit capital.

None of those have a cheap correctness check. None of them should be delegated. The point of putting deterministic authority underneath stochastic execution is not to remove judgment from the loop — it is to stop spending judgment on things a gate could have caught.