Personal AI agents are a game changer. Getting them to talk to each other? That's the tricky part.
Here's how I run ops with Grok Bot at a YC startup, and get the whole team's agents working together.
My full playbook, so you can try it. Hope it helps ! https://x.com/i/article/2117513105802473472
How a YC-backed startup runs its ops on Grok Bot
Personal AI agents are a game changer but getting them to talk to each other was the hard part
so here's how I run ops with Grok Bot at Standout, and get the whole team's agents working together
My full playbook, so you can try it too, Hope that helps !
At some point our Slack had more bots than people. Thanks @elonmusk. The weird part isn't that the agents work, it's that they now teach each other. Below is exactly how we set it up, with templates you can copy for your own team this week.
But first, how most teams get it wrong. One bot, one giant prompt, a lot of hope. "Find me great candidates." It works beautifully once. Then it redoes finished work, trusts last week's status, and drafts messages nobody asked for.
The AI isn't the problem. The setup around it is.
And teams that fix that hit a second wall: each person's agents learn alone. Connecting your own agents is easy now. Getting the whole team's agents to learn from each other is not.
I'm Founding Ops at @standoutwork, a YC-backed startup in recruiting. Every role we work on runs through the same repeatable process, and that process now runs on Grok Bot. Each AI agent there gets its own always-on computer, memory, saved skills and app connections. And agents can message each other.
Recruiting is just where I built it. Swap the nouns and the same setup runs sales, support or finance: anything with a main database, repeatable steps and a human who signs off.
Here's the whole thing, minus our prompts and scoring. A magician has to keep something.
01. One brain bot, many small helpers
Don't build one giant bot. Build a small team of them.
Every avatar is a separate Grok Bot. Each person chats with their own brain bot, and it hands the work to worker bots that use the tools. Gray arrows are work moving forward.
The blue dashes are the learning loop. Workers report back to their brain bot. Every week, each brain bot sends what it learned to the shared team bot. Humans approve the good lessons, and the updated playbook goes back to every brain bot.
Think of the brain bot as a manager. It decides what should happen and checks that it did. The workers are specialists that do everything in between, each with its own computer, its own notes and its own off switch.
When do you need a new worker? When the job needs different information, different tools or different permissions. "It would be cool" doesn't count.
Want to see this at scale? Read Anthropic's How we built our multi-agent research system: a lead agent plans, hands pieces to helper agents in parallel, then checks their work. Then watch Barry Zhang's 15-minute How We Build Effective Agents before you add a second bot. His first rule: don't build agents for everything.
Name every bot after the job it owns, "campaign/[role]" or "support/billing", never after a skill like "researcher". If you can't name the job, you don't need the bot. Fifty bots is fifty things to babysit.
02. Give every bot a job description, not a giant prompt
A bot without a finish line wanders off. Slowly, politely, and with great confidence.
So skip the giant prompt. Write a short contract instead: what the bot must deliver, from what, how often, and what it must never do. Every worker gets one as its first message. Copy this, fill the brackets:
The hardest line is done_when. Ban adjectives: "good leads" becomes a bar you can check, "fast" becomes a deadline. If a human can't check it in ten seconds, the bot can't aim for it.
Then sort what the bot needs to know by how fast it changes. Slow facts (who the customer is, how we work) live in skills and shared files. Fast facts (statuses, replies, dates) get re-read from the source every run. Treat the bot's memory like a sticky note, not a database, and a whole category of "it used old info" bugs disappears.
People call this context engineering: choosing exactly what the agent sees. The best long read is Anthropic's Effective context engineering for AI agents. For the slow-facts half, watch Don't Build Agents, Build Skills Instead, the clearest case I've seen for saving know-how as skills an agent opens only when it needs them.
03. Keep the deciding apart from the doing
The bot that decides shouldn't be the bot that clicks.
Deciding lives with the brain bot: its rules, skills, schedules and approval steps. Doing lives with the workers that touch real systems. They use app connections where they exist (MCP, a standard way to plug a tool into an agent), the browser on the bot's own computer where they don't, and helper agents for anything heavy.
Before you script a browser flow, check the MCP servers repo. Someone may already have built the connection you need.
Our recruiting admin tool is internal with no connector, so workers use it through the browser, like a very patient intern who never takes lunch.
04. Boring on purpose: make every routine safe to run twice
Anything on a schedule must be safe to run twice. No exceptions.
Every run follows the same five steps: read the current state, skip what's already done, do the work, stop at the approval gate, post a receipt. Skipping duplicates comes first, so if a routine fires twice you get the same result, not two emails. The receipt is how you see what happened without digging:
How often a routine runs is a cost decision, not a vibe. A routine that runs more often than there's new work just burns usage.
What I'd do: write routines as exact instructions, not wishes. "Every weekday at [time], flexible by 15 minutes: read [source], skip anything already [state], do [work], never send, post the 7-line receipt to [thread]." Start daily. Go hourly only when the receipts show hourly runs actually find new work.
If you read one thing on reliable agents, make it 12-Factor Agents. Factor 12, "make your agent a stateless reducer", roughly means same input, same result, no hidden state. That's this chapter in one line. Dex Horthy's talk version is worth the watch too.
05. Green, yellow, red: the approval rules
Approving every click doesn't scale. Approving nothing is how you email the wrong person.
So every action gets a color, based on how much damage it could do. Green runs freely. Yellow is internal and logged. Red needs a human yes every time, and one yes covers one exact action. For us, red is anything a candidate or client would see, anything paid, anything you can't undo.
Then give each bot only the access it needs. All your bots share one cloud computer, including files, browser logins and saved credentials. Log a tool in on one bot and every bot can use it. So: limited credentials, read-only where you can, and agents that prepare the change but don't push it. Our version: "write the draft, don't send."
The more freedom an agent has, the less it can police itself, so the safety rules have to live outside it. Grok Bot's Auto-review is a second safety net. The first is a written list of red actions in every bot's instructions. Mine is in Steal this.
Before any agent gets private data, untrusted input and a way to send things out all at once, read Simon Willison's The lethal trifecta for AI agents. It's the shortest explanation of why red needs a human.
Agents can cook. It's still our name on every plate.
06. Handoffs are where agents lose the plot
When one bot passes work to another, make it fill in the same short form every time.
Setups with many agents break in the gaps: work changes hands and the details get lost. So every handoff, bot to bot or bot to human, uses this message:
The evidence field does the heavy lifting. Some coding teams have a few agents try to break a fix before a human is even pinged. The general version: a second check against the contract before anything counts as done.
Make the receiving bot refuse any handoff with an empty result or evidence field. Whoever receives the work checks it.
Building in code instead? The OpenAI Agents SDK handoffs docs treat handoffs as a built-in feature, structured input included.
07. Get your whole team's agents learning from each other
Connecting your own agents is solved. One person, one account, shared files, shared memory, a brain bot handing work to workers.
The team is not.
Every teammate runs their own agents, and each one learns alone. One scout cracks a hard role, and what worked stays in their private chat. Ten people, ten separate playbooks, nothing shared. The real job is getting everyone's agents to share what works, every week, so a good idea spreads to the whole team.
Here's how we wire it.
Grok Bot lets bots message each other, a bit like texting: the sender doesn't wait, and the reply arrives later as its own message. A "priority" message wakes the other bot right away. An "informational" one waits until it's next active. If your agents live with different vendors, look at A2A, an open standard that lets agents from different systems talk.
One rule shapes everything: a bot can only message bots in its own owner's account.
That's why every teammate needs a brain bot. It's the bridge: it talks to its owner's workers on one side and to the shared team bot on the other. Workers report to their brain, and brains meet at the team bot. The team bot holds the shared playbook, the team's collective memory, and each of us also chats with it directly.
Clear roles keep it sane. Workers answer only their brain bot and never edit shared docs. One writer per shared doc, one owner per conversation.
Every question between bots uses the same small message:
Then the weekly cycle runs in four steps:
- Ask: at the end of the week, each brain bot asks its workers for their top 3 learnings, with proof and a deadline.
- Collect: a few hours later, a second routine gathers the answers plus the brain's own, removes duplicates, saves each one to a shared database as Proposed, and pings the team bot.
- Decide: over the weekend, the ops leads approve or reject each one.
- Share: on Monday morning, the team bot turns only the approved ones into the shared playbook, and every teammate's agents pick it up as rules and skills.
One scout's win becomes everyone's default by Monday.
We could let bots pass tips around directly, peer to peer. We don't, on purpose. Everything goes to one place, humans decide what's true, then everyone gets it at once.
Asking and collecting are two separate routines, so one slow worker never holds up the run. The deadline does.
Safety rules sit at every step. Nothing becomes a rule until a human approves it. Nothing reaches an outside person without that human's explicit go.
A brain bot can't reorganize the workspace or delete bots. It can create new bots in its own owner's account; we've tested that. In someone else's account, we haven't, so I won't pretend.
And make it visible, because bots messaging each other in the dark are impossible to debug. Every bot posts its status (working, idle, waiting, error) and its routine list to its owner's status feed, with no names or personal data.
The exact worker and brain-bot lines are in Steal this, at the end. And use priority sparingly. Nobody likes the coworker who marks everything urgent.
08. Every yes and no makes the system smarter
Every human decision is data. Treat it that way.
Each approval, rejection or edit tells the system what good looks like. Rules, skills and memory are what the bots actually follow. Once a week, a review routine reads the receipts and corrections. It spots where bots stray from their job descriptions and proposes new rules for a human to approve. Chapter 07 is the same cycle for the whole team.
No retraining, no data science. The AI itself doesn't change. The written rules do, and they're plain text you can read, compare and undo. That's exactly why I trust it with real work.
A clear "no, because..." teaches more than a bare "yes". It tells the system what to change.
Not every fix belongs in a written rule, though. Push each fix as high up this list as it goes:
- The system itself: make the easy thing the right thing
- Hard checks in code: skip duplicates and check data before anything is saved
- Written rules: instruction files and skills
- Human review: the layer that doesn't scale
Agents copy what exists and take the shortest path, so the setup has to make the right path the easy one. If you're tidying up after the agent on the same issue every week, the fix is in the wrong layer. The goal isn't to remove review. It's to move most of the reading to machines.
If evals (tests for AI output) still feel abstract, read Hamel Husain's Your AI Product Needs Evals, then hear him and Shreya Shankar on Lenny's Podcast. Their core move, read what the AI actually did and write down what failed before you pick a metric, is exactly what a weekly review routine should do.
Cap that routine at a few proposals a week, or a proactive bot will happily fill your backlog with busywork.
09. Never automate the first run that works
One good run proves nothing. It's a demo.
Trust is earned task by task, not handed to a bot all at once. Climb one step at a time: answer in a thread, prepare drafts, update internal records, prove it, then put it on a schedule. Anything external stays red until everything below it is trusted.
When a routine feels ready, ask the bot to "run it now, by hand, and show me the receipt" three times before you say "schedule it". Then keep reading receipts for the first week. It's boring. That's the point.
OpenAI's A practical guide to building agents lands in the same place: get one agent right first, add safety checks in layers, and plan for a human on high-risk actions.
The point. Agents don't replace the human in the loop. They move the human to where judgment matters, and every decision that human makes trains the next run, for the whole team. That's the whole bet: less time on busywork, more time talking to people.
So start small this week. One worker, one contract, one receipt you actually read. If you're building agents that learn as a team, my DMs are open. Tell me what broke. And if this is the kind of team you'd like to work on, we're building it at @standoutwork, and we're hiring talent scouts.
Steal this
Copy, paste, fill the brackets. The job contract from chapter 02 goes first in any new worker. These four cover the rest.
A starter prompt for a brain bot that hands work to workers:
The weekly message each brain bot sends the team bot:
Approval rules, the same for every bot:
And the two lines every worker gets:
Sources
- Grok Bot + Claude Code, Why is Everyone Switching to This? (YouTube · Rob Shocks, Oct 31, 2026)
- How to build a Second Brain that actually does the work (X · @Argona0x)
- Grok Bot Agents: Build 24/7 AI Agent Graph (X · @0xCodila)
- Grok Bot Agents: How to Build an AI Team You Can Actually Trust (X · @0xjmori)