After this guide, your chief of staff can guarantee that every capture reaches a disposition — a committed note, a labelled task, or one clarifying question — by debouncing a burst into a single bounded worker run it can prove with commits.
Listen read aloud, 8 min — or as a conversation, 8 min
Read aloud 8 min · narrated
As a conversation 8 min · two people

The problem

Most “capture” guides end the moment a note lands in an inbox folder. That ending is a lie.

An inbox that fills faster than it drains is not a system — it is a guilt ledger. The real promise a principal wants from a chief of staff (human or AI) is not “I capture everything.” It is: everything I dump reaches a disposition by morning. Not read. Not triaged into ten tags. Disposed of — turned into a vault note with provenance, a task with a venture label and a mode, a committed file, or a question sent back to the principal. Every input terminates in one of those states, and no input terminates in silence.

The hard part is the guarantee, not the capture. Capture is one event. Disposition is a workflow: burst handling, context gathering, judgment, writing, committing, and answering — repeated dozens of times a day, unattended, at hours the principal is not watching. If your design requires the principal to press a button, remember to run a command, or check whether the last run succeeded, you do not have a machine. You have a chore.

This guide describes a triage machine that makes the promise mechanically keepable.

The philosophy behind the choice

A pipeline, not a to-do list. The inbox is not a list the AI reads when someone asks it to. It is a work queue feeding an event-triggered worker. The trigger is the arrival of new input — nothing else. Empty inboxes never invoke the model; scheduled no-op runs are waste, and they are the fastest way to burn trust in the whole setup. Every model run must be traceable to a real event.

Bursts are one work unit. People don’t send thoughts; they send them in bursts — three messages in forty seconds, a correction after a screenshot. Triage each message separately and you get three half-context runs that contradict each other. The machine therefore debounces: after a capture, it waits a short quiet window (~15 seconds) that resets on every new arrival (capped at a few minutes). When the window finally lapses, the entire burst becomes one triage run with full context. Cheap, and it eliminates the “wait, you said Saturday” class of error.

Resumable, not lost. A crashed or interrupted run is retried, not abandoned — but only within a bounded window. When a new burst arrives within roughly 30 minutes of the last worker’s exit, the worker resumes that worker’s conversation instead of starting cold. Two guardrails make this safe: on resume, the worker must re-read the inbox and the recent git log — files outrank memory — because a resumed session’s context may be stale; and resume chains are capped (a fixed burst count and a same-day requirement), after which the next run is forced fresh. Any resume failure falls back to a fresh run automatically. Fresh is always the default after quiet gaps.

Dispositions, not questions. The worker operates under the constitution — the same rulebook a human chief of staff would follow — so ask-first means ambiguity comes back as a clarifying question on the principal’s chat, not as an improvised action. But the default output is work already done: a note written into the vault with a provenance comment, a task pre-drafted with the right labels, a commit that makes the whole thing auditable. Questions are the exception the principal pays attention to, precisely because everything else required none.

Bounded authority. The worker is scoped hard: it commits once, replies only through the sanctioned channel to the principal’s own chat, and it may not install schedules, hold credentials, or touch external accounts. Unattended power demands unattended limits.

How it’s wired at a high level

Four stages, all plain files plus one daemon each:

Trigger. A capture listener (see the companion guide on long-poll pickup) detects new input and rings the bell. The trigger is only ever message-arrival or an explicit user action like a “process inbox now” button — never a timer.

Debounce. After the first capture, the trigger holds a 15-second quiet window. Each new arrival resets it, up to a ~5-minute cap. When the window lapses, one worker is spawned for the entire burst. A single-flight lock (stale locks auto-clear after ~20 minutes) guarantees two workers never run at once — a burst landing mid-triage waits and runs right after.

Worker. A headless session in the vault runs a triage command. It reads the inbox, recent git log, and whatever the captures reference; it writes vault notes with “ provenance; it drafts tasks; it commits; it answers questions back on the principal’s chat. If the burst resumes a prior worker, guardrail 1 applies first: re-read the files, trust the transcript only where the files agree.

Outputs. Every run ends in one of: (a) a committed vault note, (b) a task in the tracker, (c) a reply asking exactly one clarifying question, or (d) a combination. Optionally a receipt — a log line or commit — records what was disposed. The morning brief then never reports on routine captures; it surfaces only what genuinely needs the human: open decisions, failed dispositions, questions. The routine is invisible because it is finished.

The whole chain is resumable within the 30-minute window described above, which is what converts “retry semantics” into “the promise holds even when the machine hiccups.”

What a reader’s chief of staff should be able to do afterwards

  • Keep the promise: “Everything I dump reaches a disposition by morning” — and be able to prove it by pointing at the worker’s commits, not by asserting it.
  • Configure the debounce and single-flight lock: tune the quiet window and cap for their own message rhythm, and explain why splitting a burst is wrong.
  • Specify resume semantics: the resume window, the files-outrank-memory re-read, the chain cap, and the automatic fresh-run fallback — in a testable one-paragraph rule.
  • Separate routine from signal: set up the morning brief so it surfaces only questions and failures, never already-disposed items.
  • Bound the worker: write the authority limits (one commit, one channel, no schedules, no credentials) into the constitution so unattended runs stay auditable.

The end state: the principal dumps thoughts at 11pm from a phone, and at 7am finds notes, tasks, and at most one question — never a pile.

#triage · #inbox · #automation · #claude-code · #git

Hand this to your chief of staff. Plain Markdown: /guides/contributed/from-capture-to-disposition.md. Tell it: "Read this guide and tell me what in our system it would change."

Also for your Claude: whole-site index · bootstrap prompt · guide feed