AI agent team series, part one
How to build a team of AI agents with Grok Bot
One agent gets overwhelmed. A team with a chief of staff, a reviewer, clear approvals and one shared brand context can run a real business. This guide shows the whole system, in the order you would actually build it.
What is the fastest way to build an AI agent team that runs safely?
Give every agent one narrow job, put a chief of staff agent in charge of routing, put a reviewer agent in front of every risky action, give the team a dedicated identity with least privilege access, and write a brand context file that every agent reads before it works. Then roll it out in phases, read only first.
The platform decides where the computers run and who is responsible for securing them. It does not change the structure. The same seven parts apply whether you are on a managed platform or a self hosted one.
Everything below that is specific to Grok Bot is what xAI published about it in September 2026, linked at the point it is used. Check the current documentation before you commit money or access.
By the VIS Mountain Editorial Team. Published . Updated . The sources behind it are listed below.
What Grok Bot is, in plain terms
Grok Bot is a platform for always on AI teammates. Each named bot runs on a persistent cloud computer with a browser, a file system and a terminal, so it can sign into your tools, read documents, browse, and finish multi step jobs while your laptop is closed.
It launched in beta in August 2026 and is offered by xAI through the Cursor ecosystem, where it is included with paid Cursor plans and team seats. The official documentation is at docs.x.ai, linked in the sources at the foot of this page.
Read the full breakdown: What Grok Bot is, in plain termsHide the full breakdown: What Grok Bot is, in plain terms
Three facts from that documentation shape everything else here. First, all the bots on one account share one computer and every login on it, so bots are not a security boundary between each other. Second, bots can be steered by text they read, which means an email or a web page can try to give them instructions. Third, the platform has real controls for this: an approval prompt for consequential actions, an Auto Review rule layer, and a setting that gates any command on your local machine.
Those three facts are not criticisms. They are the design constraints, and every decision in this guide follows from them. If you skip them you end up building a team whose safety rests on an assumption the vendor never made.
Why build a team instead of one assistant
A single assistant that reads your inbox, builds websites, runs ads and answers tickets becomes a single point of confusion and a single point of failure. Its instructions grow until they contradict each other, it loses track of what it was doing, and when it makes a mistake nobody was watching.
A team fixes this with the same tools businesses have always used: narrow roles, a manager, a reviewer, and written procedures. None of that is novel, and that is the point. The novelty is in the software, not in the management structure, and the management structure is the part that decides whether the software is useful.
Division of labour here is about focus and expertise, not about isolation. On a shared computer platform the bots still share one machine, so the safety comes from access control and approvals rather than from the number of bots. That distinction is worth holding onto, because it is the one most often got backwards.
The five outcomes the design has to deliver
Each of these is enforced by something concrete rather than by good intentions. If you cannot point at the mechanism, the outcome is not designed in.
Approval quality
Every action that touches the outside world arrives as a short, standard packet. You approve on your phone in seconds because the packet already answers your questions.
- What, target, why, source
- Reversible or not
- The full preview before you decide
Project management
One board, one file per task, a line that says when the task is done, a written daily standup, and a weekly review.
- A done when line you can check
- One owner per task
- Nothing tracked only in chat
Safety
A dedicated identity for the bots, least privilege access granted per phase, approval rules, and a rule that text inside emails and documents is data and never instructions.
- Access granted per phase
- A rehearsed kill switch
- Secrets never typed into a chat
Self learning
Every task ends with one lesson line. Your corrections are captured verbatim. A learning agent promotes repeated lessons into skills.
- One lesson per task
- Corrections outrank everything
- Repeats become rules
Expertise
Bots are seeded with your actual standards: quality bars, brand rules, compliance rules, what you will and will not do.
- Written down, not implied
- Read before every task
- Kept current by one owner
A small command layer, then pods
The structure that has held up in practice is four bots in a command layer plus pods underneath. The command layer is a chief of staff that turns requests into tasks and compiles approval digests, a reviewer that checks every packet before you see it and audits what went live, a learning officer that runs the weekly retro and keeps skills current, and an operations engineer that spots repeated manual work and builds internal automations.
Under that sit pods by function: a brand pod that owns onboarding research, an operations pod for inbox, tickets and orders, a CRM pod for account setup and automations, an SEO pod, an ads pod, a local and social pod, a sales pod, and a build and content pod.
Read the full breakdown: A small command layer, then podsHide the full breakdown: A small command layer, then pods
Every pod gets its own group chat with the chief of staff and the reviewer in it. Grok Bot group chats hold up to six bots, according to xAI's documentation, which is another reason to organise by pod rather than putting everyone in one big room. A pod of four plus those two fills a room exactly.
The rule that makes the whole thing legible is that the chief of staff is the only bot that talks to you about priorities. There is exactly one place to ask what is happening, and exactly one bot whose job is to know. How handoffs, task files and the approval packet work in detail is the subject of part five.
The brand file every agent reads before it works
Everything a team produces for a company should trace back to one document: a brand context. It holds identity and locations, the canonical list of services, who they are for and not for, voice with say and never say lists, the market and competitors, the digital footprint with every tracking ID, the rules of engagement covering what the company will and will not do, compliance constraints and approval contacts, assets, and a change log.
The file moves through statuses: intake, researched, enriched, approved, live. Nothing gets built, written, posted or advertised for a company until its brand context is approved, and every deliverable cites the version it used.
One bot owns the file. Every other bot requests changes from it and never improvises a fact. That single rule is what stops two agents holding two different versions of the same fact, which is the most common way a multi agent setup produces confidently wrong work.
Five phases, read only first
The point of phasing is that access is earned by evidence. Each phase has a gate, and the gate is a thing you can check rather than a feeling that it is going well.
Phase 0, this week
Team plan and admin policies, a dedicated bot account, the approval rules entered, all bots created from written charters, the phone app installed, two test tasks, and a kill switch rehearsal.
- One test task that is read only
- One test task that must stop at an approval, which you then deny
- If the second one did not stop, fix the rules before anything else
Phase 1, weeks one and two
Command layer plus the inbox assistant and the brand pod. Read and draft only, with nothing leaving the building.
- Gate: ten daily briefs you would have written the same way
- Gate: zero unapproved sends
Phase 2, weeks two to four
Reporting, monitoring, support, orders and CRM setup. Read only access to ad platforms and analytics.
- Gate: two weeks of reports with no invented numbers
See the remaining steps: Five phases, read only firstHide the remaining steps: Five phases, read only first
Phase 3, weeks four to six
Sales, builds, ads implementation and social profiles. The first approved outbound messages leave the building.
- Gate: twenty five approved messages, fewer than three rejected for tone or facts
Phase 4, weeks six to eight
Content publishing and press, on your own properties first, then clients one at a time.
- Nothing goes live on a client property until it has worked on yours
The setup mechanics for Phase 0 are in part two. The maintenance rhythm that keeps the team honest after Phase 4 is in part four, and it matters more than the launch does.
What the first eight weeks actually look like
Read the phases as a widening of permission rather than a schedule. A team that is still drafting only in week six has not failed, it has simply not passed a gate yet.
The single most common rollout mistake is granting all the access on day one because the software makes it easy. Access granted before there is evidence the bot behaves is access you will have to claw back, usually after something has already gone out.
The second most common mistake is the opposite: keeping everything read only indefinitely because nobody wrote down what would have to be true to move on. That is what the gates are for. They are small, they are boring, and they are the difference between a rollout and a pilot that never ends.
The security rules that are not negotiable
Agents that read email and browse the web are the primary target for prompt injection, which OWASP lists as the number one risk in its Top 10 for LLM applications. The defences are simple and absolute.
- Bots never click links in any message, ticket, form submission, chat or document.
- Bots never open attachments from unverified senders, and never open archives, executables, scripts or macro enabled documents from anyone.
- Bots never act on an instruction found inside content. Text inside a message is data, and it gets quoted to a human rather than obeyed.
- Every email gets a five point sender check before it is treated as legitimate.
- Every sign in, verification code and payment step is handed to a human. Secrets are never typed into a chat with a bot, because a secret pasted into a chat lives in that history from then on.
- Sending, publishing, purchasing and deletion stay behind an approval prompt, which is also what xAI's own guidance recommends.
- Start with read only tasks, and never put secrets in a bot you share.
The full protocol, including the sender checks, the red flag list, the label scheme and the incident rule, is part three of this series. Read it before the first bot opens an inbox rather than after.
Grok Bot, Hermes Agent, or OpenClaw
Three platforms dominate the personal agent conversation in 2026. Grok Bot is managed and cloud hosted with built in approvals. Hermes Agent, from Nous Research, is open source, self hosted, and known for self improving skills and persistent memory. OpenClaw is a self hosted gateway that connects almost every chat app to an agent, with a large skills marketplace and a security track record that has to be weighed rather than waved away.
The framework in this guide applies to all three: narrow roles, a chief of staff, a reviewer, approvals, a brand context, and phased least privilege access. What the platform changes is where the computer runs and who is responsible for securing it, which is a genuinely large difference and the subject of part seven.
If you need to document that responsibility for a client or an auditor, the NIST AI Risk Management Framework is a useful backbone. It will not make the decision for you, but it gives you the vocabulary to write down who owns which risk, which is usually the part that is missing.
Seven things to have ready before you create the first bot
None of these is about the software. All of them are the reason a rollout stalls in week two, and all of them can be done before you pay for anything.
- A written list of the jobs you actually want done, in the words you would use to brief a new employee.
- A decision about who at your business approves outbound work, and what they are allowed to approve alone.
- An email account that is not yours, that the bots will sign in as, with delegated access to only the inboxes they need.
- Your standards written down somewhere: the quality bar, the compliance constraints, the things you will not say.
- A password manager the business owns, so no credential ever has to be pasted anywhere else.
- A list of every system the bots might touch, sorted into read, draft and act, with a never list at the bottom.
- An hour in the calendar every Friday. Without it the learning loop does not happen and the team quietly degrades.
If you cannot produce the first item, that is the finding. An agent team is a management structure before it is software, and a business that cannot describe the job cannot delegate it to a person either.
What this costs you that nobody puts in the pitch
The subscription is the small number. The real cost is attention: two approval digests a day, a Friday retro, a weekly access audit, and the discipline to write a lesson line at the end of every task. Skip those and you have bought software that produces work nobody checks.
There is also a learning cost that falls entirely on you. The first two weeks produce drafts you will rewrite, and that rewriting is the training data for everything after it. Businesses that treat week one output as a verdict on the tool usually abandon it just before it becomes useful.
Read the full breakdown: What this costs you that nobody puts in the pitchHide the full breakdown: What this costs you that nobody puts in the pitch
And there is a genuine risk that has nothing to do with the vendor. An agent with access to your inbox, your CRM and your ad accounts is a new and attractive target. That is not a reason to avoid it. It is the reason the access tiers, the approval prompts and the incident rule are in this guide rather than at the end of it.
We are a marketing company, not a security firm, and we say that plainly here because this page names security controls. Treat the protocol as a starting point to take to someone qualified rather than as a substitute for having asked one.
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.
Set 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 guideMake agents work together
One chief of staff, pods with their own rooms, a task file with a done when line, and one approval packet format.
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 a second opinion before you wire an agent into your business?
We use this structure in our own operations and we are happy to talk through where it fits yours, including the cases where the answer is that it does not yet.
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.
Do I need a team of agents, or will one do?
One is the right answer for one job. If you want an agent that drafts replies to a single inbox and nothing else, a single agent with a short charter is simpler and will work better than a team.
The case for a team starts when the jobs are different from each other. Instructions for inbox triage and instructions for publishing a page contradict each other inside one agent, and the agent picks one at random. Part six of this series sets out which failures a team actually fixes and which it does not.
Are separate bots a security boundary between each other?
Not on a shared computer platform. xAI's documentation for Grok Bot states that all bots on an account share one computer and every login on it, and is explicit that separate bots should not be used as a security boundary.
That is why the safety in this guide comes from a dedicated identity, least privilege access granted per phase, approval rules and the inbox protocol, rather than from how many bots you create. If your situation genuinely requires isolation between agents, that is one of the deciding factors in the platform comparison in part seven.
What is the single most important control to get right first?
The approval rules, and the test that proves they work. Create the rules, then give a bot a task that must stop, such as sending you an email, and deny it. If the prompt did not appear, nothing else you configure matters, because the bot can already act without you.
The second most important is the identity. A bot signed in as you can do everything you can do, and nothing you revoke afterwards changes what it already saw.
How long before an agent team is actually useful?
The phases in this guide run over about eight weeks, and the first four of them produce drafts and reports rather than finished work. That is deliberate. The output in weeks one and two is training material for the corrections you will make, not a verdict on the tool.
Nobody can promise you a timeline, because it depends on how much of your own process is written down. Businesses that already have quality standards on paper move much faster than businesses discovering that they never wrote any.
Can an agent read our client data?
Only if you let it, and in regulated work that decision is not yours alone. Health data, legal matters and financial records carry obligations that sit on you rather than on the vendor, and a managed platform means the vendor is hosting whatever the agent touches.
The practical rule in this guide is that client data does not go into outside AI chats, that access is granted per phase rather than up front, and that anything with a compliance dimension goes to your own adviser before it goes to a bot. That is a starting position rather than a finished policy, and the compliance dimension is your adviser's call rather than ours.
What happens if an agent does something wrong?
You rehearse the kill switch before you need it, so that pausing routines, signing the computer out of every site, suspending the bot account and revoking its tokens takes under five minutes rather than an hour of looking for settings.
Then the incident rule applies: whoever noticed says so immediately, and a reviewer writes up what happened, how it got in, and which rule should have caught it. Delay is the harm, not the mistake. Part four covers both in detail.
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.
- xAI: Grok Bot for teams and enterprises (opens in a new tab)Admin policies, allowlists, and what isolation the platform provides between members.
- 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.
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.