Multi-agent orchestration: decide when roles earn their cost

A multi-agent system divides a process among specialised agents and an orchestration layer. The layer assigns work, carries state, handles failures and assembles the result. That design can help, but every extra role adds another instruction set, call, permission map and place where a case can stop.

Choose it because the process needs those properties. A diagram with several roles is not evidence of a better result.

Define the capability that must improve

Write the reason for a second role as a measurable requirement:

• independent research tasks should run in parallel;
• a specialist needs a narrower schema and instruction set;
• a reviewer must challenge the first result;
• a reader and a writer must have separate access;
• a long process needs separate state and recovery at each stage.

If all roles use the same data, tools and decision rights, one agent with a validator may be easier to test and maintain. A deterministic workflow may handle the same work with fewer moving parts.

Model the handoffs before selecting tools

For each role, state:

1. the input it receives and its source;
2. the output schema it must produce;
3. the tools and permissions it may use;
4. the conditions that send work to review;
5. the state retained for the next role;
6. the owner responsible for a failed handoff.

CrewAI's process documentation describes sequential and hierarchical task execution. LangGraph's persistence documentation describes checkpointed graph state and thread-scoped recovery. These capabilities are building blocks; the company still defines the process policy and acceptance test.

Keep access separate by operation

An agent that reads source records may not need write access. A summariser may not need to send a message. A reviewer may need to see evidence while the action role receives only the approved fields.

Map permissions per role and record every handoff. Keep external writes behind an approval action when the consequence is material. A failure or prompt injection should have a limited operational effect because the affected role has limited access.

Compare the complete process

Run one agent, separate workflows and the proposed multi-agent design on the same acceptance set. Include routine cases, missing evidence, contradictory sources, tool failures and a human review step.

Count retries, failed tools and operator reconstruction. Token usage alone does not represent the cost of a handoff-heavy process.

Use orchestration where state has a reason

Long-running work can benefit from explicit state and checkpoints. Parallel research can benefit from independent tasks that return structured results. A regulated or sensitive process can benefit from separate access roles and human decisions.

The same process may fit one workflow when inputs are stable and branches are known. Start with the simplest version that passes the acceptance set. Add roles only when the first design fails a named requirement and the new role addresses that failure.

Prepare the operating record

The production record should contain role definitions, tool permissions, state schema, retry policy, review roles, source references and incident ownership. Operators need a view of the case that shows the current role, pending handoff, evidence and permitted next action.

Re-run the comparison after a major model, framework, integration or process change. A new role can change cost and failure patterns even when the user-facing output appears similar.

Multi-agent selection card

• What requirement forces more than one role?
• Which cases show the benefit?
• Can each role receive only the data it needs?
• What output crosses each handoff?
• How does a person resolve a failed transition?
• What state survives a restart?
• What does a complete case cost?
• Who maintains the orchestration after release?

If the proposed architecture cannot answer these questions, begin with one agent or a workflow. A free process scan can map the case and identify the first measurable architecture choice.