• conforms_to::[[Conviction Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Multiple Agents See Coherent State Without User-Land Coordination

The runtime platform guarantees that all agents see the same state at the same time. When two agents read the same value and both attempt to mutate it, the runtime serializes the operations: exactly one succeeds, and the other sees the post-update state and decides what to do next. There is no eventual consistency, no leader election, no distributed-lock dance, and no application-layer coordination protocol -- the runtime carries the bookkeeping that makes concurrent multi-agent state mutation tractable, and agents reason locally about state transitions without having to coordinate globally.

Why it is held

Multi-agent coordination patterns built outside the runtime fragment. Each team picks a coordination technology (distributed locks, optimistic concurrency control, CRDTs, leader-election protocols, vector clocks), each implementation has bugs the team rebuilds when discovered, and each requires reasoning about partial-state windows that the runtime primitive removes by construction. The application code that handles "did I get the lock? did the other agent take it? is my view of state still valid?" is not the application's actual logic -- it is bookkeeping the platform could provide. Treating coherent multi-agent state as a runtime primitive removes the coordination surface entirely: every agent's read sees the current state, every agent's mutation either commits atomically or sees the conflicting commit and decides what to do next.

The platform-as-coordinator stance composes with the atomic primitive ([[Agent Operations Commit Wholly or Roll Back Wholly]]). Serialization of concurrent mutations happens at the atomic-operation boundary: each agent's operation is an atomic envelope, and the runtime orders the envelopes so exactly one of any conflicting set commits. Without atomicity, the serialization would have to coordinate across partial-state windows -- exactly the partial-state failure mode the atomic primitive forbids. With atomicity, "agent A's operation committed; agent B's operation now sees the post-A state" is a clean before-and-after pair with no observable middle.

The platform-as-coordinator stance composes with the asynchronous-events primitive ([[Event Notification Is Atomic With State Change, Not Polled or Queued]]). Events are how agents react to other agents' state changes in a coherent-state world: when agent A commits a state change, agent B's registered listener observes the change atomically with the commit, and the listener firing is itself part of A's atomic envelope. A multi-agent runtime without atomic-envelope events would force agents to coordinate on a shared event log; a coherent-state runtime without event notification would force agents to poll. Both stances together make the multi-agent reactive scenario work end-to-end.

The Conviction is feasible because the platform is single-coherence-domain by design. Single-coherence-domain architecture is what makes runtime-level serialization tractable: the runtime can serialize because there is one runtime, not a federated set of runtimes whose ordering would require external coordination. The platform is explicitly not for horizontally-scaled clustered workloads (the anti-pitch Conviction surfaces this as one of the seven cases where the platform is the wrong runtime). Trading coherent multi-agent semantics for horizontal scale would surrender exactly the property that makes multi-agent coordination tractable on this platform.

The reference runtime provides building blocks: user-object sessions associate runtime objects with privileged identities, per-user resource limits give the platform visibility into per-agent resource pressure. The foundation layer's connection daemon mediates per-port connection state, and per-owner resource tracking provides partial mediation. The Cloud Server Reference's eight-primitives table marks coherent multi-agent semantics as "Partial" -- the user-object plumbing is present but the agent identity wrapper and inter-agent message protocol the MVA needs are gaps. The downstream agent-identity workstream is where the agent identity wrapper lands; subsequent workstreams build on the wrapper to demonstrate inter-agent coordination scenarios that exercise this Conviction's stance.

The Conviction is held because the no-coordination-protocol agent-coding experience is what platform adoption purchases for the multi-agent scenario. When all-agents-see-the-same-state is the runtime's promise, agent code reasons about state transitions locally and trusts the runtime to serialize. Trading the primitive for application-layer coordination would reintroduce exactly the bug-prone coordination protocols the primitive removes.

What it asks

Honoring this Conviction asks the project to keep multi-agent coordination inside the runtime, not to delegate it to application-layer coordination protocols.

• The downstream agent-identity workstream lands the agent identity wrapper that exposes the platform's coherent-state primitive at the agent-facing surface. The wrapper must associate each agent with a runtime user-object, scope the agent's mutations through the runtime's serialization, and surface the post-conflict state observation to the agent without requiring agent code to detect "I lost the race" via custom protocol.
• MVA scenarios that exercise multi-agent state assume runtime serialization, not application coordination. When the atomic-operation demonstration phase or future workstreams introduce concurrent operations on shared state, the demonstration architecture treats the runtime's serialization as the coordination mechanism. Demonstrations that introduce application-layer locking (semaphores, mutexes, retry-on-conflict logic) are operating outside the spirit of the primitive.
• Decisions introducing distributed coordination must surface the cost. A Decision adding "for cross-instance coordination, route operations through Redis/etcd" or "for high availability, run the platform behind a leader-election protocol" reintroduces exactly the partial-state windows and coordination patterns the primitive removes. Such Decisions weigh the distribution cost against the platform-fit cost imposed on this Conviction. The platform is single-coherence-domain by design; cross-instance coordination is outside the platform's primitive entirely.
• Communication distinguishes runtime-coherent state from eventual-consistency or distributed-locking patterns. When the project's coherent-multi-agent claim is communicated externally, the distinction between runtime-serialized in-memory state (runtime primitive) and eventually-consistent or distributed-locked state (cross-system patterns) is the load-bearing detail. The two are sometimes conflated in agent-infrastructure copy that uses "consistent" loosely.
• Workstream scoping checks the coordination scope for new agent capabilities. Workstreams adding capabilities that require cross-instance coordination (multi-machine clustering, federated agent networks) need to acknowledge they are operating outside the platform's primitive for those operations. The platform's primitive operates within a single coherence domain; cross-domain coordination is a different primitive on a different platform.

Drift recognition

The Conviction has weakened when the project's outputs treat multi-agent coordination as something application code arranges, rather than as the runtime's standing condition.

• Application-layer locks, semaphores, or retry-on-conflict logic added to agent code. When agent code accumulates explicit coordination primitives (acquire-lock, compare-and-swap loops, retry-on-version-mismatch patterns), the platform's runtime-serialized primitive is being worked around. The application is doing coordination the runtime already does, and the explicit code signals either distrust of the platform or accidental drift.
• Eventual-consistency framings introduced for in-runtime state. A Decision adding "for performance, accept eventual consistency on this state" inverts the Conviction's stance for that state. Once any state has been allowed to drift to eventual-consistency semantics, the runtime no longer carries the coherence guarantee for that state, and application code has to reason about consistency windows that the primitive normally removes.
• Distributed-locking infrastructure added for in-runtime coordination. Routing in-runtime coordination through external lock services (Redis, etcd, ZooKeeper) demotes the platform from "the coordinator" to "one component a separate coordinator orchestrates." The demotion may be defensible for cross-instance integration; it is drift when applied to in-runtime state the platform's primitive already handles.
• Leader-election protocols introduced for in-runtime authority. A Decision adding "agents elect a leader for this operation" reintroduces exactly the leader-election dance the value-prop's primitive list named as something the runtime removes. The dance is drift evidence; in a held-Conviction world, the runtime's serialization is the authority, and election is unnecessary.
• Cumulative drift across multiple sessions. If two or three consecutive sessions add features that quietly lean on application-layer coordination, eventual consistency, or external lock services without surfacing the platform-fit cost, the project has drifted from holding the Conviction.

Sources

• The project's agent-runtime value-proposition draft, Section 3 ("What runtime-level primitives look like"), Draft v2 dated 2026-04-25. Carries the coherent-multi-agent-semantics primitive's articulation: "All agents see the same state at the same time. When two agents both read 'budget is $500' and both try to spend it, the runtime serializes -- exactly one succeeds; the other sees the updated state and decides what to do next. No eventual consistency, no leader election, no distributed-lock dance." This Conviction's stance opening preserves the no-eventual-consistency / no-leader-election / no-distributed-lock-dance triple verbatim because it is the load-bearing distinction. The single-coherence-domain framing referenced in the Why It Is Held section comes from the value-proposition draft's discussion of the platform's architectural commitment to a single coherence domain. Cited by path; not authored as a Reference node per the URL-resolvability principle in the Reference Form Contract.

• The Cloud Server Reference's Mapping section. The eight-primitives table identifies the runtime's user-object sessions and per-user resource limits as the runtime building blocks, the foundation's per-port connections and per-owner resource tracking as the partial mediation, "Partial" status with the gap noted as needing an agent identity wrapper and an inter-agent message protocol. The downstream agent-identity workstream closes the agent identity wrapper gap; subsequent workstreams build on it. The Reference is the graph's authoritative anchor for the present-but-partial implementation grounding.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Conviction-form node in the eOS-DeepContext graph. Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape and the prohibitions on has_commitment::, decided_on::, and has_epistemic_status:: in the identity block.

• in_practice_domain::[[eOS Continuum]]

  • The coherent-multi-agent-semantics primitive is one of eight runtime primitives the eOS-Harness MVA is responsible for grounding in the graph.

• informed_by::[[Cloud Server (Croes, 2012, rev. 2026)]]

  • The Reference's eight-primitives table provides the graph's authoritative framing for what the foundation layer provides for coherent multi-agent semantics: the runtime's user-object sessions and per-user resource limits as the runtime building blocks, the foundation's per-port connections and per-owner resource tracking as the partial mediation, "Partial" status with the gap noted as needing an agent identity wrapper and an inter-agent message protocol. The Reference grounds the implementation-level claims this Conviction's What It Asks section makes about MVA scenarios and the downstream agent-identity workstream.

• informs_downstream::[[eOS-Harness Minimum Viable Architecture]]

  • The atomic-operation demonstration phase exercises this Conviction's stance whenever the demonstration architecture introduces concurrent operations on shared state. Future workstreams (agent identity, sample agents) carry the Conviction's asks forward as the agent identity wrapper and as inter-agent coordination scenarios that demonstrate runtime serialization rather than application coordination.

• composes_with::[[Agent Operations Commit Wholly or Roll Back Wholly]]

  • Coherent multi-agent semantics and atomicity reinforce each other tightly: serialization of concurrent mutations happens at the atomic-operation boundary; each agent's operation is an atomic envelope, and the runtime orders the envelopes so exactly one of any conflicting set commits. Without atomicity, the serialization would have to coordinate across partial-state windows -- the failure mode the atomic primitive forbids. With atomicity, before-and-after pairs are clean.

• composes_with::[[Event Notification Is Atomic With State Change, Not Polled or Queued]]

  • Coherent multi-agent semantics and asynchronous events reinforce each other at the multi-agent boundary: events are how agents react to other agents' state changes in a coherent-state world; the listener firing is part of the committing agent's atomic envelope. A multi-agent runtime without atomic-envelope events would force agents to coordinate on a shared event log; a coherent-state runtime without event notification would force agents to poll. The two together make the multi-agent reactive scenario coherent.

• grounded_in::[[Adopt Single-Coherence-Domain Architecture]]

  • The Decision that commits the platform to a single coherence domain by design. The coherent-multi-agent-semantics primitive is feasible because of that commitment; horizontal scaling would force the serialization to coordinate across runtime instances and reintroduce the partial-state windows the primitive removes. The Decision's What Would Change It section names the conditions under which the architectural commitment would be revisited; this primitive's platform-level claim depends on those conditions remaining unmet.

• grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]

  • The meta-Conviction this primitive is one instance of: what is normally a pattern (distributed locks, optimistic concurrency control, leader-election protocols, eventual-consistency reconciliation) becomes a primitive in the runtime that every line of agent code can rely on; external coordination patterns cannot deliver platform-level coherent multi-agent state.

• grounded_in::[[Runtime State Is Persistent by Default, Not by Application Discipline]]

  • Multi-agent coherence matters because the shared state agents serialize access to must survive across agents and restarts alike. Without orthogonal persistence, "all agents see the same state at the same time" would hold only within a single process lifetime; with it, coherence is a runtime-scope guarantee agents can rely on across the runtime's entire operating lifetime, not just within one uptime window.