Most waits find nothing almost always: a daily release check says no 360 days a year, and a branch
watcher wakes on every push including everyone else. So the number to optimise is the useless wake
times how many there will be.
The fix is not a cheaper wake, it is pushing the relevance test into the wait condition so that firing
implies relevance. Wait on a push THAT CONTAINS a COMMS file, not on a push. Wait on a version string
that differs, not on a page that changed. Both are shell tests with no model in them.
Three tiers, most events dying at the first: shell condition (free), fresh minimal agent (one small
cold read), escalate with real context (a full read of a long session). A context-inheriting fork that
returns nothing to the parent is tier two done well, but it is still a read, so it is the fallback for
when relevance needs judgement rather than the default.
For the platform this means a condition belongs in the declaration, not in the agent that wakes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The field report describes the watcher for one purpose — one agent waiting on another's push. That is
where it was discovered, not where it belongs. Same shape answers: wait for the job, wait for the
container, wait for the credential file, wait for a human to reply.
What this adds over the field report:
the cost model as a formula idle is free forever; a wait costs `fires x context-at-the-time`, and
every wake is uncached by construction because the prompt cache TTL is
~5 min and nothing worth waiting for resolves that fast
block > poll > model most things Officer waits on can be blocked on rather than polled.
inotify for a file, tail --pid for a process, docker events, IMAP IDLE,
and — highest leverage and unbuilt — postgres LISTEN/NOTIFY, since
nearly everything here is already a row in one database
an exit-code contract 0 fired / 1 timed out / 2 broke. 1 and 2 must not be conflated: "nothing
happened" and "I stopped being able to tell" are opposite facts, and
absence reads as reassurance
lifetimes if the payload plus the repo is enough to act on, do not keep a session
alive to receive it. Event-spawned short-lived agents cost a constant
amount per event; resident ones cost more every time
Draft. One mechanism proven (the git poll, fired twice tonight); the contract and the Officer use-case
table are specification. Marked measured vs reasoned throughout.
On a branch, not master: the master checkout is pinned behind the remote while the server runs from it,
and pushing master would also trip the watcher currently armed on it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5