C.W.K.
Stream
Lesson 02 of 04 · published

Pull, Don't Push

~9 min · pull-model, read-before-claim, sidekick, freshness

Level 0Lone Machine
0 XP0/37 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A five-minute-old chat turn is a memory of a conversation. It is not proof that a machine is still awake."

Push vs pull, and why Watchfire pulls

Some Sidekicks push: a document editor sends the current document into the model every turn, because the doc is small and the whole point is to edit it. Watchfire is a durable engine watching a fleet that changes on its own, so it does the opposite — it pulls. Read-only host tools fetch source-of-truth state by a stable id, on demand, when a claim actually needs it.

Bound to the fleet, not the selected Mac

The Sidekick binds to a durable fleet host — host_kind=watchfire, a stable id — not to whichever Mac happens to be selected in the browser. The active surface rides along as a context cursor you can Follow or Pin, and at send time a frozen turn_context_ref locks it, so a running answer stays bound to the context it was asked in even if you navigate away. (The same stale-context guard you met with Cmd+K, now at conversation scale.)

Read fresh before any claim

The system rule is blunt: before asserting anything about current fleet, host, or terminal state, do a fresh status or read call. Prior chat turns are memory of the discussion — they are not evidence that a Mac is still reachable or that an observation is still current. The conversation remembers what was said; only a fresh read knows what's true now.

No pre-chewed snapshot per turn

And Watchfire never injects a whole fleet snapshot into every chat turn. That would be the paste-the-world trap from the Durable Operations track wearing a Sidekick costume: a snapshot goes stale the instant it lands, and now the conversation carries a rival, decaying copy of the truth. Pull by id, read live, and report the freshness alongside the value so the reader knows how old the fact is.

Pull the truth when you need it; never cache it into the conversation. A read is current; a snapshot is a memory pretending to be current.

Code

Pull by id, read fresh, report freshness·python
# WRONG -- push a snapshot into every turn (it's stale on arrival):
#   turn.context = whole_fleet_snapshot()

# RIGHT -- the Sidekick pulls source-of-truth by stable id, on demand:
status = sidekick_host_status(host_kind="watchfire", host_id="fleet")

# Before ANY claim about 'right now', read fresh:
host = sidekick_host_read(scope="host", host_id="server")
say(f"{host.name} is {host.status} (observed {host.observed_at}, {host.freshness})")

# Prior chat turns are memory of the discussion -- never proof the Mac is
# still reachable. The read is the proof; report its freshness with it.

External links

Exercise

Take an assistant or dashboard that reports on changing state (a status page, a chatbot over live data). Decide, for each claim it makes, whether it's reading fresh or repeating a cached value. Redesign one claim so it pulls current state on demand and shows the reader how old the value is. What does the freshness label protect them from?
Hint
The freshness label protects the reader from acting on a fact that quietly expired. 'Server: healthy (12 seconds ago)' is trustworthy; 'Server: healthy' with no timestamp could be from now or from an hour ago, and the reader has no way to tell which.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.