What Delegation Actually Requires
This is a member-only chapter. Log in with your Signal Over Noise membership email to continue.
Log in to readModule 2 · Section 3 of 5
What Delegation Actually Requires
Before the original PDA 1.0 covered delegation, it talked about a delegation matrix: which tasks to hand off versus keep, based on importance and whether you’re the only one who can do them. That framing still holds, but there’s a new dimension: whether the task is reversible if the agent gets it wrong.
Reading and summarising? Fully reversible — worst case is a bad summary and you re-read the source. Sending an email? Irreversible once it leaves your outbox. Editing code? Reversible if you’re using git, less so if you’re not.
I use a simple test before delegating anything non-trivial:
Can I review the output before it has any effect? If yes, the stakes are lower. If the agent drafts an email that I have to approve before sending, that’s very different from an agent that sends emails on my behalf. The first is delegation with review. The second requires more trust in the agent’s judgement and more careful testing before you give it that authority.
Is the task well-defined enough that the agent can succeed? Agents fail at vague tasks the same way humans do — they produce something, but it’s not what you wanted. The better you can specify the inputs, outputs, and constraints, the more reliably the agent performs. This is where your context files pay off again: an agent working inside your project already understands the conventions, which means your task descriptions can be shorter and still precise.
Have I seen the agent do this correctly before? The first time you delegate anything consequential, watch it closely. The second time, watch a bit less. By the tenth time, you’ve established whether it’s reliable for that task. Trust is earned through observation, not assumed.