Home › Agents & Tool Use › Role-based crew
🕹️ · Build

Role-based crew

A team of fixed specialist agents, each with a defined role, collaborates to finish one task.

In one line

Give each agent a fixed role, like researcher, writer, and reviewer, and let them hand work off to one another until the task is done.

ConceptWhat it is

A role-based crew is a multi-agent pattern where several agents are each assigned a fixed specialist role, such as researcher, writer, and reviewer, and they collaborate on a shared task by passing work between them. Instead of one general agent doing everything, responsibilities are split the way a small human team would divide a project, with each role given its own system prompt, tools, and acceptance criteria.

It exists because a single agent that plans, gathers, drafts, and checks all at once tends to lose focus and skip steps. Separating concerns into named roles makes each agent's job narrow and easy to reason about, and it makes the overall workflow easier to inspect, debug, and trust, at the cost of the extra coordination that talking between roles requires.

How it worksThe mechanics

A task enters the crew and a coordinator, or a fixed hand-off order, routes it to the first role. Each agent is the same underlying LLM steered by a different role prompt and tool set; it does its narrow job, produces an output, and passes it to the next role. Work flows down the pipeline, for example researcher to writer to reviewer, and a review step can send a draft back for one or more revision cycles before the coordinator releases the final deliverable.

At a glanceSee it

Role-based crew diagram
Role-based crew diagram 1

When the reviewer rejects, a mature crew diagnoses which role owns the defect — researcher, writer, or the brief itself — and routes the rework there rather than always bouncing it back to the writer.

Role-based crew diagram 2

Zooming into a single role — an entry contract gates the input, a scoped prompt and tools do the work, and an acceptance check must pass before the hand-off is allowed.

When to use itWhere it fits

  • Well-defined workflows that map cleanly onto human roles, such as research, write, and review.
  • Tasks where separating duties improves quality, like having a distinct reviewer catch what the writer missed.
  • Repeatable pipelines you run often, where a fixed structure is worth the up-front design.
  • Situations where you need clear accountability and want to inspect each stage's output.

When NOT to use itLimits & anti-patterns

  • Simple single-step tasks where one agent, or even one prompt, is enough.
  • Open-ended problems whose steps are unknown in advance and cannot be pre-assigned to fixed roles.
  • Latency- or cost-sensitive paths, where several role hand-offs are too slow or expensive.
  • Cases where roles would mostly duplicate each other, adding chatter without adding value.

Trade-offsAdvantages & costs

Advantages
  • Clear responsibilities make the system easy to reason about, test, and debug one role at a time.
  • Specialized role prompts and tools often raise quality over a single do-everything agent.
  • A dedicated review role adds a natural quality gate and a place to enforce standards.
  • The structure is reusable, so the same crew handles many tasks of the same shape.
Trade-offs & costs
  • Rigid roles struggle when a task does not fit the pre-defined pipeline.
  • Chatter and hand-offs between roles add extra LLM calls, latency, and token cost.
  • A fixed order can propagate an early mistake downstream if no role is empowered to correct it.
  • Designing the right set of roles and hand-offs is itself real engineering effort.

ExampleIn the real world

A team wants a weekly competitive-intelligence brief produced automatically. A researcher agent queries news and public filings and returns raw findings; an analyst agent extracts the three most material changes with sources; a writer agent turns those into a one-page summary; and an editor agent checks tone, length, and citations before release. Each role has its own system prompt, permitted tools, and acceptance check, and the editor can bounce a weak draft back to the writer once before the coordinator ships the brief. Because the roles and their order are fixed, the same crew runs every week with only the input data changing.

ToolsHow to implement it

  • CrewAIframework built specifically around role-playing agents organized into a collaborating crew.
  • Microsoft AutoGenconversable agents that can be given distinct roles and made to coordinate on a task.
  • MetaGPTassigns software-team roles like product manager, architect, and engineer along a defined workflow.
  • LangGraphlower-level graph framework you can use to wire fixed roles and hand-offs explicitly.

Cost & effortWhat it takes

Each role is at least one LLM call, and hand-offs plus review loops multiply that: a three-role crew with a single revision cycle is roughly four to six calls per task, so token cost and latency scale with the number of roles and how much they talk to each other. Engineering effort is moderate rather than high, because the roles, prompts, and hand-off order are largely fixed — most of the work is defining responsibilities and acceptance checks up front, not building open-ended planning at run time.

A living map of modern AI — kept current every morning