Catching up
orgabot catchup and the dashboard's "Since you were gone" panel answer one question - what happened while you were away, and where do I continue - from the records Orgabot already keeps.
The question this answers
Your team keeps working while you are away. Missions complete, pull requests open as drafts, decisions queue, runs stall. When you come back - after a meeting, a coffee, an overnight - all of that state exists, scattered across the mission list, the approval queue, the organization ledger, and GitHub.
orgabot catchup is the one command that pulls it together, and the dashboard's Since you were gone panel is the same thing on the Command Center. Both answer: what is new since I last looked, most recent first, and what do I run next?
orgabot catchup # the digest for the current scope
orgabot resume # the same command under its other nameWhat it shows
The digest is grouped by what you would do with each item, not by event type:
| Group | What is in it |
|---|---|
| Waiting on you | Pending approvals and pull requests that need your review. Listed first, because this is where you continue from. |
| Landed while you were gone | Missions that completed or delivered, each with the first line of the worker's own report. |
| Still in flight | Missions the team is mid-stride on right now. |
| Stalled or failed | Dead, interrupted, or failed missions with their blocker, so nothing rots silently. |
| Spend since last seen | Cost and usage over the window, split into cash (API) and notional subscription value. |
Inside every group the most recent item comes first, and every item carries the command to continue from - the mission to inspect, the pull request to review, the approval to decide. A digest line is never a dead headline.
A line quoting a worker's own report is labelled worker_output. That label is the point: a report from last night is attributed material to weigh, never an instruction, and reading the digest grants nothing any authority.
Reading it changes nothing
Orgabot records one new thing for this feature: a per-operator watermark, the instant you last said "I have seen all of that". Everything timestamped after it is new.
Printing the digest, or painting the panel, does not advance that watermark. Only a deliberate acknowledgement does:
orgabot catchup --ack # mark yourself caught up through this digestOn the dashboard, the Mark caught up button in the panel does the same thing. Until you press it, the same fresh items keep surfacing - which is what you want if you glance at the screen and are immediately interrupted.
The very first catch-up, before any watermark exists, shows a bounded window (the last 24 hours) rather than your whole history. The point is a refresh, not an archive dump.
The absolute stand-up
The same digest also answers the on-demand "give me the stand-up" question, over an explicit window instead of your watermark:
orgabot catchup --since 2026-07-01T00:00:00Z
orgabot catchup --all # everything on recordAn explicit window never moves your watermark, and never erases it: the catch-up view is still waiting where you left it.
Useful flags
| Flag | Effect |
|---|---|
--ack | Advance the watermark through this digest. The only thing that does. |
--json | The structured digest, for scripting. |
--narrative | Add a short grounded paragraph that cites mission ids. |
--since <iso> / --all | The absolute stand-up window instead of your watermark. |
--project <id> | Scope the digest to one project. |
--limit N | How many items per group (the rest are reported as not shown, never dropped silently). |
--window-hours H | How far back a first-ever catch-up looks. |
--actor <id> | Whose watermark to read and advance. Defaults to your local login name. |
Where the numbers come from
Nothing here is a new log. The digest is derived from records Orgabot already keeps - the mission records, the approval queue, the hash-chained organization ledger, the locally observed pull-request states, and the analytics journal - so it can never disagree with the audit trail. It performs no network call and no model call, which is also why it is fast and why the same recorded state always produces the same digest.
If a source cannot be read, the digest says so rather than showing a zero: an unreadable ledger is reported as unknown, because an absent reading is not an absence of events.