Causal synchronization in Agent Mesh: when is a peer ready?

Receiving the newest message may not be enough

A peer may learn that work was reassigned before receiving the evidence that explains the previous assignment's expiry. Applying the newest-looking record immediately can skip the context needed to interpret it.

The causal synchronization guide describes signed state exchange and catch-up evidence through causal anti-entropy. Readiness gates prevent acting when required predecessors or membership context are missing. They address the dependency of a transition on admitted history.

Treat catch-up as resolving specific missing context

In an illustrative restart scenario, an offline peer returns with a persisted local head. Other peers have advanced membership and reassigned work. The returning peer needs enough authenticated history to understand the relevant transition, not simply the current wall-clock time.

A useful operator view identifies which predecessor or membership requirement remains unresolved. “Synchronizing” is helpful as a broad status, but a retained reason makes it possible to distinguish a slow transport from a conflicting or unavailable record.

Readiness does not certify the decision

Synchronization establishes visibility of state. It does not by itself certify agreement or grant an external effect. A peer can have the necessary history while still lacking the policy decision required for the next operation.

The authority boundaries remain relevant after catch-up. For example, discovering the current assignment does not mean the peer itself owns it. Re-evaluate the intended action against its actual assignment and the current effect boundary.

Handle unresolved evidence during disconnection

Missing, stale or conflicting evidence needs an explicit policy outcome. The Mesh failure guidance describes pausing, narrowing eligibility and reconciling before recovery.

Do not invent a recovery shortcut that marks a peer ready merely because a retry timeout expired. A timeout can trigger an operational response, but it cannot supply a missing causal predecessor. Your application needs a policy for waiting, obtaining additional evidence or stopping the affected work.

Verify readiness under reordered delivery

• Deliver a dependent record before its required predecessor.
• Observe that affected work remains gated.
• Supply the missing authenticated context and inspect readiness.
• Repeat with obsolete membership information.
• Check that restored visibility does not bypass assignment or effect authorization.

The synchronization example is a starting reference for implementation. Retain the delivery order and evidence in your own test report so a successful catch-up can be distinguished from an accidental ordered-message assumption.