How to Set Up Grok Bot as a Multi-Bot Operations System for Your Business

By Elie Mendlow

Introduction

This post is the long-form follow-up to the pinned infographic on X. If you have not seen it yet, start with the MCAFax setup infographic post on X, then come back here for the step-by-step version.

Grok Bot is a personal AI assistant app where you can run many bots side by side. Each bot has its own chat, its own memory, its own routines, and its own connectors to tools like email, calendar, file storage, and a work board. That makes it possible to build something closer to an operations team than a single chatbot.

The catch is that a team of bots fails the same way a team of people fails: two people edit the same record, nobody owns the inbox, approvals get lost in side chats, and somebody sends the wrong email at the wrong hour. Every rule below exists because something like that went wrong once. Throughout, we use a generic healthcare staffing agency as the example business.

Does it work? One real example: a recruiting agency we run on Grok Bot: about 2 months in, one admin does what took 4+, revenue has doubled, and we canceled an expensive ATS.

Step 1: Draw the org chart before you create a single bot

Start on paper. Decide what your departments are and what "done" means for each one. A typical shape is one front-door chief of staff bot, a handful of department leads, and specialist bots under each lead. A mature setup can grow to about two dozen bots, but you should start with far fewer and add bots only when a lane is clearly overloaded.

• Front-door chief of staff: the only bot you talk to for approvals and daily priorities. It routes work, it does not do all of it.
• Department leads: one per area, for example business development, finance, account management, marketing, and operations. Each lead owns its lane's results and reports up.
• Specialist bots: narrow jobs such as inbox routing, invoice follow-up drafts, job posting drafts, or meeting notes.

Give each department a color or icon on its bot avatars so you can tell lanes apart at a glance.

flowchart TD
    O[Owner] --> FD[Front-door chief of staff bot]
    FD --> BD[Business development lead]
    FD --> FIN[Finance lead]
    FD --> AM[Account management lead]
    FD --> MKT[Marketing lead]
    FD --> OPS[Operations lead]
    IR[Inbox router] --> BD
    IR --> FIN
    IR --> AM
    BD --> S1[Specialist: outreach drafts]
    FIN --> S2[Specialist: invoice follow-up drafts]
    AM --> S3[Specialist: client updates]
    MKT --> S4[Specialist: content drafts]
    OPS --> W[Detect-only watchers]

Also decide up front which moments stay human. In a staffing business that usually means contracts, sales calls, confirming a job description, making an assignment, and any decision to stop working with someone. Bots prepare; people decide.

Step 2: One writer per board or system of record

Pick the system of record for each kind of work: a board for open jobs, a board for clients, a board for candidates, a ledger for money. Then give every board exactly one AI owner. Only that bot writes to it.

Any other bot that notices a change sends it to the owner bot along with the source, such as the email or file it came from. The owner bot decides whether to apply it. This one rule stops most board drift, duplicate rows, and arguments about which version is right. Write the rule into each bot's instructions and keep a short list of who owns what.

Step 3: One inbox router

Do not let every bot crawl the mailbox. Assign a single inbox router bot that reads incoming mail and hands each relevant fact to the bot that owns it, with the message reference, sender, date, and a short quote. Nobody else reads the inbox directly.

The same idea applies to the calendar: one bot writes calendar events, everyone else asks it. One reader per input means one place to look when something gets missed.

Step 4: All approvals in one front-door chat

When you run many bots, the fastest way to lose control is to have approvals scattered across a dozen chats. Make the front-door chief of staff bot the single place where every approval request and every draft email card lands. Department bots do not ask you directly; they ask the front door, which batches and presents the request.

flowchart LR
    D[Department bot drafts message] --> G{Send gates pass?}
    G -- No --> F[Stays a draft with a one-line flag]
    G -- Yes --> Q[Owner-yes queue]
    Q --> FD[Front-door chat shows the card]
    FD --> Y{Owner presses send?}
    Y -- Yes --> S[Message sends or is scheduled]
    Y -- No --> R[Back to the bot with notes]

Step 5: Send gates and an owner-yes queue

The core rule: bots draft, the owner presses send. No external email goes out without a yes on that exact message. Later you can unlock a short, named list of standing sends (for example a routine confirmation) but only after that type of message has run cleanly several times in draft mode.

Before a draft even reaches you, run it through gates. If any gate fails, it stays a draft with a one-line explanation. Useful gates:

• Clean artifact: no leftover tool markup, tags, or formatting junk.
• Preview: the message looks right as the recipient will see it.
• Money check: before chasing a payment, confirm it is actually unpaid in the ledger.
• Recipient allowlist: billing messages go only to approved billing contacts.
• No duplicates: check what was already sent before sending again, one at a time.
• Thread context: the reply fits the conversation it belongs to.
• Calendar check: any proposed date is a real working day and the weekday matches the date.
• Recipient hours: messages approved late are scheduled for the recipient's business hours, for example held overnight rather than landing after 10 PM. Scheduled sends re-check the gates when they fire.

