Using Claude Code Subagents to Separate Triage From Implementation
Yes, run a dedicated triage subagent before implementation. Claude Code subagents each get their own context window, sized by whatever model they run on, completely separate from the main conversation and from each other. A triage subagent can read the full customer conversation, dig through past tickets, and reproduce the bug without any of that exploration ever landing in the implementation subagent's context. The implementation subagent starts fresh with only what the triage step decided mattered.
This isn't a workaround for a limitation. It's the documented purpose of subagents. Anthropic's own guidance says to use one "when a side task would flood your main conversation with search results, logs, or file contents you won't reference again," and that the subagent "does that work in its own context and returns only the summary." Triage is that side task. Reading a rambling bug thread, grepping the codebase for the failing code path, and checking whether three other tickets are the same issue don't belong in the context window that's about to write a patch.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
Claude CodeWhat a subagent actually isolates
Claude Code's subagent documentation is specific about what's separate and what isn't. A subagent defined in a markdown file with YAML frontmatter gets its own system prompt (the markdown body), its own tool allowlist, and its own model choice. Critically, a non-fork subagent doesn't inherit the parent conversation. It doesn't see your conversation history, files Claude has already read, or previously invoked skills. Claude composes a delegation message summarizing the task, and the subagent works from that message alone. Only a fork subagent, created with /subtask, carries the full parent context forward, which is the wrong tool for this split, since the whole point is to keep triage exploration out of the subagent that writes the fix.
Subagents can be invoked three ways: automatically, when Claude matches a task description to a subagent's stated purpose; explicitly, by naming the subagent or @-mentioning it; or as a session default via the --agent flag. They're spawned through the Agent tool (renamed from Task in recent versions, so you'll see both names depending on which docs or changelog you're reading), and by default they run in the background, concurrently with the main session, up to a configurable limit of 20 at once.
The tool-scoping matters as much as the context isolation. A triage subagent only needs read access, so Read, Grep, Glob, and maybe Bash for running a reproduction script are enough. Give it Edit or Write and you've handed a research task the ability to touch files it was never asked to change. An implementation subagent needs write access instead: Read, Edit, and Bash for tests, and it doesn't need to re-search the whole codebase for context it should already have received in its brief.
The two-subagent setup
A working split looks like two subagent definitions in .claude/agents/:
triage.md, toolsRead, Grep, Glob, Bash. Its system prompt tells it to reproduce the reported bug, identify the failing file and function, check for existing duplicate reports, and write a scoped brief (symptom, repro steps, suspected file paths, any related past tickets) rather than a fix.implement.md, toolsRead, Edit, Bash. Its system prompt takes a scoped brief, writes the fix and the test, runs the test suite, and stops there, with no re-investigation of the original report.
The main session's job shrinks to orchestration. It hands the raw bug report to triage, takes its brief, hands that brief to implement, and reviews the resulting diff. Neither subagent's context ever holds more than it needs for its own step.
Why one long session blurs two similar bug reports
Run your bug queue through Claude Code in one long session, reading each report and writing each patch in the same conversation, and the failure shows up deep into the afternoon. The session has already covered several unrelated reports from different customers when you ask for a fix to the duplicate-webhook bug from the second one. Claude Code answers as if there had only ever been one webhook complaint, points back to "the earlier investigation," and names the retry logic as the cause.
That earlier investigation covered two separate webhook complaints, one from a customer on an older SDK and one whose endpoint was timing out. The long conversation blurred which fix applied to which, and sorting it out means scrolling back and re-pasting the second report. Past that point, splitting triage into its own subagent stops being an optimization.
Split it and the same afternoon runs differently. Each report goes to a fresh triage subagent that returns one scoped brief, and each brief goes to a fresh implement subagent that never sees the others. Separate fixes, separate diffs, no cross-contamination between customers.
The bottleneck moves upstream past a few reports a day
Two subagent definitions and a manual handoff is genuinely enough for a small queue. If you're triaging two or three reports a day, write the .claude/agents/ files above and stop reading here.
Past that volume, the split itself keeps working; what breaks is what gets handed to it. The triage subagent is only as good as what it's handed, and at volume the raw material is scattered. The same bug gets reported in Slack, in a support ticket, and by a second customer in a sales call, and nothing tells the triage subagent those are one issue instead of three. Someone still has to notice the duplicate, gather the three phrasings, and paste them into one triage prompt, which is the exact manual step that breaks down first in a long triage session once volume goes up. That's true whether or not the fix underneath is a subagent split.
An upstream structuring layer gets cheaper than a bigger prompt at that volume. We build Modem, and its Claude Code integration sits ahead of both subagents. It dedupes the Slack message, the ticket, and the sales-call mention into one topic with the customer quotes and account details attached, then hands that topic to Claude Code as a task through the Modem agent, which writes the brief and reports back with the PR when it's done. The triage subagent still runs, but it's triaging a topic that's already been merged and counted, not raw noise from three channels. Modem is what we sell, so read that recommendation knowing where our incentive sits; the underlying pipeline that feeds a brief like this is covered in more general terms in how to have your coding agent fix user-reported bugs.
The version to start with today
Write triage.md with read-only tools and a brief-writing system prompt, write implement.md with edit access and nothing else, and route one real bug report through both by hand. The first time a fix comes back clean because the implementation subagent never saw the three false leads triage ruled out, the case for keeping them separate stops needing an argument.
