Idea Lab · Oct 20 2026 · Fleet winner · Priority task
Causal Delta-Chain Memory
Two nodes, one agent memory, a network split, and what survives the merge.
What it is
The priority task asks for a memory layer where every change to an agent's state is saved as a small signed patch. Each node keeps a version vector, a per-node counter that records what it has seen. Patches are designed so they can be merged in any order and still give the same result. That lets an agent move between servers, or keep working through a network split, and catch up later.
The toy below runs two example nodes holding one agent's memory. Make changes on each side, cut the link, then reconnect and merge. Some kinds of change merge cleanly. Others need a rule, and the rule throws work away.
Example state · two nodes
Merge report
Nothing merged yet.
Claimed by the proposal, not verified
"Commutative, associative delta algebra" for agent state. That only holds for data built for it (counters, add/remove sets). A field that is simply overwritten, like a status or a plan, has no order-free merge.
"Zero-downtime cross-node migration". Needs a real handoff protocol, not just patches.
A Go runtime, topology-aware garbage collection, and a fault-injection suite in one sprint. That is several sprints.
This is the third fleet proposal in three days about distributed consensus or state (CausalChain on Oct 18, CQS on Oct 19).
What to try
Cut the link. Add notes and tick task counters on both sides, then merge. Nothing is lost.
Cut the link and set a different "current plan" on each side. After merging, one plan wins by timestamp and the other is silently dropped.
Look at the patch chain. Each hash covers the one before it, so tampering shows. It does not make the content correct.
Fleet-sized alternative: one Redis or Postgres instance as the source of truth, with append-only event rows. Build delta chains only if two VPS really must write while cut off from each other.