A role-based multi-agent framework is the fastest way I know to find out whether a problem splits into roles. I used one in an agent orchestration platform I lead for a client, next to Google ADK, and in a library of agentic patterns I keep for my own work. Today the production side of that work runs on Google ADK and the Claude Agent SDK. This article describes what the role-based model gave me, what production asked for on top of it, and how the move worked.
What the role-based model gives you at prototype stage
You describe a crew in a few lines: each agent has a role, a goal and a backstory, each task has an expected output, and a process decides the order. A researcher hands its notes to an analyst, the analyst hands a draft to a reviewer. Ten minutes later you watch the crew talk.
That speed answers the first real question of any multi-agent idea: does the work divide into roles at all? In the prototypes I ran, two outcomes were common.
- The roles hold. Each agent does a recognisably different job, with different tools and different inputs. The split is worth keeping, and the prototype becomes a specification.
- The roles collapse. Two or three agents repeat each other, or one agent does the real work while the others restate it. A single agent with good tools, or a plain workflow, covers the job.
A business owner reads a crew definition and recognises their own team in it. That makes the prototype a good conversation tool as well: the people who run the process correct the roles before anyone writes production code.
What production asks for on top
A prototype answers "can agents do this?". Production answers a longer list, and the list is the same whichever framework you start from.
Identity and permissions per tool
In a prototype every tool runs with the developer's keys. In production each tool call acts on behalf of someone: the end user, the agent's own service identity, or a person who approved the step. You need to say, for every tool, who the call runs as and what it may touch. That decision lives at explicit trust boundaries in code, outside prompts and role descriptions.
Control of the flow
Role-based orchestration lets the model decide much of the order: who speaks next, when the task is done, when to delegate. For an exploratory task that is the point. For a business process with rules, the owner of the process expects the same steps in the same order every time, and an auditor expects to see them. Production systems I lead keep the deterministic parts deterministic and give the model the steps that need judgement.
State that survives
A crew run lives in memory for the length of the run. A production agent keeps a session across days, stores what it learned in a long-term memory with its own retention rules, and writes business records to the systems of record. These are three data classes with three owners, and each one needs its own store.
Observability and evaluation
When an answer is wrong, you need to know which agent, which model call and which tool call produced it, with timing and token cost for each. You also need a set of evaluation cases that runs before every change of prompt, model or tool, so a green deployment comes with evidence that the agent still behaves.
Support over years
A client system runs for years. The framework under it needs a release policy you can plan around, documentation for the platform it deploys to, and a vendor that supports the managed runtime. That weighed as much as any technical feature in my choice.
Where the work moved
I lead production agent work on two pairs, one per vendor, at two levels.
| Level | Anthropic | |
|---|---|---|
| Managed platform | Gemini Enterprise Agent Platform | Claude Managed Agents |
| Framework to build and own the agent | Google ADK | Claude Agent SDK |
Google ADK gives me both kinds of orchestration in one model. Workflow agents (sequential, parallel, loop) run fixed steps in a fixed order; LLM agents take the steps that need judgement; a coordinator agent delegates to sub-agents when the task calls for it. Callbacks before and after each model and tool call are where permissions, approvals and guardrails live. The same agent runs locally, in a container on Cloud Run, or on Agent Runtime inside Gemini Enterprise Agent Platform, where sessions, Memory Bank, identity and traces are managed services.
The Claude Agent SDK gives me the agent loop that powers Claude Code: tools, permission modes, hooks that run before and after each tool call, subagents with their own context, and MCP servers for every external system. It fits agents whose main work is reading, deciding and acting across files, documents and APIs, and teams that want to own the code of the agent end to end.
Which pair fits depends on your systems and your team: the cloud you already run, the data you have, who will maintain the agent. I compare the two in the Google vs Anthropic guide, and the Google ADK article maps the Google layers one by one.
How a crew becomes a production agent
The prototype is the specification. In the moves I led, the work followed the same five steps.
- Keep the roles that held. Each role that did a distinct job becomes an agent or a sub-agent, with its instruction rewritten as a precise contract: inputs, outputs, tools, stop condition.
- Turn the fixed order into a workflow. Every sequence the process owner confirmed becomes a sequential or parallel workflow; the model keeps the steps that need judgement.
- Give every tool an owner and an identity. Each tool gets a typed contract, the identity it runs as, and the approval it needs before it acts.
- Separate the three kinds of state. Session, long-term memory and business records each get their own store and retention rule.
- Write the evaluation cases first. The outputs that the prototype got right become the first evaluation set, and the new agent passes it before it replaces anything.
The role-based framework stays in my toolbox for the first conversation about a multi-agent idea. The production agent runs on Google ADK or the Claude Agent SDK, chosen on your case, and the AI automation page describes how I take a process from that first conversation to an agent in production.
Last technically reviewed: 5 October 2026. Product names and capabilities change; the Google ADK, Gemini Enterprise Agent Platform and Claude Agent SDK documentation is the source of truth for current features.