I Run a Team of Grok Bots. Here's What I'd Delete from Your Agent Product

Every button, router and rule you built to babysit your model is a bet against the next model.

You'll lose that bet in three to six months.

I learned it running a team of Grok Bots. I told my main bot I wanted a few new teammates. It recruited four, set up a group chat and onboarded them. I never wrote a hiring workflow. I just asked.

Then I watched Lee Robinson's Stanford CS146S lecture on how Grok Bot works. Lee ran DX at Vercel, built agents at Cursor, and now works on Grok Bot at SpaceX.

Near the end, he spent less than a minute on the one idea that explains the whole architecture:

Delete the product.

Here's what I'd delete from yours, and what I'd never touch.

Your agent isn't a tool anymore. It's a coworker.

For years, using an agent meant: send a message, wait, send the next one.

Now my personal agent, Jojo, runs on a Mac mini at home. I text it from Telegram whenever I want. My bot team runs on Grok Bot.

I can cut in mid-task. "Go check this post." Then: "Actually, Thursday is fine." It knows those are the same request.

What changed:

• It's always on. Laptop closed, restart, crash. It keeps going.

• It has its own computer. Desktop, files, browser, in the cloud.

• You're not the only one who wakes it. Slack mentions, emails, scheduled jobs.

• It works for days, weeks, months. Not one session.

• It has a job, not a ticket. An agent is scoped to an issue. A bot has a standing role and long-term memory.

Why are these shaped like chat bots? Lee's answer: everyone knows how to text.

In Lee's words: "It knows when to be quiet."

One task? Use Claude Code. Ten? You need a manager.

"Why not just do all this in Codex or Claude Code?"

If you have one task at a time, you should. Your attention is on one thing. Watch it to the end.

At five or ten parallel tasks, across worktrees or projects, you become the bottleneck. Every switch means reloading where it was, what the context is, what to say next.

"Claude Code has subagents." Subagents offload heavy work inside one task. Ten tasks need something else: a bot with a standing role that remembers where every thread is.

That's what Jojo does for me. I hand it a task. It opens an isolated workspace in herdr, spins up Claude Code or Codex, tracks progress and checks the result. By default I hear exactly two things: "done," and decisions that need me. (I packaged it as a skill: herdr-workflow in joyehuang/skills.)

Lee describes the same shape: the main agent stays sparse. It manages the to-do list and messages helpers. Subagents do the expensive work with fresh context and bring back only the result.

One caveat: this only works if the model is genuinely good at multi-agent work. In my experience, that jumped in the second half of this year. Before that, agent teams cost more than they gave back.

Subagents split a task. A bot holds a job.

Grok Bot is mostly what they didn't build

The core is still the minimal agent: a model calling tools in a loop. The craft is in the ring around it.

A router in front dedupes, merges bursts of messages, sets priority, and decides whether to bother you. Your direct message beats everything. The moment you speak, it drops what it's doing.

The agent's computer is a cloud VM that boots on demand, snapshots, and sleeps. The loop lives on the server, not the VM, so every VM can be rebuilt and patched without the agent stopping.

Client and server share exactly one tool: SendToUser. Phone, desktop, email, Slack all just text the server. The client decides how to render: a login form, a draft to approve before anything irreversible, or just an emoji.

The model only sees tool names until it picks one. And every task climbs a ladder: known context, then connectors and APIs, then web search, then the browser, then the full desktop. Asking you is the last rung.

Lee's bar for cost: a cache miss is basically a bug. For an always-on agent, cache hit rate decides whether you can afford to keep it alive.

No model picker. No streaming. In Lee's words, Grok Bot works "primarily because of everything we didn't have to build."

"The best UI is none at all."

UI complexity is a confession

Watch how AI coding tools evolved.

First: Tab-complete, one line.

Then: select a few lines, get a tiny edit box.

Then: a sidebar with Ask, Plan and Agent modes you had to pick first. For a while last year, Cursor was shipping UI tweaks about twice a week.

Now: Codex opens to a text box. The modes are mostly gone. There's a permissions toggle, and most people run it on max.

Every one of those layers existed because the model wasn't good enough. One line, because more went wrong. Selected lines only, because free rein wrecked things. Modes, because the model couldn't tell whether to ask, plan or act.

We're back at a text box. Not because models can only chat. Because they're strong enough that extra UI just gets in the way. And the box can still render forms, cards and charts when the model needs them.

UI complexity usually means you're compensating for a model that isn't smart enough.

Today's model is the worst you'll ever build on

Lee's rule, which he says they followed at Cursor and follow at SpaceX: accept that "the models today are the worst they'll ever be."

Build for the next model. Build as little as possible.

The hard part is believing it. Earlier this year, multi-agent setups were forgetful and bad. A few months later they weren't. Everyone shrugged like that was normal. We've gone numb to it.

If you actually believe it, then the harness you wrote to patch today's model weaknesses has a shelf life of three to six months. That's not you doing a bad job. That's how this field works. Whatever you patch today, the model eventually learns.

