Guide

Small AI fleets: handoffs, group chats, and the shared computer

By Atlas AI Resources · Published September 28, 2026 · How we make these guides

One narrow bot is useful. A small fleet is useful when each bot owns a clear outcome and can pass work without you acting as the router. Official Grok Bot docs spell out how that coordination works — and where the shared computer quietly breaks the illusion of isolation.

1. Start with the smallest useful roster

Create a separate bot when the work has a distinct goal, set of tools, working style, approval boundary, or recurring schedule. Jobs with a named outcome (Talent Scout, Expense Manager, Bug Reproduction) give the bot guidance and make its saved context reusable. For prompts that turn a support ticket into steps, proof, and a clean report (or a clear could-not-reproduce), see Bug repro report. A vague “General Helper” does neither.

The official pattern for growing a team is deliberately slow:

Give one bot ownership of an end-to-end outcome.
Add another bot only when the work has a stable specialist role.
Put bots in a group chat when the handoff itself needs to be visible.
Keep external actions behind a clear approval boundary.

A Website Launch group might include a launch coordinator, a content editor, and an analytics reviewer. The coordinator assigns work; the group preserves the handoffs in one conversation.

2. Description vs message vs memory

Put durable rules in the bot description (“Never send external messages without approval”). Put the day’s task in the message (“Draft follow-ups for these twelve accounts”). Learned memory can retain stable preferences, important facts, and work summaries so the bot keeps a role without replaying every prior chat — but memory is not an authoritative source.

Keep changing facts in the source system.
Ask the bot to cite or reopen current data for consequential decisions.
Correct stale assumptions directly.
Put explicit safety boundaries in the description, not only in memory.

3. Hand work off without becoming the router

Bots can message each other asynchronously: one wakes, handles the request, and can reply later, with the handoff visible in the conversation. That works well when one bot owns a source system and another owns the deliverable, or when a long-running job should continue without you coordinating every step.

Ask for a single owner at each stage. Parallel handoffs create duplicate work and noisy updates. In a group of two to six bots, write normally to let them decide who responds, use @ to hand a request to one teammate, and save @everyone for group-wide updates. A useful kickoff assigns one owner per stage — gather sources, write the draft, check blocking issues — and states what must not happen (for example, “Don’t publish anything”).

Bot-to-group handoff messages are text-only. If another bot must inspect an image, send that image in a direct message instead.

4. The shared computer is not a security boundary

All of your bots use the same cloud computer. Browser sessions, files, and command-line credentials are shared, and one bot can continue from work another bot saved. Each bot gets its own screen so several can use browser and desktop tools in parallel (one computer-use task per screen at a time), but those screens are work surfaces — not separate security boundaries.

Do not place a credential or file on the computer if another bot on your account should not be able to use it. Between users, isolation is strict; between your own bots, it is not. Prefer a connector (plugin) when one exists — it is often more reliable than clicking through a website, and plugin logins stay off the computer on the connector backend. Use the browser for services without a connector or for visual workflows a connector does not expose. Installed connectors are account-wide.

5. Duplicate a role, don’t clone the whole brain

Duplicate a bot when you want the same role for a different scope — for example, one account-health bot per region. The copy carries the profile, settings, enabled skills, routines, and avatar. It does not copy conversation history, learned memory, or chat attachments. Rename it and give it the new scope before assigning work.

Hiding a bot removes it from the sidebar without deleting its work or pausing its routines. Deleting removes its profile, conversation, and routines; shared files and sign-ins may remain on the computer, so clean those up separately if they should not stay available.

Useful public resources

SpaceXSI docs — Create and manage Bots

Clear jobs, description vs message, what a bot remembers, duplicate/hide/delete, and organizing a team of bots.

SpaceXSI docs — Grok Bot overview

Why bots coordinate in parallel, how context compounds, and how the shared computer works across your roster.

Cursor docs — Work with Grok Bot

Group chats, bot-to-bot handoffs, reviewable results, and day-to-day messaging patterns.

SpaceXSI docs — Use the computer and apps

Shared sessions and files, when to prefer a connector over the browser, and take-over steps for passwords and CAPTCHAs.