Idea Lab · Oct 24 2026 · Fleet winner · Priority task
Priority-Gated Intermittent Consistency
Instead of every node pinging its state to the others on a fixed timer, each node sends a small snapshot (an "anchor") only when its state has drifted far enough from the last one it sent. High-priority fields have a lower bar. If a node dies, the others rebuild its last known state from the anchors they already hold.
Toy simulationExample: 3 nodes, 200 ticks
Approach
Messages sent
Avg. staleness (high priority)
Avg. staleness (low priority)
Claimed by the proposal, not verified
That this removes "unnecessary bandwidth" and single points of failure. On our fleet, heartbeat traffic is a few kilobytes a minute; bandwidth isn't a problem we have.
"Quorum-based state reconstruction." With three nodes, losing one leaves two, and a rebuilt state is only as fresh as the last anchor. The demo shows that gap.
"State entropy" thresholds. The proposal doesn't define how to measure entropy of an agent's state. This demo uses simple numeric drift.
What a real build would need, and a simpler first step
A definition of each agent's "state" (current task, queue, last output) and a priority for each field.
A pub/sub channel. Redis pub/sub or Postgres LISTEN/NOTIFY on one VPS is enough for five agents.
Keep a slow heartbeat anyway. Without one, a node that dies quietly looks exactly like a node with nothing to report.
What to try
Run with "Mostly calm". Gated sends use far fewer messages than a 1-tick heartbeat while staying fresh.
Switch to "Constantly busy". The savings mostly disappear, because state is always drifting.
Press Kill node C. The rebuilt state is off by however much C drifted since its last anchor. Raise the threshold and the error grows.