Keep an owner-yes queue: a simple list of everything waiting on you, with what it is, how long it has waited, the proposed action, and the source. If something sits too long, the front door reminds you once. Nothing in the queue ever auto-sends.

Step 6: Detect-only watchers

Some bots should only watch. A watcher that checks for replies, compares two systems for mismatches, or reviews meeting notes should write nothing. When it finds a problem, it sends the fix to the bot that owns that board or message. Splitting detection from action keeps watchers from quietly creating a second source of truth.

The same split applies to money: one bot does the step, a different bot checks it. Nothing is self-certified, and no bot ever invents a figure. Money numbers always cite the ledger or the bank record.

Step 7: Run locks so two runs never collide

Routines can overlap: a slow run is still going when the next one starts, or two copies of the same routine exist by accident. Give each routine a run lock, a small marker keyed to the run date or window. A run checks the lock first and stops if another run already holds it. This prevents double sends, double updates, and duplicate reports. Also merge duplicate routines whenever you find them.

Step 8: Stay quiet when nothing changed

A bot that reports "all clear" every hour trains you to ignore it. The rule is quiet when clean. Bots message only when something changed or needs a decision.

There is one exception for new routines: for the first several days, have a new routine report a short pass, fail, or quiet-with-reason so you know it is actually running. Once it has a clean streak, let it go silent.

Two habits help here:

• Delta, not restate: keep a shared daily file where each lane appends only the few lines that changed. Bots read it before messaging each other.
• Digestible output: short bullets and one clear ask, or a sheet plus a few bullets.

Avoid fleet-wide broadcasts. Rule changes go to the front door, which forwards them only to the bots they affect.

Step 9: Routines and cadence

Set a rhythm and keep it boring:

• Daily: each area produces one merged digest. A hang detector notices if an expected digest is missing and sends one alert.
• Owner hour: once a day, spend a focused block reading the board, clearing the owner-yes queue oldest first, checking money, and making one deep move.
• Weekly: department leads report, the audit runs, a weekly report is assembled, next week's drafts are prepared, and you hold a review.
• Monthly: a short rollup of trends and open issues.

Pick times that fit your own business; for example a digest at 4 PM gives you time to act before the day ends.

Step 10: A weekly audit bot with rubrics and a scorecard

Add one audit bot whose job is to check the system, not run it. Each week it reviews three layers: the boards (is data complete and current), the bots (did each do what it claims), and the written procedures (are they still true). Score each against an explicit rubric.

Two rules keep the audit honest. First, anything the auditor could not check is marked unverified and never raises a score. Second, every line on the weekly scorecard has one owner and one cited source. Red lines become agenda items in the weekly review.

Keep a versioned handbook of your rules with a changelog that notes why each rule was added. Have the auditor periodically confirm that every new rule actually reached every bot's instructions.

Step 11: Keep usage down

Scheduled runs add up fast, and most of them often find nothing to do. Lessons that apply to almost any setup:

• Slow down pollers to match how often the work really changes.
• Once a thread goes cold, end watches that ask "did they reply?"
• Be careful with group rooms: every post can wake every member.
• Batch non-urgent cards instead of relaying each one.
• Merge duplicate routines and add run locks.
• Archive retired bots for real; a paused bot with live routines may keep firing.

Review usage from the first week, not after the bill surprises you. A few settings changes often cover a large share of wasted runs.

Step 12: Use MCAFax skills instead of rebuilding from scratch

You do not need to reinvent every rule above. MCAFax publishes its playbooks as public knowledge, and the simplest way to use them is one broad MCAFax skill that your AI loads when it needs guidance. Instead of pasting long instructions into every bot or rediscovering the same lessons, your bots pull the relevant public knowledge on demand. That saves setup time and keeps token use down, because the knowledge is loaded only when it is needed.

Start with the MCAFax skills page. For background on why a loaded skill beats pasting long prompts, read AI skills vs prompts for a small business, and for a concrete example see the lead follow-up automation prompt guide.

Replication checklist

Work through these in order:

1. Map your pipeline, with an owner and a win condition for each stage.
2. Give every board one writer and a short written procedure.
3. Assign one inbox reader.
4. Assign one calendar writer.
5. Set up one front-door chat for all approvals.
6. Build send gates before the first outbound message.
7. Start everything draft-only; unlock standing sends only after clean runs.
8. Split detection from action with detect-only watchers.
9. Write money rules: cite sources, separate executor and checker, never invent figures.
10. Create shared files: owner-yes queue, daily delta file, open-loops list.
11. Group bots into departments under the front door.
12. Set the daily, weekly, and monthly cadence.
13. Build the weekly scorecard and review.
14. Add the three-layer audit with rubrics.
15. Keep a versioned handbook and confirm rules reach every bot.
16. Watch usage from week one.
17. Keep relationship and legal moments with humans.