Grokbot Crashes Halfway Through—Don’t Swap the Model Yet

Lauren Tan publicly shared the chief-of-staff prompt she uses when running the Grokbot system. The structure isn’t complicated: write the goal clearly, provide enough context, constraints, and resources, assign roles, add checks, validation, and review, and finally enforce a clean output and handoff format.

What’s really interesting is that Ricker pushed this one level further. He proposed that Grokbot should not answer questions directly; instead, it should first determine what shape the work should be split into, then hand it to Kimi K3 to run. Up to 300 K3 agents in parallel, across 4,000 steps. The router is one prompt; the runtime is three hundred agents.

Why does a single agent hit a wall? An agent has only one context. When a task gets big, it has to hold instructions, sources it has read, half-formed ideas, and drafts all at once. The further it goes, the fuller the context gets, and quality drops in the part completed last. Ricker’s point is that the model itself isn’t the problem; the problem is the shape: one agent, one context, one pass. Multi-agent changes the shape. One agent does only one thing, shares what it learns, and checks the others.

Grokbot acts as a router first and never does the work itself. For every request it answers only one question: what shape is this work? There are four:

• FAN-OUT: many independent items, such as scanning 80 companies.
• CHAIN: each step needs the previous step’s output, such as research to drafting to editing.
• DEBATE: judgment-type questions with no single answer, such as whether to launch.
• SUPERVISOR: long, messy, and possibly failing midway, such as building and testing a tool.

When unsure, choose the simpler one.

You are a router. Never do the work yourself.
For every request, pick ONE pattern and hand off to Kimi:

FAN-OUT     many independent items  (scan 80 companies)
CHAIN       each step needs the last (research -> draft -> edit)
DEBATE      judgment, no single answer (should we launch?)
SUPERVISOR  long, messy, may fail    (build + test a tool)

Output: pattern, one-line reason, the brief for Kimi.
If unsure between two patterns, pick the simpler one.

Fan-out is one brief, multiple identical agents, and a merge at the end. 80 companies, 200 documents, or 300 targets can finish in the time it used to take to do one. 300-way parallelism is most useful here. Chain lines agents up in sequence: research hands off to analysis, analysis to drafting, drafting to editing. Each agent sees only the part it needs. Use this when quality depends on order. Debate puts two agents on opposite sides and a third as judge. A single agent tends to agree with its own first idea; a dedicated opposing side fills that gap. It fits launch-or-wait, buy-or-build, or choosing among three options. The judge must explain why. Supervisor has an overseeing agent assign work, check each result, and send failures back with reasons. It fits long tasks. Ricker’s claim is that K3 is strong at keeping a plan across thousands of steps, workers write backend code at Fable 5 level, and fewer tasks fail.

If agents can’t see one another, they will duplicate work, contradict one another, and miss things. The fix is shared memory: every agent reads before it starts and writes after it finishes. A Kimi run has a 1M-token context that can hold the brief, findings, and decisions. The structure has three parts: facts, the facts checked and their sources; decisions, the choices and reasons; open questions, what is still unknown. Each agent writes to one of these parts in its final step, and reads all three in its first step.

Systems often break at handoffs. One returns a paragraph, the next expects a list, and the merge silently drops half. The fix is boring but effective: every agent returns the same shape every time.

{
  "agent": "fanout-17",
  "task": "pricing for company 17",
  "status": "done",
  "result": {},
  "sources": ["url"],
  "confidence": 0.9,
  "memory": {"facts": [], "open": []}
}

status lets the supervisor see failures without reading every result; confidence lets the merge weight by confidence instead of treating guesses and verified facts as equal. Write it once, paste it into every template.

When 300 agents are running, some will fail. Pages won’t open, sources conflict, tasks are partially completed. A single-agent failure ruins the whole answer; with multiple agents, only the broken part is retried. Retries should include a reason, such as “the page has no price; try the docs site.” Blind retries will fail the same way. If it fails twice, put it into open questions, mark it in the final output, and don’t silently guess.

Multi-agent uses more tokens because many agents read and write. Ricker says Kimi K3 is about 5x cheaper at the same coding level and has high token efficiency, so this system can run every day without saving it for special occasions. For readers with a development background, cost determines frequency.

Someone joked in the replies that 300 agents sounds like his Tuesday shift: too many moving parts, and someone is always passing the blame. The metaphor is pretty accurate. Without routing, memory, and handoff formats, 300 agents are just 300 blame-passing points.

You can set it up in six steps:

1. Install router grokbot. Paste the router prompt into Grokbot; from then on it classifies requests and does not answer directly.
2. Save four templates kimi k3. In Kimi Agent Swarm, create one template each for fan-out, chain, debate, and supervisor.
3. Add shared memory. Each template reads memory at the start and writes facts, decisions, or open questions at the end.
4. Paste the handoff format. Every template uses the same seven fields.
5. Connect the handoff. The router outputs pattern, reason, and brief as the startup prompt for the corresponding Kimi template.
6. Run three test requests. One broad, one deep, and one judgment-type, and check whether each goes into the right lane and whether every agent returns the format.

This system requires no code and is reusable. Next time there’s a new task, don’t build a new agent; first see which of the four shapes it belongs to. Most people try to make the bot stronger with a better prompt or a better model, and that can help before the wall. After the wall, the only thing you can change is the shape of the work: many focused agents replacing one overloaded agent. Route first, then run. The four shapes cover most cases; stack two when necessary. Share memory, standardize handoffs. Expect failure, retry with reasons, and mark whatever remains. You can install it tonight: router, four templates, then send off that big task you’ve been putting off.

Original link: https://x.com/0xMortyx/status/2114035717596733762

Ricker’s full guide: https://x.com/i/article/2112842988573331457