GrokBot is amazing. Here's why I stopped using it.
Last week, using GrokBot to orchestrate various agents running in T3 Code, I merged 78 pull requests. My best before that was 35.
Then, over the weekend, while I slept, my 16 shiny new bots burned $100. Most of it just went to bots waking up, thinking it over, and deciding they had nothing to tell me.
By Monday, when it was time to work again, my setup was dead. I'd hit the spend limit, so every bot, every routine, and every webhook was failing to fire.
Naturally, I raised the spend limit. Naturally, the bots ate it before I could even export all my data and get off the platform.
I'm more and more convinced that a staff of always-on agents is the right way to work. It's a really good idea, for reasons I'll talk about below. And GrokBot is the closest thing we have to a working implementation. But it's just not there yet, and the reasons are architectural.
Why I wanted a staff in the first place
Coding agents can already do a lot of the work. What wears me out is everything around it: knowing which PRs are waiting on review, what came in overnight, and what to work on next. I wanted to engineer that mental load off me and into the system.
GrokBot is built for exactly that. Each bot is an agent with its own chat and its own little Linux computer in the cloud, and with the desktop app installed, it can run commands on your machines too. Bots run routines on a schedule or when a webhook fires, and they can even reconfigure each other.
So I hired 16 of them, one per area of my work: Inbox, GitHub, Bugs, Blog, Research and so on. A Config bot's whole job was setting up the others, and a Vault bot was the only one allowed to write to my notes.
When a project needed a few bots at once, I'd pull them into a group chat: "Okay, in this room we're only working on this project."
Then I connected them to my coding. I write code in T3 Code, a desktop app that runs Claude Code and Codex threads side by side, because that's where my Anthropic and Codex subscriptions and the models I like live.
I didn't want to open T3 to the cloud through a public tunnel, where anyone with the URL, or a bot with a prompt injection in its context, could run commands on my PC. So a small script on my PC, no AI involved, pinged a GrokBot webhook whenever a coding thread finished, failed, or needed me. That woke my T3 Code bot, which could tell me about it or act back on my PC through the desktop app.
What it looked like when it worked
Two routines carried most of the week. A GitHub bot watched my PRs, and when a review came back approved, it told the coding thread that owned the PR to land it. It never merged anything itself, and one PR landed two minutes after its approval.
And three times every weekday, my inbox, calendar and journal bots wrote up what they'd found, and Vault turned their reports into a ranked priorities board.
I stopped hunting for the next thing to do and just did it. That's where the 78 PRs came from: the bots and my coding threads, working together.
GrokBot deserves a lot of the credit:
- It lives in the cloud and still uses your computers. I could change which computers the bots were on without rebuilding anything, which is absurdly helpful.
- Sign-ins don't hand over the password. When a bot needs a login or an API key, it gives you a field to paste it into, and the bot never sees the value.
- It's fast. Fast enough that I'd stay in the chat to answer a clarifying question instead of wandering off, which mattered more than I expected.
- It's the best X crawler I've used. Unfortunately, for DevRel, that matters a lot.
For a few days, it felt like running a small company. Then it felt like being that company's only project manager.
"Okay, I'll get back to you with that"
The more work I handed to the bots, the more of it fell through the cracks, and most of the cracks started with the same sentence: "Okay, I'll get back to you with that." Then the bot never would, because nothing was going to wake it up. Its next turn was whenever I happened to message it again.
Here's one ordinary day. On Friday, October 9, 24 of my coding threads finished. The bots told me about 17 of them on time and 3 late. I never heard about the other 4. That same day, a coding job failed twice without anyone telling me.
The next afternoon, I asked the bot coordinating my coding threads to hold all merges while we sorted out a failing check. The hold never reached the threads, and 46 minutes later, a PR merged right past that check. No harm done, that time.
Group chats helped, but about 15% of the time, a bot answered in its own one-on-one channel instead of the room. With 16 bots talking, I couldn't check every channel, and a bot that had told me something once wouldn't say it again.
The $100 weekend was the same kind of crack. My notifier fired at every stage of every coding thread, and every event woke a bot.
So that Friday, the bots and I designed a filter: a small piece of plain code that would decide which events were worth waking anyone for, cutting about 80% of the traffic. A bot took it on and built it, but nobody ever switched it on, so coding events kept waking a bot 500 to 750 times a day.
We fixed it the morning I noticed, but there's no undo on usage. (And this was already the $200 plan. I'd upgraded twice, because $20 of usage was a joke, and then so was $60.)
The cloud computer was moody, too. It sleeps when it's idle, so scheduled jobs ran 12 to 80 minutes late, and unpredictable restarts logged me out.
So the system that was supposed to carry my mental load handed it right back. I was scaling up the work and losing more of it between the cracks.
Why: GrokBot's own team explains it
Lee Robinson, who works on GrokBot at SpaceX, gave a Stanford lecture on how it's built, and it's a great, candid talk. Almost every complaint I had is on his slide of open problems.
Every wake is a model turn. Everything that can wake a bot (you, a routine, a webhook, another bot, background work finishing) goes through one router into that conversation's queue, one turn at a time. Then the model asks, in the slide's words, "Anything worth saying?" If not, "Quiet is allowed." Only one tool, SendToUser, ever reaches you.
That's a smart way to keep bots from being noisy. But it means silence costs a full model turn.
Even after we fixed the filter, a "task done" event would wake my T3 Code bot, and it would often decide the news wasn't worth mentioning. I was paying for inference that was basically deciding, "Hmm, I guess we shouldn't talk."
It also makes following up a judgment call. GrokBot can subscribe a bot to the work it's waiting on, but the model decides whether to, and mine decided inconsistently.
Memory gets rewritten where you can't see it. After every turn, a background pass updates a profile of "up to 100 facts in 4,000 characters," plus short-term notes "that fade quickly." I never knew what a bot remembered unless I went and read its memory file.
Every bot sees every skill. The model is trained to pick the right skill "when there's hundreds of skills." That's impressive, but it meant my calendar bot could see every skill my GitHub bot used.
Each bot is one conversation with one queue. Helpers do the heavy lifting in the background, but the bot you talk to holds every job you've given it. My busy bots became bottlenecks and lost track of what was going on.
Lee is upfront about the rest. On coordination: "Many agents sharing one computer and one memory run into classic distributed-systems problems." On when to speak: "Too many messages is noise. Too few and you can't tell what it's doing." On cost: "Always-on only works if idle agents are nearly free and active ones are cheap." That's my week, in three slides.
His team's answer is a principle he brought from Cursor to SpaceX: "delete the product." Assume "the models today are the worst they'll ever be," and be ready to rebuild as they improve. I agree that models will get smarter. I just don't think smarter models should be responsible for plumbing.
What it'll take, part 1: the plumbing
What I want is abstraction without losing determinism. Make sure models all have very small jobs, and hand everything around them to plain code:
- Follow-ups are records, not promises. When a bot hands off work, the system writes it down, subscribes the bot, and wakes it when the job finishes or fails. Relying on AI to "remember" to message you is a death trap.
- Every wait has an else. Each follow-up gets a deadline. If a helper crashes, that's news too, and the bot waiting on it hears about it. "I'll get back to you" can't end in silence.
- Events over clocks. I'm more and more convinced that a cron job is usually the wrong answer. It's wasteful, and it still misses things: my 20 nightly per-bot jobs were my second-biggest drain all week. Bots should respond to real events, and plain code, not a model turn, should decide which events are worth waking anyone for. My rule became "webhook for everything, no tokens spent."
- Small models for small decisions. Some calls do need judgment: is this worth waking a bot for, who should hear about it, does this message start a new project? That's not a job for a frontier model. A decision model like TypeSafe's Jev answers narrow, typed questions like these. When I tested it, a typical answer took under 200 milliseconds, and 65 of them cost less than a tenth of a cent. The classifier advises, and code decides: code enforces who's allowed to do what, and until a classifier proves itself on my own examples, its answers are just hints.
- Quiet by default. Background workers never post. (I have a coding bot, and I hate watching it work.) When a bot does talk to me, it's a short, deliberate act with a length limit, because my bots were wordy.
- A fresh instance per job. Give each job a crystal clear description, just the tools it needs and just the skills it needs, and call it a day. Then no busy bot becomes a bottleneck.
I'm building an open-source alternative to see how far these ideas go. But honestly, I'd rather see them land in the tools everyone already uses.
What it'll take, part 2: where the work lives
Plumbing keeps promises from getting lost, but it doesn't show you what's going on. By the end of the week, I had to search 16 chat channels and memory files I couldn't see just to find out.
Chat logs and hidden memory make a terrible database. A staff needs filing cabinets, not just a group chat.
I did set up one filing cabinet on purpose. Vault kept my priorities board in a documents app, not a chat, so I could open it any time and the bots could read it back.
That paid off when it broke. The app's MCP server started cutting database reads off at 2,000 characters, so the board stopped refreshing, and I could see that it had. When a bot forgot a promise in chat, nothing changed, so nothing told me.
That app was Agent-Native Content, and Agent-Native is what my team builds at Builder. I'm biased, but that's also why I put my board there.
Agent-Native is our open-source framework for agentic apps. Mail, Content, Slides and Design each come with their own agent, built for one job, and an MCP server. You work in the app, and its agent, or any outside agent over MCP, works on the same state.
A general bot can hand the job to the app built for it, and you can open the app and see what happened. And because it's open source, when my board broke, I fixed that cutoff upstream myself.
GrokBot is amazing. It gave me a real week of what an always-on staff can do, and I want the version that lasts.
Agent-Native is one option among many. Whatever you build on, the split is the same: let models do the reasoning, the writing, and the coding, and leave the routing, the queues, the follow-ups, and the state to plain code. I paid $100 to learn that, so you don't have to.
