The word that comes up most in agent demos is "autonomous," and it is almost always said as praise: look, it decides on its own, you do not have to approve anything. But autonomy is not a virtue the agent has; it is a constraint you removed. Every task an agent can do without asking permission is a permission you stopped requiring, and when you say it that way, out loud, it stops sounding like an achievement and starts sounding like an architecture decision. Which is exactly what it is.
This essay builds on the argument Gregor Hohpe makes when he says architecture is a game of satisfying constraints: technical progress keeps lifting limits we used to treat as fixed, and every time one falls you have to recalibrate the heuristics that depended on it. Hohpe says this about technical constraints. I want to apply it to a constraint that is not technical but about authority: how much an agent can do without a human signing off. And I want to add something his argument does not say, because it did not have to: that a constraint being removable does not mean it is wise to remove it. Sometimes the architect puts it back, on purpose, under a different name.
Autonomy is signing authority you delegate
When someone new joins a company, nobody hands them an unlimited checkbook on day one. They get signing authority: they can approve spending up to a certain amount without asking, and above that amount they need someone else. The limit is set before the first transaction, not after reviewing their purchases. It rises with track record: after two years with a clean history, that limit is higher. And the control is not in reviewing each invoice one by one (that does not scale and everyone knows it), it is in the number. In the limit itself.
An AI agent is exactly that: a figure you delegate signing authority to. "It can open a pull request but not merge it" is an approval limit. "It can deploy to staging but not to production" is another. "It can touch the read replica but not run migrations" is another still. When someone says they want a "more autonomous" agent, what they are asking for is to raise its signing limit. And that is the point: you are not improving the agent, you are signing on its behalf in advance, without yet knowing what it will sign.
The metaphor passes the test Hohpe himself demands in The Mighty Metaphor: it is not enough for the image to look alike, the dynamics have to match. And they match where it counts. Signing authority is granted cheap: it is changing a number, checking a box, widening an IAM role. It is clawed back expensive: by the time you discover the limit was too high, there are already transactions signed under that authority, and undoing them costs far more than avoiding them would have. The asymmetry between granting and clawing back is the same on both sides, and everything else follows from it.
Reviewing each action afterward does not scale; setting the limit up front does. The control moves from the end to the start.
Why control has to live in the limit and not in the review
If you had to approve every move the new hire made, you would not have given them signing authority: you would have given them a form. Signing authority exists precisely so you do not have to look at each transaction, and in exchange it puts all the responsibility in one place: getting the number right, up front.
With agents this is not a preference, it is physics. A human reviews a handful of actions an hour with real attention; an agent runs hundreds. Reviewing each action after it happens is the strategy that guarantees you fall behind, because the agent produces faster than you can read, just as I already argued in Code Is Inventory, Not an Asset: there the bottleneck was understanding the volume; here it is containing the reach. They are two distinct problems of the same agent. One is how much it produces; this one is how far what it produces can go.
That is why the place you set the limit is not the code the agent writes, but the boundary the agent cannot cross. A platform like Amazon Bedrock AgentCore exists for that: identity, permissions and guardrails defined before the agent acts, not controls that review what it already did. And the spec-driven flow of Kiro does the same thing from the other end: the spec is the boundary, the contract that says what is inside the signing authority and what stays out. In both cases, the architect job moved from watching to calibrating. From reviewing invoices to setting the number.
I know what you are about to say
But a more autonomous agent ships faster. Every approval I take away is friction I take away, and friction is what I am paying to eliminate.
It is true in the short term, and it is the whole trap. Raising the signing limit always speeds things up until the day it does not. The employee with unlimited authority also closes deals faster, until they sign one that sinks the quarter; and then the speed you gained for months is eaten by a single transaction that should never have had permission to exist. What you buy by widening autonomy is not speed, it is speed plus a tail of risk you do not see until it materializes.
And there is an asymmetry the rush hides. When the limit is too low, the cost is visible and bounded: the agent stops, someone approves by hand, you lose minutes. When the limit is too high, the cost is invisible until it arrives, and then it is not bounded: it is everything the agent could touch while nobody was looking. A conservative limit fails small and loud; a generous limit fails big and silent. They are not two symmetric errors you can average out.
Autonomy is not a capability you give the agent: it is a constraint you remove from yourself, and you will want it back on the day it suits you least.
So how much does getting the number wrong cost?
Let us put a calculation on it, with the assumptions in plain sight so you can redo it with yours. This is not a measurement from a real client; it is arithmetic to think with, the kind this blog does.
Say an agent runs 200 actions a day. If you set a low limit, say 10% of those actions fall outside it and need a human approval, each costing about 3 minutes of someone's time: 20 actions times 3 minutes is 60 minutes a day of friction. Annoying, measurable, and the whole bill arrives today.
Now raise the limit until only 1% needs approval: 2 actions a day, 6 minutes. You gained almost an hour a day. But you widened the reach of the other 198 actions that now pass on their own. It only takes one of those, over a whole quarter, being one that should not have passed (a deletion, a permission opened too wide, a spend that runs away) for the cost of containing and reverting it to comfortably eat the nearly 60 hours you saved over those three months. The calculation is not "how much do I save in friction"; it is "how much do I save in friction minus the reach of the worst case I just enabled." The second term is the one nobody puts on the napkin, and it is the one that decides.
The numbers are made up and yours will be different. What does not change is the shape of the calculation: the saving is linear and visible, the risk is tail and silent, and calibrating the limit is consciously choosing where to cut between the two. Maximizing autonomy is setting that cut at "I would rather not think about it."
My suggestion
On Monday, bring a single question to your next architecture review, one for each agent you already have running: what is its exact approval limit, and who set it? "It has the permissions it needs" does not count; that is the answer of someone who set no number. Have someone state the concrete boundary, how far it can go without a human signature, and who decided it should be there. If nobody knows the number, it is not that the agent is very autonomous: it is that you signed it a blank check and it has not gotten around to cashing it yet.
And if you want something even more concrete, do the exercise in reverse for a sprint: start from the lowest limit at which the agent is still useful and raise it only when the track record justifies it, like the signing authority of the employee who has gone two years without a slip. It is slower to start and much cheaper to sustain. After all, if you truly trust that the high limit is safe, setting it low first and watching it earn its way up should cost you nothing. ;)