Amplify or delegate
When can work be handed to an AI agent, and when should the model only amplify what you do? It comes down to who holds the acceptance test: the check that says whether the work is done. Three ideas lead there, in order.
The cost of quality
Every acceptance test makes two kinds of mistake. It lets some bad work through, and it rejects some good work. Where you set the pass mark trades one for the other: a stricter mark lets less bad work through but rejects more good work. What each mistake costs decides where the mark belongs.
Take a goal of middling complexity, such as reviewing a contract.
Moving the pass mark only trades one mistake for the other. Add up what the two cost and the total is a U, the shape quality managers know from Juran’s cost of quality: the cheapest pass mark sits at the bottom, and the higher the stakes, the stricter it is. Only a better test, written by someone who can recognise good work, pulls the curves apart and reduces both mistakes at once. The numbers are illustrative. When the acceptance test is your own judgement, how much you check is a trade of the same shape: How much should you check the AI’s work?
The nature of complexity
A better test pulls the curves apart, but there is a limit to how good a test can be, and complexity sets it. Suppose the work has a number of parts, and each can be done a number of ways. If each part can be checked on its own, the test needs one line per way per part: the number of parts times the number of ways. If the parts can only be judged together, the test has to cover every combination: the number of ways multiplied by itself once for every part. One count adds; the other multiplies.
Think of a lock with many dials. If each dial clicks when it is right, you open it dial by dial. If only the whole lock opens, you must try every combination.
Write the acceptance test out, one line for each thing it must check
Simple: checked part by part
6 parts × 3 ways: one page.
Complex: judged only as a whole
3 multiplied by itself 6 times.
If every atom could hold one line
With 6 parts, the complex test has fewer lines than there are atoms in a grain of sand. At 3 ways a part, it passes the atoms of the observable universe at 168 parts. Press play.
Each mark along the scale is ten times the one before. Adding a part adds a few lines to the simple test; it moves the complex test the same distance along the scale every time.
Four examples from Ashby and Beer
Forty lightbulbs
Five bulbs give 32 patterns. Forty give “more than a million million”. And the world, Beer adds, “does not consist of forty lightbulbs”.
A firm with 300 inputs and outputs
Beer calls 300 “highly conservative” for any firm. Turn the whole Earth into a computer and run it for its entire history, and it handles about 10⁹² bits (after Bremermann). The task is not hard; it is impossible.
An airport
Only 100 variables, each in only 5 degrees. Ashby put the second figure at “one bit for every atom in the universe”, by the estimate of his day; today’s is nearer 10⁸⁰.
A thousand components
A hundred possibilities each. A machine a million times faster barely helps the second figure. Only selecting part by part does.
Most work sits in between
A contract’s clauses can mostly be checked one at a time, but the price, the warranties and the indemnity have to be read together. Each group of parts that must be judged together multiplies the size of the test instead of adding to it. While the groups stay small, a test can still be written group by group. As they grow, any test that can be written starts to see good and bad work as alike, and the two curves of step 1 slide together.
The same expert writing the test, from the simplest goal on the left to the most complex on the right.
Amplify or delegate
Put the two together. The complexity of the goal sets how far apart good and bad work can be told; the stakes set what a mistake costs; the test is set at its cheapest pass mark. If the mistakes it still makes are within what the stakes and the job can bear, the test can be handed to an agent. If not, you hold it, and the model amplifies what you do.
Amplifier this job
Delegation
In Ashby’s notation (1956): the world is X, the model S, the context window the channel G, the acceptance test g, its two verdicts γ₁ (not yet) and γ₂ (done), and the goal η. The model comes to rest only on γ₂, so whoever writes g decides where it rests.
- J. M. Juran, Quality Control Handbook (1951): the cost of quality.
- W. R. Ashby, “Design for an intelligence-amplifier” (1956), in Shannon and McCarthy (eds), Automata Studies, §10.
- W. R. Ashby, “Setting goals in cybernetic systems” (1972).
- S. Beer, Brain of the Firm, 2nd edn (1981), ch. 3, “The dimensions of the problem”.
- R. S. O’Rourke, “The LLM as variety transducer”, Kybernetes (2026).
The decision does not turn on how capable the model is. It turns on three things you can examine before any agent is built: how far the work can be checked part by part, what a mistake costs, and whether someone who can recognise good work has written the acceptance test. Where they line up, an agent can do the work under supervision, with access to the world limited to the risk. Where they do not, the model is still valuable as an amplifier: you hold the test, act, see how the world responds, and adjust.
That is what a Diagnose engagement looks at — one workflow, one team, a week or two: which parts of the work can be checked on their own and which must be judged together, what each kind of mistake costs, and who can write the acceptance test. A Build engagement then writes that test with your experts, sets the agent’s limits to match the risk, and keeps the test in your hands where the work is too complex to hand over.