A desk action log is a file you tell a Grok Bot desk to append to after each run: when it ran, what it did, which files it touched, what messages it sent, and what is waiting on your approval. It isn't a built-in feature. It's an instruction you put in the bot's description or a skill, the same way a handoff state file is. Grok Bot gives you separate bots with their own chat and memory, asynchronous messages between bots, and group chats. The log is the convention you add so you can review a desk's work in one place instead of scrolling several chats.
Who this is for
You run a few Grok Bot desks and want a quick way to answer "what did each one actually do today?" without reading every conversation.
What Grok Bot does, and what you add
| Built into Grok Bot | Pattern you add | |
|---|---|---|
| Separate desks | Each bot has its own chat and memory | One clear scope per desk, written in its instructions |
| Reporting | Bots can message each other asynchronously | An "append to your log after every run" instruction |
| Coordination | Bots can be put in group chats | A lead bot that reads logs (a role you define, not a feature) |
| Consequential actions | A stop-before-send rule you write into the bot description | A log line for every item waiting on approval |
| The record | — | One log file per desk with a predictable name |
Because each bot keeps its own memory, no single place shows what every desk did. The log file fills that gap.
The instruction and the entry
Add something like this to the desk's description or a skill:
After every run, append one entry to `logs/<desk-name>.md`:
time, what you did, files touched, messages sent,
and anything waiting on approval. Never edit past entries.A resulting entry:
## 2026-10-14 09:40 · Writer
- Did: drafted B50
- Files: drafts/50-grok-bot-desk-action-log-review.md
- Messages: told Reviewer the draft is ready
- Waiting on approval: nonePitfalls
- Assuming the log is complete. The desk writes it because you asked. If an entry is missing, treat that as a finding, not as proof nothing happened.
- Entries that say "done." Without files and messages listed, you can't check anything. Ask for specifics in the instruction.
- One log for every desk. Desks writing to one file make it hard to tell who did what. Use one file per desk.
- Confusing the log with the state file. The log records what happened. A handoff state file says where a task stands and who acts next.
How to check it
- Read one desk's latest entries against its written scope.
- Look for files outside its area, or messages to people it shouldn't contact.
- Check that anything that should have waited for approval is listed as waiting, not done. See hard approval boundaries.
- Spot-check one entry against the files it names.
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 logging line to each role 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
Add the logging instruction to one desk today and read its log after a few runs. Soft ladder: /free, then the Operator Pack ($47). Related: desk handoff, approval boundaries.