Researcher and Planner Agents Don't Need Job Titles, They Need Boundaries
Modern coding agents already research, plan and code in one session. Here is what separate agent profiles still buy you over skill-based workflows, and when splitting agents by role is just for show.
A single modern coding agent can research, plan, implement and test in one session, so a team of Researcher, Planner and Developer agents looks like extra ceremony. Yet the pattern is common: in a one-person company (OPC), one founder runs a whole company's functions by giving each department a virtual employee, which is an agent profile. The question is whether profiles beat a simpler setup: one capable agent running a skill-based workflow.
The role name adds little. A profile pays off only when it carries its own context window, tool permissions, model, or an independent check. Without one of these, the profile is only a label, and a skill does the same job cheaper.
Two Ways to Organize an Agent System
In setup A, one agent does everything and loads a skill for each task. A skill is a workflow written down: a Markdown file of steps, checks and know-how that the agent follows when the task appears.
In setup B, each role gets a profile: a reusable configuration of instructions, tools and an optional model, often a Markdown file. Claude Code calls them subagents, VS Code calls them custom agents, and OpenCode simply calls them agents. Most tools let you use a profile two ways: pick it as the main agent for a session (the Agent dropdown in VS Code, Tab in OpenCode, claude --agent <name> in Claude Code), or delegate to it from the main agent so it works in its own context window [1]. The example below uses Claude Code's format.
---
name: reviewer
description: Reviews a finished diff for bugs and missing tests
tools: Read, Glob, Grep
model: sonnet
---
You review code. Report problems with file and line. Do not edit files.The tools line enforces the role. This agent has no Write or Edit tool, so it cannot fix a problem and then hide that the problem existed. The sentence "You review code" only asks for that behavior.
Fixed Steps Belong in a Workflow, Not in a Persona
Anthropic separates two things. Workflows run through predefined code paths, and agents let the model direct its own process and tool use. Workflows give predictability and consistency on well-defined tasks. Agents win when a task needs flexibility and model-driven decisions [5].
A monthly invoice reminder or a deploy checklist has known steps, and an automation or a skill runs them with fewer tokens and fewer surprises. Wrapping the same steps in a "Finance agent" persona adds cost without adding capability.
I see this as a scale: a script fixes every step, a skill gives steps the model adapts, and a profile team also lets the model choose who does what. Use the least flexible level that works. I use "workflow" loosely for steps written down, while Anthropic reserves it for code-defined paths.
162 Personas Tested: Role Names Did Not Raise Accuracy
Researchers tested 162 personas on 2,410 factual questions across four LLM families. Adding a persona to the system prompt did not improve accuracy compared with a prompt without one [2]. That study measured factual question answering, not agentic coding, so it cannot settle the coding question. It does suggest that a line like "You are a senior Planner" adds little to a Planner agent.

