The difference between people who get real leverage out of AI and people who get burned by it isn't prompt quality or model choice. It's knowing which work to hand off and which to keep. Give a model the wrong task and it will do it confidently, at speed, and you will pay for the mistake later. The skill is deciding, before you delegate, what class of work you're looking at.
I run a fleet of autonomous agents in production, and the whole thing holds together because the boundary between what runs unattended and what waits for me is drawn deliberately. This is how I draw it.
Two Axes That Actually Matter
Most advice about AI delegation sorts work by difficulty. That's the wrong axis. A model can handle hard work fine. What it can't handle is work where being subtly wrong is expensive and you wouldn't catch it. The two questions that actually decide whether to delegate are these.
Reversibility. If the output is wrong, how hard is it to undo. Drafting a blog post is fully reversible: you read it, you don't like it, you throw it away and lose two minutes. Sending an email isn't reversible. Deleting rows from a table isn't reversible. Wiring money is very much not reversible. The cost of a mistake on reversible work is your attention. The cost of a mistake on irreversible work is the mistake, permanently.
Verifiability. If the output is wrong, will you know. Some work you can check in seconds: the code compiles or it doesn't, the JSON parses or it doesn't, the total matches the invoice or it doesn't. Other work you can't easily check at all. If you ask a model to summarize a contract you have not read, you have no way to know whether the summary is faithful without reading the contract, at which point the summary saved you nothing.
Put those together and you get a simple rule. Delegate freely when work is reversible and verifiable. Gate it behind review when it's irreversible or hard to verify. Be most careful about the corner where it's both.
Give the Model the High-Volume, Well-Specified Work
The work that pays off to delegate shares a shape: there's a lot of it, the requirements are clear, and a wrong result is cheap to catch and cheap to undo. This is where a model earns its keep, and where a fast model like Sonnet does most of the volume.
- Drafting. First drafts of anything - posts, emails, docs, commit messages. A draft is reversible by definition. You're the gate, and you were going to read it anyway.
- Transforming data. Reshaping JSON, converting formats, extracting fields from messy text. The output is mechanically verifiable: it parses and matches the schema, or it doesn't. I lean on this constantly in my data parsing pipelines.
- Boilerplate. The tenth CRUD endpoint, the test scaffold, the config file that looks like the last four. Well-specified by the pattern around it, and the compiler checks the result.
- First-pass research. Gather the candidates, summarize the options, find the relevant docs. You still make the call, but the legwork is done and you can spot-check the sources.
- Routine sync and processing. Reading incoming email, updating notes, generating a report from data that already exists. High volume, low stakes, reversible.
Notice what these have in common. None of them are the final decision. They're the labor that feeds a decision, and the decision stays with you.
Keep the Consequential and the Unverifiable
On the other side of the line is work where a subtle error is expensive and you wouldn't necessarily catch it. This stays with you, or waits behind a review gate.
- Final decisions. Which candidate to hire, which vendor to sign, which architecture to commit to. A model can lay out the options. It doesn't own the outcome.
- Anything that acts on the world. Sending an email, moving money, modifying records other systems depend on. These are irreversible and they touch things outside your control. They don't run unattended.
- Taste calls. Whether the copy sounds like you, whether the design feels right, whether the tone fits the relationship. A model produces a competent average. Your judgment is the thing that isn't average.
- Work you cannot check. If you can't easily verify the answer, delegating it doesn't save you effort. It moves risk. More on that below, because it's the trap people fall into most.
The test isn't "is this hard." It's "if this is quietly wrong, what does it cost, and would I find out." When the honest answer is "a lot" and "probably not," keep it.
The Proposed-Actions Pattern
The useful middle ground between "the model does it" and "I do it" is: the model drafts the action, a human approves it, and only then does it execute. The AI does all the work of figuring out what to do. It doesn't get to pull the trigger.
In my setup this is a literal queue. Low-stakes reversible work - reading data, writing notes, generating reports - runs autonomously. Higher-stakes actions don't execute directly; the agent writes a proposed action into a review queue, and nothing happens until I approve it. An agent that decides a CRM contact needs a follow-up email doesn't send the email. It drafts the email and files it for me to approve, edit, or kill. The reasoning is automated. The irreversible step is gated.
This pattern buys you the leverage of automation without the exposure of automation. The model still saves you the ninety percent that's thinking about what to do. You keep the ten percent that's deciding whether to actually do it. I go deeper on the mechanics of running this safely in running AI agents in production.
Relax Review With Evidence, Not Hope
The mistake in the other direction is over-gating: making a human approve work the model has proven it does reliably, forever, out of caution. That's just you doing the work with extra steps.
The right default is to start with review and remove it based on evidence. When an agent has proposed a class of action a few hundred times and been right every time, that's data. You can widen its autonomy for that specific, narrow class and keep the gate on everything else. What you shouldn't do is start with no review because the demo looked good. You have not earned that yet.
So the direction of travel matters. Begin gated, watch the queue, and let the model's actual track record - not your optimism about it - tell you where the gate can come off. Reversibility still bounds this: even a perfect track record doesn't earn an agent the right to wire money unattended, because the one exception is unrecoverable.
The Trap of Delegating What You Cannot Check
Here's the failure that catches good engineers, because it feels like progress. You hand a model a task, it returns something plausible, you skim it, it looks fine, you ship it. But you never actually verified it, because verifying it would have taken as long as doing it. You didn't save the effort. You moved the risk downstream, to a moment when it's more expensive to discover.
A model hands you a wrong answer with exactly the same confidence it hands you a right one. There's no tremor in the output. So if you can't check the work, the plausibility of the output tells you nothing, and delegating it isn't delegation. It's gambling with an extra step that makes you feel productive.
The discipline is to only delegate work you can verify, or to build the verification into the process. If the answer is checkable, check it. If it isn't directly checkable, add a step that makes it checkable: a test, a second adversarial pass, a structured output you can validate. That's the whole argument for having AI review AI - a separate pass whose entire job is to make the first pass's output something you can trust. If you can't make the work verifiable at all, that's a signal to keep it, not automate it.
The Line, Drawn
The framework is small enough to hold in your head. Ask two questions of any task before you hand it off: if the output is wrong, can I undo it, and would I know. Delegate freely where the answer to both is yes. Gate behind a proposed-actions queue where it isn't. Relax the gate on evidence, never on hope. And never delegate what you can't check, because unverified output isn't saved effort, it's deferred risk.
Get the line right and AI is the best leverage available to a small team. Get it wrong and it's a faster way to make mistakes you won't notice until they cost you. The models keep getting better. The judgment about where to trust them is still the part that's yours.