What to Delegate to AI Agents — and What to Keep
Most people sort the work by how much they hate it — which hands an agent the highest-stakes tasks first. The two questions that actually sort it, the verb gate that holds the line, and what the week becomes.
You are past the demo stage. You have watched an agent do real work, you believe the leverage is real, and now you are looking at your actual business trying to decide which pieces to hand over. This is the decision that determines whether agents compound your operation or quietly corrupt it — and almost everyone sorts the work on the wrong axis.
The sorting rule everyone starts with
The instinct is to sort by feeling: delegate what you hate, keep what you like. Or by hours: delegate whatever eats the most time. Both feel rational and both put the most dangerous work at the front of the delegation queue.
Look at what a founder actually hates: refund conversations, pricing decisions, replying to public criticism, chasing an invoice. You hate them because they are consequential — they are tense precisely because getting them wrong costs money or reputation. Hate-sorting hands an agent the highest-stakes work first. Hours-sorting fails differently: some work is slow because judgment is load-bearing, and stripping the judgment out is the error, not the efficiency.
The failure mode is not that the agent does these tasks badly. A current model writes a perfectly serviceable refund email. The failure mode is what happens when it is wrong — because for this class of work, wrong ships straight to a customer, a ledger, or the public, and you find out after.
Delegation is not about what the agent can do. It is about what happens when the agent is wrong.
The two questions that actually sort the work
Every task in your business can be placed by asking two questions, neither of which is “can AI do this?” — the answer to that one is almost always yes, which is why it sorts nothing.
First: can a machine check it?Not “does it look right when I read it” — that is review, and review costs you attention every single time. Checkable means a cheap external test settles it: the link returns 200, the test suite passes, the row count matches the source export, the file exists and is not empty. If a check like that exists, the agent can run at volume, because wrongness gets caught by a process instead of by you.
Second: what is the blast radius if it is wrong and nobody notices for a week? A wrong draft sitting in a folder has a blast radius of zero — you fix it when you read it. A sent email cannot be unsent. A deleted file is gone. A public post is screenshotted before you wake up. Same model, same quality of output, wildly different cost of error.
Two questions, four buckets, four different treatments:
- Checkable, low blast radius — delegate fully. This runs without you. The check is the supervisor.
- Checkable, high blast radius — delegate behind a gate. The agent does all the work and stops before the irreversible step. You approve the artifact, not the idea.
- Uncheckable, low blast radius — delegate and sample. Tone, summaries, categorization. Spot-check a few per batch; the cost of a miss is small enough that sampling is honest coverage.
- Uncheckable, high blast radius — keep it. Not because the model is not smart enough. Because nothing external can catch the error and the error is expensive.
Where real work actually lands
Run our own operation through that grid and the placement is unglamorous. What runs unsupervised: research pulls that end in a file, first drafts of everything, internal reports, data reshaping where the row count is checkable, code that has tests standing behind it. What runs behind a gate: anything whose final step is send, post, spend, delete, or deploy. What we sample: classification and tone at volume. What never left the human: pricing, refunds above a threshold, public replies to criticism, anything a lawyer would want to see, and any account change we could not reverse.
Gate verbs, not tasks
The practical mistake people make with approval workflows is maintaining a list of gated tasks. Task lists rot — your work changes weekly, the list does not, and the new workflow nobody classified defaults to ungated. Gate the verbs instead. Whatever the workflow is, however new, if its last step sends, posts, spends, deletes, or deploys, it stops at the finished artifact and waits.
And the gate must hold the artifact, not the plan. An agent asking “shall I send the outreach batch?” is a summary, and summaries hide the error you are gating against. The gate that works looks like: the exact recipient list and the exact copy of every email, or the rendered post itself, or the literal file list a delete will remove — and then a full stop. You approve the thing that will happen, not a description of it.
## Runs unsupervised (each task names its check) - weekly metrics report -> row count matches source export - research pulls -> output file exists, sources linked - content first-drafts -> land in drafts/, never scheduled ## Gated verbs (agent stops at the finished artifact) - send -> full recipient list + exact copy, then WAIT - post -> the rendered post itself, not a summary of it - delete -> the exact file list, dry-run first - spend -> amount, destination, what it unblocks ## Kept (do not attempt, surface to operator) - pricing, refunds over threshold, public replies to criticism, legal anything, irreversible account changes ## Log - caption dedupe would have deleted 59 live drafts. "same caption" != "duplicate". delete stays gated.
That file is not documentation. Agents read it at the start of every session, which is the difference between a boundary and a suggestion. If the line lives in your head, every new session renegotiates it — and agents renegotiate confidently.
What a week actually looks like
The honest version, because the fantasy version sells courses for other people: the work does not disappear, it changes shape. Mornings start with a queue, not a blank page — overnight and batched output to read, gated artifacts to approve or bounce. Most days that is well under an hour. Lanes run in parallel through the day, on demand; you touch them at the gates and the checks, not in the middle.
Weekly, three things keep the system from drifting:
- Sample the uncheckable lanes. Pull a handful of outputs from the delegate-and-sample bucket and actually read them. Drift in tone and judgment is gradual and invisible at the per-item level.
- Read the failure log.Every miss gets one line: what happened, what rule it produced. The log is the institution's memory — without it, the same failure reoccurs with a new session that never saw the first one.
- Move the line. Promote and demote. A gated task that has run clean repeatedly, with its check in place, earns a longer leash. Any task that produced a failure gets demoted the same day, and the log says why.
Your role shifts from producing to judging — editor and auditor over a fleet, rather than the hands. Total hours drop hard. But be honest with yourself about the shape: if you only love the making, a week of reading queues and approving artifacts may not be the job you wanted. It is, however, the job.
Honest limits
Three things this framework will not do for you. First: one-off tasks are usually cheaper to just do. Writing the procedure, the check, and the gate is an investment that pays on repetition; a task you will run once does not repay it. Delegate the weekly things first, the monthly things later, the one-offs mostly never.
Second: gates make you the bottleneck, on purpose. That is the design working, but it has a cost — the operation moves at the speed of your availability on exactly the actions that matter most. If you disappear for three days, gated work queues. That is still strictly better than gated work executing unreviewed, but it is a real constraint, not a footnote.
Third: nothing here delegates judgment. The grid tells you where judgment is load-bearing so you can keep it, not how to automate it away. Agents do not own risk, do not carry taste, and will drive off any cliff your files point them at. What you get is leverage on everything else — which turns out to be most of the week.
Start with one sort
Do not build the whole system this week. Tonight: list the tasks you touched in the last seven days, ask the two questions of each — can a machine check it, and what breaks if it is wrong for a week — and write your version of the gated-verb list. That single page is the skeleton everything else hangs on. The full build — the truth layer, the procedure docs, the verification gates, and the week-by-week rhythm of running it — is what The AI Operator Method ($97) walks through, from an operation that actually runs this way.