Structuring your subagent team, the six roles you need in a daily driver

Building one subagent is the easy exercise. Running six of them side by side without them shredding each other's files or doing the same research three times, that's the hard one. I tested this over eight weeks with five different setups and landed on exactly six roles that any solo founder or small team can put to use. More gets messy, fewer leaves gaps.

Prerequisite: you've worked through the playbook "Your first sub-agent in 30 minutes" and you know the CEO worker pattern from Level 5 Lesson 2. This is the next step, turning a single specialist into a team that actually pulls together.

1. The six roles almost everyone needs

Before you create a single file, think about which tasks you're really handing off. From my eight weeks of testing, these are the six:

• Researcher, digs through external sources, summarises, writes a report
• Reviewer, reads code or text and gives concrete feedback, but changes nothing
• Drafter, writes first versions of texts, code, mails, posts
• Auditor, checks whether claims hold up, verifies sources, compares against the inventory
• Coordinator, hands out tasks to the others, pulls the results together
• Janitor, cleans up, archives, dedupes, deletes old drafts

Six is the ceiling. I ran eight once and the coordinator forgot everything because there were too many options. At six it picks right, consistently.

2. Define permission profiles up front

Every subagent gets a different set of tools. That's mandatory, otherwise three weeks in you've got somebody who "just quickly" overwrites prod. My default:

• Researcher: Web-Search + Read only, no Write, no Bash
• Reviewer: Read + Grep only, no Write
• Drafter: Read + Write in drafts/ only, no git
• Auditor: Read + Web-Search + verify tools, no Write
• Coordinator: tool calls to other agents only, no direct file write
• Janitor: Read + Write + Delete in drafts/.archive-*, nothing else

Put that as the first entry in every agent markdown file, right at the top of the frontmatter. If your setup supports permissions via a tools: array, use it. If not, write it as prose in the prompt and let the coordinator filter.

3. Split the agents folder cleanly

With six agents you need structure. Mine sits like this:

~/.claude/agents/
  researcher.md
  reviewer.md
  drafter.md
  auditor.md
  coordinator.md
  janitor.md

Per project you add .claude/agents/ in the repo on top of that, and the project variants go in there. If you need a different drafter for Academy than for client sites, create .claude/agents/drafter.md in the Academy repo. It overrides the global one automatically. Important: the global ones are the generalists, the local ones the specialists. Not the other way round.

4. Who triggers whom

The most common beginner mistake: every agent can call every other one. That gives you endless loops. In my setup it only goes one direction. The coordinator sits on top and calls researcher, drafter, reviewer, auditor, janitor. Those five call nobody. If the drafter wants something reviewed, it hands that back to the coordinator with a note saying "please schedule a review". The coordinator decides.

Sounds clunky, but it isn't. It keeps you out of loops and makes debugging trivial. When something goes wrong, look at the coordinator trace.

5. Shared memory or isolated contexts

This is where it gets tricky. Every subagent has its own context window. If the researcher has read 30 sources, the drafter sees none of it. Three options:

First option: after every subagent call the coordinator writes a summary into a file and passes that to the next agent as input. Works, but it's handwork.

Second option: you use a memory MCP server (see Level 4 Lesson 3) and all agents read from and write to the same memory store. Nicest solution. Needs setup, though.

Third option: you let every agent work in isolation and accept that some things get researched twice. With small teams that's often fine.

I use option two with StudioMeyer Memory. For me that cut duplicate research by about 60 percent.

6. Lock down output conventions

If the drafter writes Markdown today and YAML tomorrow, the reviewer can't do anything with it. My pattern:

• The researcher always writes a report with # Frage, ## Quellen, ## Befund, ## Verdict
• The drafter always writes into drafts/{kind}/{slug}.md with frontmatter
• The reviewer always writes a list in the format - [Severity] Zeile X: Befund
• The auditor always writes verify statistics at the top and findings at the bottom
• The coordinator writes a status block: what got done, what's still open, next step

That makes merging outputs trivial. You read three reports and they're all structured the same.

7. Avoiding conflicts between agents

Three conflicts keep showing up:

Drafter and janitor: the drafter writes, the janitor archives. If both run at the same time, the drafter can write a file, the janitor spots it and clears it away on the spot. Fix: the janitor never runs in parallel, only on an explicit coordinator trigger.

Researcher and auditor: both fetch external URLs. When the same URLs get requested, you pay twice. Fix: the auditor checks the memory store first to see whether the researcher already had that URL. If yes, recycle it.

Reviewer and drafter: the drafter writes version 1, the reviewer finds 12 issues, the drafter writes version 2 with partly new issues. Fix: a maximum of two review rounds per draft, after that it goes to a human.

8. When the coordinator wants too much

At some point my coordinator started wanting to do everything itself instead of delegating. Classic drift. The pattern behind it: when the coordinator prompt carries too many "if X, do Y" rules, it figures it can just do the thing directly. Fix: write shorter, and put a sentence at the end like "You are the coordinator, not the executor. Your job is delegation, not execution."

Concrete symptoms to look for: the coordinator gives 800-word answers when three subagent calls would do. The coordinator argues with the user instead of asking. The coordinator forgets to start subagents.

For me, a reset to a 200-word system prompt fixed the problem in a day.

9. Eval and improvement

After two weeks of running this you should know which agent is too slow, which one hallucinates too often, which one costs too much. My setup:

The coordinator runs a few times a day and I log token usage per agent into a CSV. After a week I can see: researcher takes 40 percent, drafter 30, auditor 15, reviewer 10, coordinator 4, janitor 1. If the drafter suddenly jumps to 50, I go look at what changed in the prompt.

If you want eval more systematically, take a look at the playbook "Agent eval in 60 minutes". It shows you how to run test cases against every agent.

10. When you do NOT need subagents

So this doesn't read like "everybody has to build agents": if you have fewer than three recurring tasks, you don't need a team. A single subagent is enough. If you have no recurring tasks at all, you don't need one either, plain Claude Code is the better choice. And if you have more than three people on the team all running their own setups, an agent team may well be overkill and what you actually need is a proper multi-user setup with shared configs.

Rule of thumb that works for me: from four recurring tasks a week on, the setup effort for a team pays off. Below that it doesn't.

What next

Once the team stands, these are the two next steps. First, look at the playbook "Hooks against hallucinations" to automate the audit steps. Second, read Level 6 Lesson 7 "Multi-agent orchestration" for the advanced patterns if you're heading towards scale.

Sources to go deeper:

• Anthropic docs on subagents in Claude Code: https://docs.claude.com/en/docs/claude-code/sub-agents
• Multi-agent research pattern (Anthropic blog): https://www.anthropic.com/engineering/multi-agent-research-system