Guides
Multi-Agent AI Teams Explained: Roles, Groups and Delegation
A plain-English guide to multi-agent AI teams: roles, threads, groups and delegation, how they fit together, and when one AI agent is all you need.
A multi-agent AI team is a group of AI agents that each own one role and work toward a shared goal. One agent researches, another writes, another checks the result, and usually one coordinates. Each keeps its own instructions and access. You get specialists instead of one agent juggling every job, at the cost of more moving parts.
What is a multi-agent AI team, in plain words?
Think of a small office. You would not ask one person to be the researcher, the writer, the bookkeeper and the receptionist at once. You would hire people for roles, give each the keys they need, and have someone keep the work moving.
A multi-agent team applies that to AI agents. The parts are:
- Roles. Each agent has a job description and instructions written for that job.
- Access. Each agent gets only the apps, files and computer its role needs.
- Conversations. Agents work in their own conversations, and sometimes in a shared one.
- Delegation. One agent can hand a bounded piece of work to another and get a result back.
- Coordination. A lead agent receives your request and pulls the pieces together.
What are the building blocks of a multi-agent team?
Different tools name these parts differently. In Brainwrite the vocabulary is small, and the docs map each need to one building block:
| Need | Use |
|---|---|
| An ongoing relationship and memory | Bot |
| Related conversations kept together | Folder |
| An independent conversation with its own running state | Thread |
| Several bots sharing context | Group |
| A specialist handling one branch of work | Delegation |
| Repeated work at a known time | Routine |
Bots are the roles
A bot is a lasting agent identity. It keeps its name, instructions, memory, approved skills, connected tools and computer preference. You create a separate bot when the role or the access should differ. Some examples:
- A coding bot attached to one repository
- A research bot with browser and document tools
- An operations bot with Gmail, Calendar and Slack
- A local-model bot for private or offline work
Threads are the conversations
A thread is one conversation with a bot. It has its own transcript, model, approvals, costs and Stop control. A bot can run up to three direct threads at once, including threads waiting on your approval. Stopping one thread does not redirect its siblings.
Threads share the bot's saved memory and skills, but they do not automatically see each other's transcripts. Start a new thread when you want fresh context. See threads and groups.
Groups are the shared room
A group puts several bots into one conversation. Use it when specialists need the same brief or should hand work to each other. Each participant keeps its own model and permissions. Group timeouts stop one slow participant from blocking everyone.
When a bot sends the same request to several group members, the group shows one shared message addressed to them, and each member replies in that conversation.
Delegation is the handoff
Delegation asks another bot to handle a bounded subtask. The delegated task keeps its own activity and returns a result to the conversation that asked, with explicit status: completed, failed or cancelled.
The rule of thumb from the docs: give each delegate a narrow outcome, and do not give two bots ownership of the same files.
The Chief of Staff is the coordinator
A Chief of Staff is a bot role. It receives requests for a team, delegates focused tasks, and summarises the results. Each team has at most one Chief. A Chief can create new specialists in its own team, and those start with connected apps and automatic approvals turned off.
How does work flow through a multi-agent team?
Here is a typical request moving through a team:
- You ask the Chief for a competitor summary for Monday.
- The Chief delegates page collection to a research bot with browser access.
- The research bot returns notes. The Chief delegates the write-up to a writer bot that has no app access at all.
- The writer returns a draft. The Chief checks it against the research and sends you one summary.
- Any risky step along the way, such as sending a message, becomes an approval card for you.
Each bot ran with its own model and its own limits. The writer never touched the browser. The researcher never had your inbox.
Why do multi-agent teams work better than one big agent?
They are not always better. They help in three specific ways.
- Narrow access. Each bot gets only the tools its role needs. A writer with no app grants cannot send anything. See connected apps for per-bot grants.
- Focused instructions. A short, role-specific prompt is easier to write, test and fix than one prompt covering every job.
- Right model per job. Each bot can use a different engine and model. A coding bot on Codex, a writing bot on Claude, a private bot on a local model. See bring your own model.
When is one AI agent enough?
More often than people expect. Use one agent when:
- The work is one role, such as fixing code in a single repository.
- Every step needs the same access.
- You are still figuring out what the job is.
- The task is short enough to review in one sitting.
The docs are direct on this: you do not need another bot just to start a different project or choose another model. Start a new thread, or change the thread's model in the chat header.
Add a second bot when one of these becomes true:
| Signal | What it suggests |
|---|---|
| You keep removing app access before some tasks | That work belongs to a separate bot with less access |
| One prompt has grown into several job descriptions | Split it into roles |
| You want two things done at the same time, in different places | Separate bots, or separate threads |
| You keep copying results from one chat into another | A group or delegation |
What goes wrong with multi-agent teams?
The common failure is overlap. Two agents editing the same file, or both driving the same browser, produce a mess. Brainwrite handles the physical side: a computer, browser session or shared project folder cannot safely have two agents changing it at once, so Brainwrite reports the conflict rather than allowing overlapping actions. New local-agent threads also use separate working folders by default.
The other failures are about design:
- Vague ownership. If two bots both "own" the report, neither does. Name one owner per output.
- Too many bots. Every extra bot is another prompt to maintain and more tokens to pay for. Your provider bills each bot's usage. Per-thread usage and cost figures show where it goes.
- Folders treated as boundaries. In Brainwrite, a sidebar folder is only organisation. It is not a privacy boundary or a permission setting.
Try it
Brainwrite runs on macOS today. Download the app and pick a plan on the pricing page. Begin with one bot. When you notice the signals above, add a second with narrower access, and let a Chief coordinate once you have three or more.
