AI agent team series, part five
How to make AI agents work together without stepping on each other
Agents do not coordinate by accident. They coordinate because one of them owns the board, every task has an owner and a finish line, and every risky action travels in the same envelope.
How do multiple AI agents coordinate without stepping on each other?
Give one agent the chief of staff role. It turns every request into a task with an owner and a done when line, enforces a work in progress limit, writes a daily standup, and batches approvals into two digests a day. Put the rest into small pods with their own group chats, pass work by mentioning the receiving bot with the task ID, and put a reviewer agent in front of every approval packet.
The reviewer can reject. Only a human can approve a consequential action. Its pass is a filter on your queue rather than a bypass around it.
By the VIS Mountain Editorial Team. Published . Updated . The sources behind it are listed below.
Two ways to run a bot team
Most teams start in the left column because it is what the software gives you by default. Everything in the right column is something you have to decide to build.
| Item | One shared room, no roles | Pods with a chief of staff |
|---|---|---|
| Who answers a request | Everyone answers everything | Each bot owns one narrow job |
| Instructions | Pile up and conflict | Short, stable charters per job |
| Who owns the board | Nobody | The chief of staff routes and tracks |
| Who catches a mistake | The client does | The reviewer, before you see it |
| How approvals arrive | As chat noise, all mixed together | As packets, ranked and batched twice a day |
| What done means | Whatever the bot decided | A written line you can check |
The left column is not a strawman. It is the default state of any group chat with several capable agents in it, and it works fine right up until two of them answer the same request differently.
The chief of staff is the only bot that talks to you about priorities
Every request you make, every routine that fires, and every ticket that arrives goes to one bot first. It creates a task file with an owner and a line that says when the task is done, assigns it, and posts it in the pod room.
It never sends email, publishes, or changes an external system itself. It routes and it reports. That single restriction is what makes the role trustworthy: a coordinator with no ability to act cannot quietly become the thing doing the work.
It also removes most of the confusion in a multi agent setup, because there is exactly one place to ask what is happening and exactly one bot whose job is to know. Without that, the answer to what is happening is spread across eight rooms and nobody has read all of them.
Two smaller responsibilities make it useful rather than ceremonial. It enforces a work in progress limit of three tasks per bot. And it flags anything stuck in Doing for more than two days, then moves anything waiting on you into a list you see twice a day.
Pods, and why the group chat size decides the shape
Organise bots by function into pods of four or five, each with its own group chat that also contains the chief of staff and the reviewer. xAI's documentation states that a Grok Bot group chat holds up to six bots, so a pod of four plus those two fills a room exactly. That is a platform constraint turning into an org design, which is unusual but genuinely useful: it stops rooms growing until nobody reads them.
A brand pod, an operations pod, a CRM pod, an SEO pod, an ads pod, a local and social pod, a sales pod and a build and content pod is eight rooms with a clear charter each, which is easier to follow than one room with thirty voices in it.
Handoffs are explicit rather than implied. The sending bot mentions the receiving bot with the task ID in the pod room, and the receiver acknowledges in its next turn or the chief of staff reassigns. Status updates use one shape every time: task ID, status, next step. Three fields, no prose, because a status update that reads like a paragraph will not be read.
What goes in a task file
One file per task, in a shared folder every bot can read. The template is short on purpose, and every field earns its place by removing an argument later.
- Title, owner, and who requested it.
- Which company it is for, which is what ties the task to a brand context version.
- The goal in one sentence.
- A done when line you can check without an opinion. This is the field that decides whether the task gets reopened.
- The access tier the work needs: read, draft or act.
See the full checklist: What goes in a task fileHide the full checklist: What goes in a task file
- Which approvals it will need, named now rather than discovered later.
- Inputs and deadline.
- A timestamped log, and the lesson line at close.
The board has six columns: Backlog, Ready, Doing, Waiting on human, Review, Done. Waiting on human is the one people leave out and the one that tells you the most, because a queue of work blocked on you is the clearest signal that the bottleneck is not the bots.
Done means something different per type of work
Write it once per task type rather than once per task. A vague done when line is the single most common cause of a reopened task.
Content
Done when it meets the quality bar with every fact sourced. Not when it is written, and not when it reads well.
A report
Done when every number traces to a saved screenshot. That rule exists because a number a bot cannot trace is a number it may have invented.
Outreach
Done when the packet was approved, the message was sent, and the reply is tracked. Sending is the middle of the task rather than the end of it.
A build
Done when the QA checklist passed and a human opened the staging link. A build nobody looked at is not finished, it is submitted.
The approval packet, and how a human decides in seconds
Nothing reaches you as a raw chat message. Every action that touches the world is submitted in one shape: the bot name, the task ID and the tier, then what it wants to do in one plain sentence, the exact target, why, the source that triggered it, whether it is reversible and how, the full preview, and the checks it already ran.
One packet is one action. No and also. If any field is unknown, the packet is not ready, which is a more useful rule than it sounds: most bad requests fail on the source field or the reversible field, and failing there is cheaper than failing after you approve.
Read the full breakdown: The approval packet, and how a human decides in secondsHide the full breakdown: The approval packet, and how a human decides in seconds
The reviewer reads it first and returns a pass or a fail with the rule it applied. Fails go back to the owner. Passes go into the chief of staff's digest at 08:00 and 16:00, ranked money and security first, then client waiting, then everything else. Urgent means a client is waiting or money or security is involved, and those come straight through.
On Grok Bot you answer allow once, deny, or always allow, from the desktop or the phone, according to xAI's documentation. Always allow is the one to use sparingly, because it converts a decision into a standing rule without writing the rule down anywhere you will re-read.
How one request becomes one finished piece of work
Read this as the life of a single task. Every arrow is a handoff that has a named owner on both ends, which is the property that makes the whole thing debuggable.
The step people try to remove is the reviewer, on the grounds that it slows things down. It does, by design, and the time it costs is roughly the time you would otherwise spend reading a packet that was never going to be approved.
The step people try to remove second is the lesson line, on the grounds that it is busywork. It is the only input the Friday retro has, and a team with no retro input stops improving on about week three.
Coordination fails when two bots hold two versions of a fact
The cure is one document per company that every bot reads and only one bot edits: identity and locations, canonical services, voice with say and never say lists, market and competitors, the digital footprint with every ID, rules of engagement, assets, plan and change log.
Its status gates the work. Nothing is built, written, posted or advertised until the brand context is approved, and every deliverable cites the version it used. That last detail is what makes a rollback possible: if a fact was wrong, you can find everything produced against the version that carried it.
A bot that needs a fact the file does not contain asks the owner to add it. It does not improvise, and it does not search for it and use what it found. Improvised facts are the single most damaging failure mode in a multi agent setup, because they are confident, plausible and repeated.
Standup, digest, review
Every one of these is a routine on the chief of staff bot, created after the workspace is seeded rather than before.
- 07:30 standup, written by the chief of staff: done yesterday, doing today, blocked, approvals waiting, risks.
- 08:00 approval digest, ranked money and security first, then client waiting, then everything else.
- 16:00 approval digest, same ordering.
- Friday 15:00 review with the learning officer: throughput, approval rate, denials, incidents, and which lessons were promoted into skills or rules.
Two digests a day rather than a live stream is the decision that makes this survivable. An agent team that interrupts you whenever it wants to act has moved the bottleneck from the work onto your attention.
The four ways coordination falls apart
The chief of staff starts acting. Somebody asks it to just send this one, it does, and within a fortnight the coordinator is also a worker and nobody can tell what it has done. The fix is to make routing and reporting the whole of its charter, with an explicit never list.
The work in progress limit gets ignored. Three per bot exists because a bot with nine open tasks produces nine half finished ones, and the board stops being a picture of reality.
Read the full breakdown: The four ways coordination falls apartHide the full breakdown: The four ways coordination falls apart
The packet format gets relaxed for urgent things. Urgent is exactly when the source field and the reversible field matter most, and the first request that skips them is usually the one that came from a hostile email.
The pod rooms grow. Adding one more bot to a working room is always the easy decision, and the room stops being readable somewhere between six and ten participants regardless of what the platform allows. OWASP's Top 10 for LLM applications lists excessive agency as its own risk, and an over full room with no clear owner is one of the ways it arrives.
The other six parts
Seven pages, written to be read in any order. Each one owns a single part of the system so none of them has to repeat the others.
The complete A to Z guide
The whole system in one place: roles, approvals, the shared brand file, and the phased rollout that starts read only.
Read the guideSet up your first agent
The forty minute sequence that decides whether an agent is a colleague or a liability, including the charter format.
Read the guideEmail and inbox security for agents
The three absolutes, the five sender checks, the label scheme, and the incident rule that makes slips reportable.
Read the guideMaintain a team of agents
The lesson line, the Friday retro, the weekly access audit, the metrics that tell you the truth, and the kill switch.
Read the guideWhy one agent is not enough
Why the do everything assistant is the setup most people abandon, and which of its failures a team actually fixes.
Read the guideGrok Bot vs Hermes Agent vs OpenClaw
Managed against self hosted: where each one runs, who is responsible for securing it, and which suits which situation.
Read the guideWant to see what this looks like applied to a marketing team?
The pods in this guide map fairly directly onto how agency work is actually split. We are happy to walk through which parts transfer and which do not.
No affiliation. VIS Mountain is not affiliated with, sponsored by or endorsed by any product named on this page, and none of them reviewed or approved it. Grok Bot and Grok are trademarks of xAI. Cursor is a trademark of Anysphere, Inc. Hermes Agent is a project of Nous Research. OpenClaw is an open source project of its maintainers. Google, Gmail, Facebook, Meta and other product names are trademarks of their respective owners. Every product name and logo shown here belongs to its owner and appears only to identify the product this page describes.
Informational only. This is general information about configuring AI agent software. It is not legal, cybersecurity, financial or professional advice, and reading it does not create a client relationship with VIS Mountain. Consult a qualified professional before relying on it for your own systems, data or compliance obligations.
Read the full breakdownHide the full breakdown
Accuracy, timeliness and attribution. Everything specific to a named product on this page is what that product's own documentation, or a named security researcher, published as of September 2026, not a claim we are making on our own authority. We link to each source rather than restate it as our own finding. Features, plans, limits and security details can change without notice and all of these projects change quickly, so verify current terms with each vendor before purchasing, deploying or granting access.
No guarantees, and your responsibility. AI agents can make mistakes and can be manipulated. No configuration described here eliminates risk. Results, security outcomes and cost depend on your implementation. You are responsible for complying with the laws and platform terms that apply to you, including privacy and data protection laws, anti spam and telemarketing rules such as CAN-SPAM and the TCPA in the United States, industry rules such as HIPAA where applicable, and each vendor's terms of service.
Third party links. External links are provided for reference. VIS Mountain does not control and is not responsible for the content, availability or practices of third party sites.
How this was made. First published on 3 September 2026 and migrated to this site with its disclosures intact, because they are the part that tells you how far to trust it. Prepared by the VIS Mountain editorial team with the assistance of AI tools and reviewed by a human before publication. Examples are generic and describe no specific client, person or account.
No warranties. Provided as is, without warranties of any kind. To the fullest extent permitted by law, VIS Mountain disclaims liability for losses arising from use of this information.
Straight answers.
Why does one agent have to be the chief of staff?
Because otherwise there is no single place to ask what is happening. With several capable agents in one room, a request gets answered by whoever responds first, two of them start the same work, and the board is whatever anybody remembers.
The role only works if it cannot act. A coordinator that also sends email quietly becomes a worker, and then nobody is coordinating. Routing and reporting is the entire job.
How big should a pod be?
Four or five bots, plus the chief of staff and the reviewer in every room. On Grok Bot that is also the platform ceiling, since xAI's documentation states a group chat holds up to six bots.
The constraint is doing you a favour. Rooms stop being readable somewhere around six participants regardless of what any platform allows, and eight small rooms with clear charters are easier to follow than one room with thirty voices.
What exactly goes in an approval packet?
The bot name, the task ID and the access tier, then what it wants to do in one plain sentence, the exact target, why, the source that triggered it, whether it is reversible and how, the full preview, and the checks it already ran.
One packet is one action, with no and also. If any field is unknown the packet is not ready. Most bad requests fail on the source field or the reversible field, which is exactly where you want them to fail.
Can the reviewer approve things instead of me?
No. The reviewer can reject, and it returns a pass or fail with the rule it applied. Only a human approves a consequential action, and that line does not move.
What the reviewer buys you is a shorter queue. By the time a packet reaches you it has already been checked against a written rule, which is why the approval without edit rate is a useful number to watch.
How do I stop approvals turning into constant interruptions?
Batch them. Two digests a day, at fixed times, ranked money and security first, then client waiting, then everything else. Urgent means a client is waiting or money or security is involved, and only those come straight through.
If the digest is still overwhelming, the problem is usually upstream: too many tasks in flight, or an access tier set to act where draft would do. Both are fixed on the board rather than in the notification settings.
What stops two agents producing contradictory work?
One brand context file that every bot reads and only one bot edits, with a status that gates the work and a version that every deliverable cites.
The rule that makes it hold is that a bot needing a fact the file does not contain asks the owner to add it rather than improvising or searching for it. Improvised facts are the most damaging failure in a multi agent setup, because they are confident, plausible and then repeated by everything downstream.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- xAI: Grok Bot documentation (opens in a new tab)The vendor's own description of bots, the cloud computer, memory and sessions.
- xAI: Grok Bot approvals, security and privacy (opens in a new tab)Where the approval prompt, the Auto Review layer and the local execution setting are documented.
- OWASP: Top 10 for LLM applications and generative AI (opens in a new tab)Where prompt injection is ranked first and excessive agency is listed as a separate risk.
- NIST: AI Risk Management Framework (opens in a new tab)A published framework for documenting who is responsible for an AI system's risks.
- xAI: Grok Bot for teams and enterprises (opens in a new tab)Admin policies, allowlists, and what isolation the platform provides between members.
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.