Figure 4 from Zheng et al. [2], licensed CC BY 4.0. No persona had a statistically positive effect on any model. On Flan-T5, 72.8% of personas hurt accuracy.
Role names do have one effect worth keeping. A profile set up on purpose can carry a distinct tone and taste: a terse reviewer, a writer with your house style, a planner that always lists trade-offs first. That shapes how the output reads, not whether it is correct, and a skill can carry the same style rules.
The Four Things a Profile Buys
- Context isolation. A delegated profile runs in its own context window and only its result returns to the main conversation [1]. A codebase search that reads 40 files costs the main session one paragraph. Context compression for coding agents covers the same pressure.
- Enforced permissions. A read-only agent cannot write, whatever the prompt says.
- Model routing. Each profile can set its own model, so narrow tasks go to faster, cheaper ones. Claude Code's docs list cost control as a benefit [1].
- Independent verification. A delegated reviewer that never saw the author's reasoning is not anchored by it. This is my reasoning, not a measured result. Google's scaling study points the same way: independent agents amplified errors up to 17.2 times, while a centralized setup held the figure to about 4.4 times [3].
Permissions and model routing work either way, as the main agent or as a delegated one. Isolation and independent review need delegation. A read-only explorer and a read-only reviewer are the two profiles I would add first.
Procedure in the Skill, Boundary in the Profile
A skill and a profile differ in where the steps run and what limits surround them.
| Inline skill | Delegated profile | Multi-agent pipeline | |
|---|---|---|---|
| Runs in | Main conversation context | Its own context window | Several windows plus a coordinator |
| Adds | The steps and know-how | Isolation, tool limits, model choice | Handoffs, parallelism, gates |
The layers combine instead of competing. A profile can load skills (Claude Code subagents do through the skills field [1]), so the procedure stays in the skill and the profile adds the boundary. Only a pipeline of role-named agents adds handoffs between windows, and those carry the heavy costs in the next section. Are agent skills the new npm covers how skills are packaged.
Where Multi-Agent Systems Lose Up to 70%
Parallel, independent work gains from multiple agents, while sequential, coupled work loses.
- Anthropic's research system beat single-agent Opus 4 by 90.2% on its internal research eval. It also used about 15 times the tokens of a chat, and Anthropic notes that most coding tasks have fewer truly parallelizable pieces than research [4].
- Google's study found multi-agent coordination gained 81% on Finance-Agent, a parallelizable task, and lost 70% on PlanCraft, a sequential one [3].
Writing code is the coupled kind of work. A Developer agent that receives a Planner's summary has lost the reasons behind each decision, and every gap becomes a guess. The VS Code workflow in this earlier post on sequential custom agents handles this with explicit contracts at each handoff, though every contract has to be maintained.
Three Questions Before You Add Another Agent
- Needs different limits. If a step must never write files, run commands or touch production, give it a profile with a tool allowlist. Run a whole session as that profile, or delegate the step to it.
- Needs a different model. If a step is narrow enough for a cheaper model, or hard enough to justify a stronger one, give it a profile with its own model.
- Needs a separate context. If the step produces bulk output the main session should not carry, or you want a check not anchored by the author's reasoning, delegate it to a profile.
If all three answers are no, the missing piece is a procedure or a style rule. Write it as a skill, or add a line to AGENTS.md.
The Cases Where a Full Team Pays Off
The picture changes when the roles are departments rather than pipeline stages, as in a one-person company. Marketing, finance and support are mostly independent streams. That is the parallel shape where Google's study and Anthropic's research system saw gains [3][4]. Each also touches different data: a support agent reads customer tickets, a finance agent reads the books, and neither should hold the other's keys. A persona line cannot enforce that, and a tool allowlist can. For unattended runs, where a mistake reaches a real customer, a separate reviewer earns its cost. The founder is the coordinator and last gate, so there is no long chain of agent-to-agent handoffs.
A Researcher feeding a Planner feeding a Developer is a different shape: sequential and coupled, where the losses come from. BMAD-style frameworks simulate a whole team for audit trails and sign-offs, and the comparison of spec-driven tools shows that overhead.
Start With One Agent, Then Add Boundaries
Start with one agent and its skills. A team of role-based agents is mostly for show unless each profile names a boundary it adds. Automate the fixed routines, write skills for procedures that need judgment, and add a profile only where you can name the context, permission, model or check it brings.
Each extra agent also adds work for you: maintaining it, testing it and managing how it fits with the others. Runtime costs rise too. Handoffs lose reasoning, Anthropic's multi-agent case used about 15 times the tokens, and sequential tasks drop sharply.
Sources
- Agent profile docs: Claude Code subagents, VS Code custom agents and OpenCode agents - Instructions, tools, model, main-agent and subagent use.
- When "A Helpful Assistant" Is Not Really Helpful (Zheng et al., EMNLP Findings 2024) - No accuracy gain from personas.
- Towards a science of scaling agent systems - Google Research - Parallel gains, sequential losses, error amplification.
- How we built our multi-agent research system - Anthropic - 90.2% gain, about 15x tokens.
- Building effective agents - Anthropic - Workflows versus agents.