When not to hand a task to an agent

Most writing on this assumes you should. The overhead is real and it is worth naming where it does not pay.

Handing work over costs something: writing the intent, the paths, the acceptance command, the prior art. Call it fifteen to forty minutes for a task of any substance. That cost is fixed, it is paid by your most context-rich person, and it does not shrink with practice as much as people hope.

So the honest question is not “can an agent do this?” but “is this task bigger than its own spec?”

Four places it does not pay

• Work smaller than its brief. A one-line config change takes ninety seconds and a twenty-minute spec. Just do it. This is the most common mistake and the easiest to avoid.
• Work where the hard part is deciding. If nobody can yet say what correct looks like, the spec cannot say it either, and you will get a confident implementation of the wrong thing. Decide first, hand off second.
• Work whose acceptance needs taste. “Does this copy sound like us” and “is this animation nice” have no command that exits zero. You can still hand these over, but budget for a human review that is as long as the work, and stop pretending the loop is cheap.
• Work touching something you cannot cleanly bound. If you cannot describe the blast radius, you cannot review the diff against it, and “it also changed some other files” is a finding you will make too late.

The signal that predicts it

The one I trust: try to write the acceptance check first, before anything else. If you can write it in a minute, the task is a good candidate. If you find yourself writing prose instead of a command, that is the task telling you it needs a decision or a conversation, not an agent.

This is a cheap test and it fails fast, which is the whole point. Ten minutes into writing a spec you are already committed; ninety seconds into writing an acceptance check you are not.

What is left

After those exclusions, what remains is a narrower band than the enthusiastic version of this promises, and it is still most of a backlog: medium-sized, well-understood, tedious, mechanically checkable. That band is genuinely worth industrialising. The rest is worth protecting from process.

On the mechanics of the handoff itself once you have decided a task qualifies, the task-handoff docs lay out what actually travels with the task.