Delegating to a System That Acts

The line between drafting and doing

The useful way to locate the line is to ask what happens if the output is wrong.

When the agent drafts, a wrong output costs you the time to notice and discard it. The blast radius is one review. The failure is visible by construction, because a human was always going to look at it — that is what drafting means.

When the agent acts, a wrong output costs whatever the action cost. A task created is a task someone might start. An email sent is an email received. The failure is invisible by default: nobody is scheduled to look, because the whole point of delegating was that you would not have to. This is why agentic work needs a governance layer and drafting does not, and it is the subject of the next lesson.

The line is not about how capable the model is. It is about who absorbs the cost of being wrong. Keep that framing and most autonomy decisions get easier.

The ironies of automation, forty years early

Before any of the mechanics, it is worth knowing that the central trap here was described precisely in 1983, about industrial process control, by a psychologist who had never heard of a language model.

Lisanne Bainbridge's argument in Ironies of Automation runs roughly: automation takes over the easy parts of a job, because the easy parts are what is easy to automate. What is left for the human is the residue — the exceptions, the ambiguities, the things the designer could not work out how to handle. So the human's remaining job is harder than the original job, not easier. Worse, the skill needed to do that harder job was maintained by doing the easy parts, which are now gone. In her words, taking away the easy parts of the task can make the difficult parts more difficult, and an experienced operator who has spent a year monitoring an automated process may now be an inexperienced one.

Her conclusion is the sentence to carry through this entire module: the more advanced a control system is, the more crucial may be the contribution of the human operator (Bainbridge 1983).

This cuts directly against the intuition that a better agent needs less management. It needs different management, and often more skilled management. If you delegate all the routine task-creation to the agent, the tasks you personally handle are now exclusively the weird ones — and your feel for what normal looks like, which is what let you spot a weird one, was built by doing the routine ones. Plan for that. It is the strongest argument in this course for reading your agent's output regularly even when you have stopped needing to.

The four autonomy levels

Kavanah models autonomy as four ordered levels, set in Settings under AI Agent.

Off. The feature is hidden. The agent does not assess work and does not run it. This is the default, and a workspace that never opts in behaves exactly as it did before the feature existed.

Assess only. The agent will tell you whether it could do a given task, and reason about how — but it never acts. This level is more useful than it sounds. It is a free read on where your delegable surface actually is, and it costs nothing but model calls. Most teams should spend a couple of weeks here before going further, because the answer is usually surprising in both directions.

Safe — internal actions. The agent may complete tasks autonomously using internal, non-destructive tools only: creating and updating tasks, leaving comments, writing drafts. It will not send email, post externally, move money, or delete. The mechanism matters and is worth being precise about: risky tools are not merely discouraged at this level, they are stripped from the agent's toolset before the model is called. The agent cannot send an email at safe level for the same reason you cannot dial a phone you do not have. It is not being obedient; the capability is absent.

Full — with approval for risky actions. The agent may reach for anything a task needs, but each risky action is checked against your action policies before it executes. The default policy for an uncategorized action is to park it for explicit per-action approval. This is the level where the agent is genuinely useful and genuinely needs the machinery in lesson 7.2.

The difference between safe and full is the single most important thing to understand about the model. Safe removes the capability. Full grants the capability and gates the call. Safe is a smaller agent; full is a supervised one.

Why the ceiling is two-sided

A member's effective autonomy is the lower of two numbers: the workspace ceiling an admin sets, and that member's own opt-in. Neither alone is sufficient. An admin who sets the workspace to full does not thereby put every member's agent into full — each member still chooses. A member who opts into full in a workspace capped at safe gets safe.

This is not bureaucracy, and it is worth understanding why it is built this way rather than as a single switch. The two sides answer two different questions. The workspace ceiling answers what is this organization willing to have happen — a policy question, owned by whoever carries the liability. The member opt-in answers what am I willing to stop personally checking — a competence and comfort question, owned by whoever will be embarrassed when it goes wrong. Collapsing them into one control forces one person to answer a question that is not theirs.

The practical consequence: raising the workspace ceiling changes nothing on its own. It grants permission. Adoption is still a per-member decision, and if nobody moves, that is information about trust, not about the setting.

Reversibility is the axis, not importance

The common instinct is to delegate unimportant work first and keep the important work by hand. This is the wrong axis, and following it produces the worst of both worlds: the agent does trivia nobody cares about, so you learn nothing about whether it can be trusted, while the work that would actually benefit stays manual.

Delegate by reversibility instead. An action is a good first candidate when a wrong result is cheap to notice and cheap to undo. Creating a task is extremely reversible — the wrong task sits on a board looking wrong, and deleting it costs a click. Sending an email to a customer is irreversible in the only sense that matters: the customer read it. Importance is orthogonal to both. An important, reversible action is a better first delegation than a trivial, irreversible one.

This is also why Kavanah's undo stack exists for agent actions, and why it is worth checking that an action you are about to delegate is on it. An action with a working inverse is one you can afford to be wrong about.

The reversibility heuristic has a second-order benefit. Reversible actions produce fast, cheap feedback about the agent's judgment, which is exactly what you need to decide whether to widen the delegation. Irreversible actions produce feedback too, but the tuition is much higher.

The frontier problem

There is a well-documented failure mode that autonomy makes worse, and you should design around it rather than hope.

AI systems have what one large field experiment named a jagged frontier: a boundary, not obviously visible from outside, between tasks the model handles well and tasks it handles badly. Inside the frontier, assistance produces large gains. Outside it, assisted work was measurably more likely to be wrong than unassisted work — the model does not degrade gracefully at the edge, and it does not announce that it has crossed one (Dell'Acqua et al. 2023).

The reason this matters more for agentic work than for drafting is that drafting puts a human at the frontier by construction. Somebody reads the output, and a bad output at the edge looks bad. Autonomy removes that reader. An agent operating past its frontier at full autonomy produces confident, plausible, wrong actions with nobody scheduled to look.

The design response is the scoping discipline from lesson 3.4, applied to autonomy: delegate the bounded, well-understood middle of the frontier, not its edge. If you cannot describe the boundary of a delegated job in a sentence, you are not ready to delegate it — not because the model will refuse, but because it will not.

The same evidence base counsels a related caution: the gains from AI assistance are highly uneven, concentrated in less-experienced staff on work inside the model's competence, and close to zero for the most experienced people on the work they know best (Brynjolfsson, Li and Raymond 2023). Delegating an expert's core judgment to an agent is the case with the least evidence behind it and the most to lose.