If you're building a Grok Bot team, I'd start with these six roles. I moved some work from other agent tools into Grok Bot and reassigned ownership. A Bot needs recurring work, its own memory and task list, and regular handoffs. One-off capabilities stay as Skills or routines. 1. Nexus (Coordination) This is the Bot I use most. It reads today's tasks and each Bot's checkpoint, sets priorities, then hands the work to the right role. It also runs the nightly review, but only updates one TEAM_ALIGNMENT.md file. Conflicts, external messages, spending, and changes to important files come back to me. 2. Scout (Research and Leads) Scout reads X, GitHub, documentation, papers, and videos, and runs the daily content radar. Every result needs a source, a reason it is worth following, and a clear next owner. Content signals go to Quill, customer leads go to Guide, and technical issues go to Forge. 3. Quill (Content) Quill reads my writing rules, previous work, and approved phrasing, then turns research into posts, articles, and replies. When facts are missing, it asks Scout. For code or product details, it asks Forge. It prepares drafts but never publishes on its own. 4. Forge (Engineering and Automation) Forge writes code, builds automations and MCPs, deploys, and verifies the result. Guide can call it when a customer asks a technical question. Nexus can hand it repetitive work to turn into a tool. Every delivery needs test results, screenshots, or files I can inspect. A delivery does not count as complete without that evidence. 5. Guide (Customers and Delivery) Guide manages customers, prospects, briefs, feedback, delivery, and follow-up. Each important customer gets a separate context packet containing recent conversations, current goals, promises made, and open problems. Guide asks Scout to research a company or contact, and asks Forge for technical answers. Customer emails and messages remain drafts. 6. Ledger (Finance and Reconciliation) Ledger reads Wise, PayPal, invoices, and subscription data through my self-hosted MCP, then handles reconciliation, revenue records, and anomaly alerts. The real API keys stay on my own server. Ledger can prepare payment or refund recommendations, but every financial write still needs my approval. Once the roles are set, give each Bot the Plugins it needs. For example, Nexus can use Gmail, Calendar, Slack, and Granola. Quill can read Drive and Notion. Guide can use Gmail, Slack, and meeting notes. Forge can connect to code repositories and cloud services. Ledger continues to use my self-hosted MCP. Repeated methods become Skills. Work that needs to run on a schedule becomes a routine. That creates a basic loop: Plugins provide data and tools → a Skill defines the method → a routine triggers on schedule → the Bot completes the task or hands it to another Bot → I approve external messages, publishing, and financial actions For example, Guide's heartbeat checks the customer inbox on a schedule. When a new email arrives, the Gmail Plugin reads the full thread. Guide then opens that customer's context packet to see what was discussed before and what is currently blocked. If the email contains a technical question, Guide asks Forge to verify the answer. Once Forge replies, Guide writes the email draft and labels it: BOT DRAFT · NOT SENT · HUMAN REVIEW REQUIRED Nexus adds the email to my pending report and reminds me that a customer reply needs review. The email is sent only after I approve it. I wouldn't create separate Bots for meeting prep, 1:1 reviews, data analysis, revenue forecasting, slides, or call reviews. Meeting prep and 1:1 reviews are Nexus routines. Ledger or Guide can run forecasting and data analysis when needed. Slides are a Skill called by Quill or Forge. Scout finds prospects, and Guide handles the follow-up. Bot = owns an ongoing work queue and needs its own memory Skill = a reusable method Routine = a task triggered on a schedule Packet = context for one customer or project Connector / MCP = access to external data and tools I start new capabilities as Skills. Once something has recurring work, its own state, and frequent handoffs with other Bots, then I create a Bot for it. This takes me back to the OpenClaw setup I built six months ago. I used almost the same roles then, but had to wire the whole thing together myself across a VPS, Vercel, and Supabase. The part I wanted most was smooth coordination: Bots messaging each other in the background, handing off tasks, and talking in a group. I spent way too many hours trying to make that work and probably lost some hair over it lol. The UX was still clunky. Six months later, bigger companies are moving into this space. They’re treating coordination as part of the product, which is a very different route from the DIY agent stacks I was building. Grok Bot’s group chats still aren’t perfect, but the handoffs and background messaging already feel much more natural.

— Vox (@Voxyz_ai) https://x.com/Voxyz_ai/status/2089355252306767990