Scaffolding that's meant to come down is not a moat.

Deleting the product starts with deleting your own habits.

Two layers: delete one, thicken the other

"Delete the product" doesn't mean "build nothing." I split every agent product into two layers.

The compensation layer: everything you built because the model wasn't good enough. Intent routers. Long rule lists. Hand-written retrieval. Mode pickers. One-off tools for one kind of task.

The load-bearing layer: what you need no matter how strong the model gets. Data. Evals. Permissions. Integrations. Distribution. Cost.

Think intern vs. senior engineer. The intern needs step one, step two, step three. The senior needs the goal. The compensation layer is the intern's checklist, and models look more like seniors every release.

Give the intern a checklist. Give the senior a goal.

Why your scaffolding is actively hurting you

If it just went idle, fine. It doesn't. It drags a stronger model down.

It hard-codes an expired assumption. Vercel's data agent d0 had 17 specialized tools. They cut it to two: bash in a sandbox and SQL. "We were doing the model's thinking for it."

• Success: 80% → 100%

• Time: 274.8s → 77.4s

• Tokens: ~102k → ~61k

• Steps: ~12 → ~7

Caveats: five queries, so a strong signal, not a study. And their semantic layer was already great documentation. With messy data, you just get wrong queries faster.

Extra constraints hurt strong models. Anthropic's Thariq explained cutting more than 80% of Claude Code's system prompt: conflicting instructions, examples that box the model in, worst-case rules that are wrong for other tasks. Dan Shipper hit the same thing on Opus 5's launch day. Old skills fought the new model. They deleted all of them, and Opus 5 got noticeably better.

Every model update means recalibrating. Vercel spent more time maintaining scaffolding than improving the agent.

The UI keeps users stuck. Thorsten Ball at Amp: "If a feature teaches you to start using agents the old way, we need to remove it."

None of this is new. It's Sutton's Bitter Lesson applied to products. As Hyung Won Chung put it at Stanford CS25: people are good at adding structure and bad at removing it.

The cleanest test I know comes from Peak Ji at Manus: swap a weaker model for a stronger one in the same family. If your product barely improves, your compensation layer is holding it back.

Does your product get better for free when the model does?

What I'd never delete

This is where "delete the product" gets misused.

Evals. They're the only thing that tells you a piece can go. Claude Code could cut 80% of its system prompt because the evals showed no measurable loss. Without evals, deleting is gambling.

Reliability. Can do isn't always does. Cognition tried letting Sonnet 4.5 write its own notes instead of their memory system. It got worse, because the model doesn't know what it doesn't know.

Permissions. Approve the draft before it sends. Review every command. Never treat an inbox as instructions. That's a line of responsibility, not a patch.

Cost and cache. Manus calls KV-cache hit rate the single most important production metric. Cached vs. uncached can be roughly 10x.

Fast human review. Lee says that after deleting nearly everything at Cursor, about 2% of the editor couldn't go. That's the part where humans check and adjust.

Readable data. Vercel's cut only worked because the effort moved into docs, naming and structure.

Fair pushback: Anthropic can build for the model six months out because they can see the roadmap. Most of us can't, and users need things done today. So ship the patch. Just don't get attached.

And discount what only big teams can afford. Every turn as a durable workflow, waking a whole VM on demand, layered memory: great at scale, a maintenance trap for a solo builder.

Don't skip the patch. Just don't fall in love with it.

What I actually do

My community bot answers questions in a group of about 800 people. There's almost no training data for how a bot should behave in a group chat. Knowing when to be quiet is the whole job.

So:

• Every entry point (mentions, replies, DMs, scheduled jobs) becomes the same kind of message. No keyword menus.

• The model decides whether to speak. Code enforces the caps: messages per minute, per-person cooldowns, quiet hours.

• A short persona. In-jokes live in files it looks up, not in the prompt.

• Every group message is untrusted input. Admin actions need an allowlist and a second confirmation.

And five rules for any agent product:

1. Start with the strongest model, the shortest prompt, the fewest tools. Add only from real failures.

2. Give every compensation piece an expiry: which weakness it covers, which eval proves it's no longer needed.

3. When a new model ships, run it bare. Delete every rule and skill the bare run doesn't miss.

4. Few, basic tools: message, search, files, shell. Specialize only when one call pattern dominates.

5. Spend your effort on the load-bearing layer.

Spend your effort where the next model can't wash it away.

Before you build one

Lee's advice to engineers is to build one yourself. I'd go simpler first: spend a few days with a personal agent and hand it something you'd normally babysit. Then reread this.

Look at the substance, not the hype.

What's one thing you deleted from your agent product that made it better? Tell me in the replies.

Next up: Winter of Agents (WoA), my next build event. Details soon.

Follow along. I write about what actually runs in my agents, and what I cut.

Long version with figures (in Chinese): https://joyehuang.me/blog/20261011---alwaysonagents/post

Long version with figures (in Chinese): https://joyehuang.me/blog/20261011---alwaysonagents/post