Delegating without getting burned

Subagents are the right tool for width: many files, many sources, more reading
than you want to carry. They are the wrong tool for anything that needs the
conversation you are currently in.

The danger is specific and worth stating up front.

A subagent that fails will often produce a plausible answer anyway

This is the thing to internalise. Asked for URLs, it may return URLs that
404. Asked for prices, it may return numbers nobody verified. The report will
read as confidently as a correct one, because nothing in the process marks the
difference.

So: treat a subagent report as a lead, not a finding.

Before acting on anything from a subagent, re-check by hand:

• any URL you are about to open or publish
• any number that affects money or a decision
• any claim that something "already exists" or "is already done"

Everything else you can usually take at face value.

What delegates well

• Reading many files to answer one narrow question
• Cross-checking a claim against several sources
• Anything whose output is small but whose input is huge
• Work that would otherwise flood your context with material you only need
  the conclusion from

What does not

• Anything needing the current conversation. A subagent starts fresh. "Do the
  thing we discussed" means nothing to it.
• Anything where being wrong is expensive and hard to detect. The failure mode
  above makes this a bad trade.
• Anything touching shared state — the screen, a browser, a device — while you
  or another agent is also using it. Two agents fighting over one window is a
  mess that is hard to unpick.

How to brief one

The quality of the output is set by the brief. Five things belong in it:

1. The situation, not just the task. Why this matters and what it is for.
Without it, you get a technically correct answer to the wrong question.

2. The exact deliverable. Where the output goes, what format, what
sections. "Write a report" produces something unusable. "Write these four
sections, in this order, to this path" produces something you can use.

3. What is off limits. Files not to touch, resources not to spend,
shared things not to grab. Be explicit — a subagent does not know what you are
in the middle of.

4. Budget, in numbers. If the work costs money or time, give a ceiling and
say what to do on hitting it. "Stop and report what you have" beats blowing
through it.

5. How to report failure. Ask explicitly for what was not verified. A
subagent that is told to flag uncertainty will flag it; one that is not will
smooth it over.

Ask for the negative results too

Add this to every brief: "Also report what you checked that turned out to be
useless, and why."

It costs a paragraph and it saves the next person from re-walking the same
dead ends. It also gives you a read on how carefully the work was done — a
report with no dead ends usually means not much was actually checked.

Running several at once

Parallel is fine when the jobs are genuinely independent. It is not fine when
they touch the same files or the same screen.

If you do run several, decide up front what happens when results arrive
mid-conversation. Interrupting whatever the human was saying to announce a
finished job is a real cost — it buries the thing they were actually asking
about. Note the result, finish the current thread, then report.

The exception: if the new result changes the answer you are currently giving,
use it immediately. Not interrupting means not hijacking the topic — it does
not mean withholding something that makes your current answer wrong.