Handoffs without the 3 a.m. loop

1. The arrow test

@rvaniaaaa wrote one of the most useful critiques of bot teams this month. In the post sharing it, @rvaniaaaa wrote: "One prompt audits your whole team. One script stops runaway handoffs. One 4-line test for every new bot".

The core idea is what we'll call the arrow test. Draw your bots as boxes and each handoff as an arrow. Then look at the shape.

• If the arrows form a single line (A hands to B hands to C hands to D) and nothing happens in parallel, you don't have a team. You have one job split into four pieces, with three extra handoffs where context can get lost. One bot with a good checklist would probably do it faster and cheaper.
• If the arrows fan out (one bot hands separate pieces to several bots that work at the same time) or each box has a different owner of a different outcome, the split is earning its keep.

Figure explanation: The top row is bots A, B, C, and D in a single line, with nothing in parallel. The lower sketch is one lead handing separate pieces to research, drafting, and design at the same time. The arrow test in this part says the line is usually one job with extra hops, and a fan-out or a different owner for each outcome can earn the split.

Run this test on your own setup before reading further. It takes five minutes and often removes a bot.

2. Pass files, not chats

The Official docs are specific about how context moves: "Conversations and learned context stay separate per Bot, while shared files, browser sessions, and direct handoffs move context between them." Bots on your account share one computer, which "makes handoffs work without repeating setup." ^[1]

In practice: when one seat finishes its part, it should leave a file another seat can pick up, not a long chat the next bot has to reconstruct. A good handoff file is short and boring:

• what was asked,
• what was done,
• what's left, and for whom,
• where the inputs and outputs live.

Our recommendation is to keep one owner at each stage: for any given step, exactly one bot is responsible, and the handoff file names who that is. To be clear, that's Botski's advice, not a quote from xAI. We looked for that wording in the Grok Bot docs and didn't find it. The closest Official example is xAI's own IncidentWatch and IncidentSweep, two bots with one job each, which Part 3 covers in detail.

3. Stop rules on every chain

A handoff that can hand back can loop. Bot A asks Bot B to check something, B finds a problem and hands it back to A, A "fixes" it and hands it to B again. Left alone, that can run until something stops it, and every hop is a turn on your usage.

Two rules to add to every bot that hands work to another bot:

1. A hop limit. Something like: If this task has already passed between bots three times, stop and ask me. Put a hop count in the handoff file so each bot can see it.
2. Stop on failure. If a step fails, stop and report what happened. Don't retry by handing it to another bot. IncidentSweep follows this rule exactly: "if anything fails, it stops and reports what happened". ^[3]

On Teams, there's also an admin control. The v0.71.2 changelog (Oct 14) says team admins "can turn off Messaging between Bots under Bot capabilities on the dashboard, so members' Bots can't message or hand work to other Bots". ^[2] That's a blunt tool, but it's worth knowing it exists.

4. Ephemeral workers

@kocer_eth made a point about scale: agents "shouldn't be running all day. they should spin up for the exact window a task needs, finish it, and shut down until the next trigger".

For a Grok Bot team, the practical version is this: a seat that only matters when something happens should be started by that thing (a webhook, an email tag, a handoff from another seat), not woken on a timer to check whether anything happened. Our guide The Grok Bot Bill goes through the cost side of that choice.

5. A counterpoint on scale

You'll see big numbers in this space. @rvaniaaaa also wrote that "Grok Bot already has 624 ready-made bots in one public index". The same post warns: "A bad community bot has everything a good one has. Read it first".

A large catalog is a useful signal that people are building, and a good place to borrow ideas. It isn't proof that any one of those designs fits your work, or that more bots is better. Run anything you borrow through the arrow test first.

6. What this means for you

1. Run the arrow test on paper. Mark parallel arrows and straight lines.
2. Merge straight lines that one bot with a checklist could do.
3. Add a handoff file template to each seat's standing instructions: asked, done, left and for whom, where things live, and a hop count.
4. Add the two stop rules (hop limit, stop on failure) to every bot that hands work on, and ask each bot to remember them.
5. Swap timers for triggers where a seat only matters when something happens.

7. Tradeoffs and caveats

• Hop limits can stop good work. A limit of three will sometimes halt a chain that would have finished. That's the price of not looping all night; raise it for a chain you've watched.
• Files are shared. Handoff files sit on the computer all your bots share, so don't put anything in them a different seat shouldn't see.
• Stop-on-failure means more pings. You'll get more stop-and-report messages. That's the system working.
• The 624 figure is a community count, not an xAI number, and a big catalog says nothing about any one bot's quality.
• The admin toggle is all or nothing. Turning off Messaging between Bots stops good handoffs too.

Next step: Find handoff-ready team templates in the Botski directory. Check that each one has a hop limit and a stop rule before you add it.