Your Subagent Isn't Broken — You're a Bad Manager to It

Day 1: Why Your Subagent Returned Garbage — It's a Delegation Problem, Not a Context Problem

Here's the failure everyone hits in week one of multi-agent work: you fan a task out to a subagent, it comes back with something confident and completely wrong, and your first instinct is to blame the model. Wrong instinct. You either buried that subagent in irrelevant context or starved it down to a one-liner — and that's not a model problem, it's a management problem. You've solved this exact bug before, just with a human on the other end instead of a prompt.

The run that goes sideways

You've probably already lived this. You spin up an orchestrator to fan out work — refactor a module, review a diff, go research an API. First attempt: you paste in the whole file, the whole design doc, half the git log, 'just in case it's useful.' The subagent does something, sure, but not the thing you needed — it grabbed some side detail buried in the noise and ran with it. So you overcorrect. Second attempt: 'fix the auth bug,' nothing else. Now the subagent is guessing at scope, it touches three files you never wanted touched, and it reports back 'fixed it' with nothing you can actually check that against. Two different failures, same root cause — and it has nothing to do with context-window size.

Name the pattern: this is a delegation-boundary problem

A prompt to a subagent isn't a buffer you fill — it's a brief you write. Every EM has already learned this the hard way, usually with a new hire on their first ticket: hand them a wall of undifferentiated context and they can't find the signal in it; hand them a bare instruction and they have no idea what 'done' looks like. Scoping a task for a subagent is the exact same skill as scoping a task for a junior engineer. If you've managed people, you already have this skill. You just haven't noticed it transfers.

The isomorphism, made concrete

• ▹Context passed to the subagent → the delegation brief you'd write for a new hire's first ticket
• ▹The subagent's returned summary → the status report you'd expect back from that hire
• ▹What the orchestrator keeps back → the manager's own accountability — the parts of the picture only you're positioned to hold (why this task matters, how it fits with parallel work, what happens next)
• ▹The subagent's tool access / scope → the hire's authority level — what they're allowed to decide on their own vs. what they have to escalate

Two failure modes, same shape as bad bosses

You've worked for both of these managers at some point. Now you're the one wiring both of them into your pipelines.

• ▹Hoarding (micromanagement): the orchestrator dumps its entire context into the subagent prompt — every file, every decision, every caveat — because it doesn't trust the subagent to work without total visibility. Result: no signal about what actually matters, a plausible-looking but off-target answer, and the orchestrator ends up redoing the work anyway. Nothing was really delegated — it was a no-op with extra steps.
• ▹Dumping (abdication): the orchestrator hands over a bare task with no scope, no constraints, no success criteria — 'review this PR,' 'fix the bug.' The subagent has to invent its own boundaries, which means there's no specific result to hold it to, and you can't tell a good report from a confidently wrong one. That's not efficient delegation. That's skipping the part of the job that was actually yours to do.

The fix EMs already know

A good delegation brief has three parts: a goal (the outcome you want, stated as a result, not a task list), boundaries (what's in scope, what's explicitly out, what not to touch), and a definition of done (the concrete evidence you'll accept as proof — tests passing, a specific file changed, a claim verified against the actual code). Write your next subagent prompt as those three sections, literally, and most of your garbage-output problem disappears before you've touched a single model setting.

Before and after

// BAD — dumping (abdication): no scope, no success criteria
Agent({
  description: "fix login",
  prompt: "There's a bug where users get logged out randomly. Fix it."
})

// ALSO BAD — hoarding (micromanagement): everything, no signal
Agent({
  description: "fix login",
  prompt: "Here is the entire auth module (4000 lines), the full \
  session design doc, last quarter's incident postmortem, and the \
  complete git log for this directory. Somewhere in here is a bug \
  about random logouts. Figure it out."
})

// BETTER — goal, boundaries, definition of done
Agent({
  description: "Fix random session-expiry logout bug",
  prompt: "Goal: users are being logged out mid-session even though \
  their token hasn't expired. Find the root cause and fix it.\n\n\
  Context: this started after the refresh-token change in \
  src/auth/refresh.ts three weeks ago (see git log on that file). \
  I've ruled out the client-side timer — it's not resetting early.\n\n\
  Boundaries: only touch src/auth/*. Don't change the token TTL \
  config — that's owned by the security team.\n\n\
  Definition of done: existing auth tests pass, plus a new test that \
  reproduces the original bug and now fails-then-passes. Report the \
  root cause you found, not just 'fixed it'."
})

Notice what actually changed isn't the amount of text — the good version is still short. What changed is that every sentence in it does exactly one job: state the goal, draw a boundary, or define the finish line. Everything else — the postmortem, the full module, the incident history — either gets compressed down to the one fact that matters ('started after the refresh-token change') or left out entirely, because that's context the orchestrator needs to judge the report, not context the subagent needs to do the work.

What's next

Get one delegation brief right and you've solved the two-agent case. Day 2 is about what happens once the orchestrator is juggling five of these briefs at once, plus its own accountability, plus a pile of incoming reports — the orchestrator's own context budget, and the point where one layer of delegation stops being enough and you need a second layer of hierarchy underneath it.

Extend your knowledge

• ▹Grab a subagent prompt you wrote this week and rewrite it with explicit goal / boundaries / definition-of-done sections — run both, compare the outputs side by side.
• ▹Read through Anthropic's Claude Code docs on the Agent/Task tool and notice how the description vs. prompt fields map to 'brief' vs. 'scope signal'.
• ▹Pull up a ticket or brief you wrote as a manager for a new hire — check whether it actually had all three parts, or whether you were hoarding or dumping without realizing it.
• ▹Hang onto this lesson's before/after example for Day 2, where the orchestrator itself becomes something that needs to be delegated to.