A desk handoff is a pattern for passing work from one Grok Bot to another: the bot finishing a step writes a short state file (what's done, what's next, who owns it, what's blocking), then messages the next bot. The next bot reads the file before it acts. Grok Bot gives you the pieces: separate bots with their own chat and memory, asynchronous messages between bots, and group chats. The state file is a convention you add on top so the record doesn't live only in someone's chat history.
Who this is for
You run more than one Grok Bot, say a writer, a reviewer, and a publisher, and work is starting to fall between them: a bot redoes something already done, or a message says "ready" with no clue where the output is.
What Grok Bot does, and what you add
| Built into Grok Bot | Pattern you add | |
|---|---|---|
| Separate desks | Each bot is its own assistant with its own chat and memory | One clear job per bot, written in its instructions |
| Nudging the next desk | Bots can message each other asynchronously | A message that points to the state file, not a full recap |
| Group coordination | Bots can be put in group chats | A lead bot that assigns owners (a role, not a feature) |
| Consequential actions | A stop-before-send rule you write into the bot description | "A handoff passes work, not permission" in every desk's rules |
| The record | — | A state file per task in an agreed folder |
Because each bot keeps its own memory, the next desk doesn't automatically know what the last one did. That gap is exactly what the state file fills.
The state file
Keep it short enough to read in one pass. One file per task, with a predictable name like `handoff/<task-id>.md`:
# Task: B45 draft
Status: draft done, waiting on review
Owner (next step): Reviewer
Inputs: briefs/45-grok-bot-desk-handoff.md
Outputs: drafts/45-grok-bot-desk-handoff.md
Blockers: none
Not approved yet: publishing
Updated: 2026-10-14 by WriterThen the message: "B45 draft is done. State is in `handoff/b45.md`." The file is the record; the message is the nudge.
Pitfalls
- Two owners. If two bots both believe a task is theirs, you get duplicate work. One named owner per task, and every bot checks the file before starting.
- Reassigning by chat. Asking two bots at once creates races. Reassign by editing the owner line, then message the new owner.
- Status only in messages. Messages arrive later and get buried. If it isn't in the file, the next desk shouldn't assume it.
- Treating handoff as approval. The receiving bot has the same limits as the sender. Sends, posts, and spend still wait for you.
How to check it
- Pick a task and read only its state file. Can you tell who acts next and where the output is? If not, the file is too thin.
- Look for any task with no owner or two owners.
- Check that no desk took a send or publish step after a handoff without your approval.
Where ShipKits fits
The Operator Pack ($47) is markdown seats + skills + install.sh — not a hosted app, not a chatbot. Seven named seats, three skills, an ops playbook and a token-cost playbook. Done means a file, PR, or URL. Adding a handoff section to each role ("read the state file first, update it last") is a quick way to put this pattern into practice. Soft path: start at /free. Cheat Sheet for the skim checklist mindset.
Soft next step
Pick one task that crosses two of your bots and give it a state file before the next handoff. Soft ladder: /free, then the Operator Pack ($47).