I've had nine named agents running for a few weeks now, on Grok Bot, in beta since 11 August. Two shared rooms. Standing watches on mail, the vault, conferences, Raindrop, and the brand work. This is a write-up of how it's split, of the two features that carry the whole thing, and of why adding a tenth unit on top turned out to be trivial.
Worth noting where this product comes from, because the plumbing tells you something. Grok Bot shipped three days before SpaceX closed its acquisition of Cursor, and it shipped on Cursor's infrastructure: iOS listing under Anysphere, desktop downloads and sales links on Cursor's side, Grok branding on the marketing site. It's a Cursor product wearing a SpaceXAI badge, which explains why it feels like something built by people who spend their days watching agents fail against real repositories rather than by people building a chat interface.
What a Bot is in this product
A Bot here is a persistent named teammate with its own memory, files, browser sessions and preferences. You message it the way you'd message a colleague, from desktop or iOS, and closing the laptop doesn't stop the work. Underneath the chat there's a cloud computer: browser, filesystem, terminal. Connectors and MCP where a clean API exists, computer use everywhere else, including sites that have no API at all. Output is supposed to land in the actual tool (the calendar event, the vault note, the Outlook draft) rather than in a markdown blob you then have to move by hand.
The architectural detail that matters, and the one I'd want to know before anyone else set this up, is that all the Bots share a single account-scoped computer. One filesystem, one cookie jar, one set of logins. Each Bot gets its own screen so they can work in parallel without fighting over the display, but that's a concurrency mechanism, not a security boundary. There's no per-role sandbox. If I authenticate the work Bot into Microsoft 365, that session is reachable by the librarian, by the conference watcher, by everything. In practice this is what makes handoffs painless, since the mapper can open a source the librarian saved without anyone re-authenticating. It also means the blast radius of a bad instruction is the whole roster rather than one desk. I've configured around it (nothing with real money or real destructive scope is in the account), but "configured around it" is doing a lot of work in that sentence, and it's the reason I'd hesitate to hand this pattern to a team without talking through the threat model first.
They also talk to each other directly: DMs, group chats, ownership passed between them without me acting as the paste buffer. SpaceXAI's own write-up mentions that people inside the company tend to run a chief of staff on top of their specialists so the human stops being the middleman. I ended up in the same shape, which I'll come back to.
Routines are the part that makes the staff stop needing me. You show a Bot a path once, or just describe the cadence, and it re-runs on a schedule or on an event. Silence is a first-class outcome: if nothing new happened, the Bot is supposed to say nothing.
Where this sits relative to everything else
I've spent the last year in most of the other piles, and they're solving different problems.
Custom GPTs, Claude Projects, a good system prompt in a fresh chat: these are session tools. Strong at a turn, weak across a week. They don't hold a signed-in browser, they don't book the Tuesday slot on my work Outlook tenant, and they don't remember last Wednesday's vault hole unless I paste it back in. Context resets and I stay the router.
Frameworks like CrewAI, AutoGen and LangGraph make me the architect of the swarm. Topology, tools, evals, deploy. That's the correct move when the multi-agent system *is* the product you're shipping, and I've built things that way and would again. It's the wrong move when the job is "watch 23 Teams, ingest Raindrop, don't invent a publish date." I didn't want another repo to babysit in order to have a librarian.
Claude Code and Codex need their own paragraph, because they are the closest thing to this and the gap is the instructive one. I use both. For anything shaped like a repository they are still the best tools I have and I have no plans to stop.
The first thing they do not have is persistence of identity. A Claude Code session is scoped to an invocation and a working directory. Subagents exist and they are genuinely useful, but a subagent is a child of the run that spawned it: created, returns a result, gone. Nothing addresses it by name on Thursday. That is a call stack rather than a roster. Codex is the same shape from the other direction, a cloud task gets a container, does the job, container disappears.
The second thing, and the one that actually matters, is who owns the instruction file. CLAUDE.md and AGENTS.md are specification I write and I maintain. They are config. When the agent works out something about how I operate, that observation dies with the session unless I go and encode it by hand, which bounds the whole system's quality by my willingness to keep writing documentation about my own preferences. A self-updating brief inverts the ownership of that file. I have not opened an instruction file in three weeks and the roster has improved over those three weeks, which was never once true of a CLAUDE.md I was maintaining myself.
The third is that there is no bus. Two Claude Code sessions cannot address each other. They can share a filesystem if I build that, and I have built that, with a queue directory and lock files and all the ceremony that implies, and at the end of it I had written a message broker and gone back to being the architect of a swarm instead of the manager of a staff.
You can assemble most of the individual behaviours. Cron a headless run, wire hooks, keep a state directory, drive a browser over MCP, and I did versions of all of that for about a year. Every one of those pieces is runtime I own, debug and maintain, and none of it is the work I wanted done. The gap is less about capability than about who is holding the runtime.
Workflow builders (Zapier, n8n) want the path specified before the work has been done once. Grok Bot inverts the order: hand off a result, then freeze the path that worked.
The OpenClaw generation of "agent with a computer" experiments already established the interesting half of this: a model that can't click, save and come back tomorrow isn't enough. What's new here is the surrounding structure. Named roles that don't reset, inter-bot messaging, group rooms, routines that survive me logging off.
The desks
I split the work the way I'd split a staff, by job rather than by vendor.
Work is one Bot sitting on Microsoft 365 for both companies. Morning digest, a daytime inbox pulse, live Teams alerts only when someone is actually blocked on me. The rule is the one you'd give a good EA: stay quiet unless I'm the bottleneck. It ignores bots, newsletters and anything marked FYI, which removes most of the volume.
Knowledge is four of them and took the longest to get right. A research librarian watches Raindrop and files sources into the vault. A keeper scans the vault on weekdays and proposes what to aggregate. A mapper rebuilds structure and finds holes once a week. A researcher is on call for deep technical questions. The rules between them matter more than the roles: inbox is a drop zone, raw sources are never silently edited, personal notes stay mine unless I explicitly hand one over. Without those, all four converge on rewriting the same three notes.
Learning is a tutor that turns the library into about four hours a week on the work calendar, in two-hour blocks. On Monday it checks that next week's slots still exist and books the following wave before the current one runs out.
Brand is three: one executing the 18-month plan (write in public, two hours on Friday, no grey-hat), one measuring LinkedIn, X and the newsletter, one watching CFPs and conferences and flagging only what has become newly urgent.
Two rooms sit under all of that, Learning and Vault, where specialists talk without me in the thread.
Stop conditions
A specialist without a stop condition turns into a notification, so the watches all have teeth. The conference Bot speaks only when something is new, changed, or due in roughly three weeks. The vault keeper stays silent on a quiet inbox. The librarian diffs IDs and does nothing when nothing was saved. The mapper says nothing if the map didn't move.
Dates are a policy. Publish date comes from the page; the save timestamp is when I bookmarked it; if the page has no date we write "unknown" and leave it. Nobody gets to infer one so the catalog looks complete.
Time is budgeted the same way. Brand gets its two hours on Friday, elastic only if that phase actually earned it. Learning gets two long blocks rather than a 90-minute fiction wedged into the middle of a day. Work alerts have to cost me less than opening Outlook myself would have.
Self-update and peer messaging
Two features carry this setup, and neither of them is the persistent computer that gets most of the coverage.
The first is that Bots rewrite their own instructions. Not memory in the retrieval sense, the operating brief itself. The vault keeper worked out that "aggregate" means something narrower for daily notes than for source material, wrote that distinction into its own instructions, and has applied it since. The librarian picked up my Raindrop tagging conventions without my having documented them anywhere. I stopped maintaining prompt files around day four. Every multi-agent setup I have built before this had a quality ceiling set by how much specification I was willing to type in advance, and advance specification is exactly the thing that does not scale. Here the brief gets written by whichever unit actually has the observations, which is where that knowledge belongs.
The second is that they message each other. Direct messages, group rooms, ownership handed across without me in the middle. The Vault room has four specialists working out between themselves who takes what: librarian saves a source, keeper picks it up, mapper is told the structure moved. For the previous year of running these things I was the message bus, and I was the slow component in every one of them. This takes me off the path without taking me out of the system.
Why the tenth unit was cheap
Those two properties are the reason adding a chief of staff took an afternoon.
In a framework I would have had to build a supervisor node: define it, wire the topology, specify what it reads and how it summarises, then maintain that specification as the nine underneath it changed. Here it is another teammate with a different vantage point. It joins rooms that already exist, receives on a bus that already exists, and learns what the roster does by watching it rather than by my describing it. I told it what to look for once. It has been refining its own brief ever since, the same way the specialists do.
That is the part I would generalise. Self-update and the peer bus are what make the org chart composable. Putting a management layer over nine specialists is normally an architecture change; on this stack it was a hire.
What that layer holds is the cross-roster view. Each Bot's knowledge lives in its own brief and each handoff happens in its own room, so the system's state is distributed by design, and somebody has to read across it. Did three of you just surface the same source. Is the tutor booking hours or only proposing them. Is the mapper idle while the keeper scans. Those questions have no home inside any single desk, and no topology change answers them either. They need a reader.
The notification pattern is what made me look. Five specialists could legally ping me before 9:00 on a Monday, each one correct in isolation, each with a valid trigger and a stop condition that had evaluated and passed properly. Nine correct local decisions do not add up to a good Monday. That is a management question, and it has the same shape at nine agents as it does at nine people.
[QUI: il momento concreto in cui ho visto il chief of staff fare qualcosa che nessuno dei nove poteva fare. Che cosa ha intercettato, quali bot erano coinvolti, che cosa sarebbe arrivato a me senza di lui]
SpaceXAI's own team runs this pattern internally, so I am not claiming it as a discovery. What I did not expect was how little it cost to adopt.
The open question is whether one such layer holds. At nine specialists it reads everything comfortably. I do not know what happens at twenty, or whether the answer is a second layer or a wider one. It has been about three weeks. Ask me in a quarter.
The current shape
Chief of Staff
→ Work: CTO staff (mail, calendar, Teams)
→ Knowledge: librarian, keeper, mapper, researcher
→ Learning: tutor
→ Brand: brand exec, social pulse, conferences
The boxes will keep moving. The part I'd bet on holding is the one I keep saying about production agents: the prompt is rarely where the difficulty lives. It's in the boundaries: who may speak, who has to stay quiet, and who looks across the desks when all nine specialists are individually certain they're right. On this particular stack there's a fourth one, which is who gets to share a login, and I don't have a good answer to that yet.