Paper deep dive
MPAC: A Multi-Principal Agent Coordination Protocol for Interoperable Multi-Agent Collaboration
Kaiyang Qian, Xinmin Fang, Zhengxiong Li
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 98%
Last extracted: 4/14/2026, 1:46:36 AM
Summary
MPAC (Multi-Principal Agent Coordination Protocol) is an application-layer protocol designed to enable coordination between independent AI agents owned by different principals. It addresses the limitations of existing protocols like MCP (tool invocation) and A2A (single-principal delegation) by providing explicit semantics for session management, intent declaration, operation execution, conflict resolution, and governance. MPAC features optimistic concurrency control, causal watermarking, and human-in-the-loop arbitration, demonstrating significant reductions in coordination overhead in multi-agent scenarios.
Entities (5)
Relation Signals (3)
Kaiyang Qian â authored â MPAC
confidence 100% ¡ MPAC: A Multi-Principal Agent Coordination Protocol... Kaiyang Qian
MPAC â complements â MCP
confidence 100% ¡ MPAC is not a replacement for MCP or A2Aâit is a complementary layer.
MPAC â complements â A2A
confidence 100% ¡ MPAC is not a replacement for MCP or A2Aâit is a complementary layer.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The AI agent ecosystem has converged on two protocols: the Model Context Protocol (MCP) for tool invocation and Agent-to-Agent (A2A) for single-principal task delegation. Both assume a single controlling principal, meaning one person or organization that owns every agent. When independent principals' agents must coordinate over shared state, such as engineers' coding agents editing the same repository, family members planning a shared trip, or agents from different organizations negotiating a joint decision, neither protocol applies, and coordination collapses to ad-hoc chat, manual merging, or silent overwrites. We present MPAC (Multi-Principal Agent Coordination Protocol), an application-layer protocol that fills this gap with explicit coordination semantics across five layers: Session, Intent, Operation, Conflict, and Governance. MPAC makes intent declaration a precondition for action, represents conflicts as first-class structured objects, and supports human-in-the-loop arbitration through a pluggable governance layer. The specification defines 21 message types, three state machines with normative transition tables, Lamport-clock causal watermarking, two execution models, three security profiles, and optimistic concurrency control on shared state. We release two interoperable reference implementations in Python and TypeScript with 223 tests, a JSON Schema suite, and seven live multi-agent demos. A controlled three-agent code review benchmark shows a 95 percent reduction in coordination overhead and a 4.8 times wall-clock speedup versus a serialized human-mediated baseline, with per-agent decision time preserved. The speedup comes from eliminating coordination waits, not compressing model calls. Specification, implementations, and demos are open source.
Tags
Links
- Source: https://arxiv.org/abs/2604.09744v1
- Canonical: https://arxiv.org/abs/2604.09744v1
Trouble viewing inline? Open PDF directly â
Full Text
61,916 characters extracted from source content.
Expand or collapse full text
MPAC: A Multi-Principal Agent Coordination Protocol for Interoperable Multi-Agent Collaboration Kaiyang Qian aistatus.c University of Colorado Denver (CU Denver) Denver, CO 80204 kaiyang.2.qian@ucdenver.edu Xinmin Fang aistatus.c University of Colorado Denver (CU Denver) Denver, CO 80204 xinmin.fang@ucdenver.edu Zhengxiong Li aistatus.c University of Colorado Denver (CU Denver) Denver, CO 80204 zhengxiong.li@ucdenver.edu Abstract The AI agent ecosystem has converged on two protocols: the Model Context Proto- col (MCP) for tool invocation and Agent-to-Agent (A2A) for single-principal task delegation. Both assume a single controlling principalâone person or organization that owns and trusts every agent in the system. When independent principalsâ agents must coordinate over shared stateâtwo engineersâ coding agents editing the same repository, family membersâ agents planning a shared trip, agents from different organizations negotiating a joint decisionâneither protocol applies, and coordination collapses to ad-hoc chat, manual merging, or silent overwrites. We present MPAC (Multi-Principal Agent Coordination Protocol), an application-layer protocol that fills this gap with explicit coordination semantics across five logical layersâSession, Intent, Operation, Conflict, and Governance. MPAC makes intent declaration a precondition for action, represents conflicts as first-class structured objects rather than silent side-effects, and supports human-in-the-loop arbitration through a pluggable governance layer. The specification defines 21 message types, three state machines with normative transition tables, Lamport-clock watermarking for causal ordering, two execution models (pre-commit and post-commit), three security profiles, and an optimistic-concurrency-control mechanism for shared state. We release two interoperable reference implementations (Python, 122 tests; TypeScript, 101 tests; 66 adversarial enforcement tests total), a machine-readable JSON Schema suite covering all 21 message types, and seven live multi-agent demos spanning code editing, consumer trip planning, pre-commit authorization with fault recovery, and multi-level conflict escalation. A controlled three-agent cross-module code review benchmark reports a 95% reduction in coordination overhead (68.65 sâ3.02 s) and a 4.8Ăwall-clock speedup (131.76 sâ27.38 s) under MPAC compared to a serialized human-mediated baseline, with per-agent decision time preserved (63.11 sâ57.13 s)âdemonstrating that the speedup comes from eliminating coordination waits, not from compressing model calls. The full specification, reference implementations, test suites, and demo transcripts are released as open source. 1 Introduction The artificial intelligence (AI) agent ecosystem is growing fast around two complementary protocols. The Model Context Protocol (MCP) [2] standardizes how a single agent discovers and invokes Preprint. arXiv:2604.09744v1 [cs.MA] 10 Apr 2026 external tools: file systems, databases, SaaS APIs, and so on. Its success is evident in the rapid proliferation of MCP servers for commercial services. The Agent-to-Agent (A2A) protocol [7], introduced shortly after, standardizes how a single orchestrator agent delegates sub-tasks to worker agents under its authority, with a shared notion of âtaskâ and âartifact.â Both protocols share a foundational assumption: there is one principalâone person, team, or organizationâthat owns, trusts, and is accountable for every agent participating in the interaction. This single-principal assumption is becoming a bottleneck. Consider a concrete and entirely realistic scenario. Alice and Bob are two engineers on the same software team. Alice runs a security- focused coding agent; Bob runs a code-quality coding agent. Both agents have full edit access to the shared repository. Aliceâs agent decides to patch a token expiry validation bug inauth.pyand auth_middleware.py. Bobâs agent, operating in parallel, decides to refactor authentication logic to remove duplicationâacrossauth.py,auth_middleware.py, andmodels.py. Neither agent reports to the other. Neither principal has authority over the otherâs agent. There is no orchestrator. MCP is silent on the problem (it only mediates tool calls, not inter-agent coordination). A2A is silent as well (no single principal can legitimately tell both agents what to do). The agents proceed independently and either produce a merge conflict, silently overwrite each otherâs work, orâworst of allâproduce a plausible-looking but semantically inconsistent merged result. The same pattern recurs outside software: family membersâ agents negotiating a shared vacation itinerary, agents from different legal teams drafting a joint contract, smart-home agents belonging to different residents resolving HVAC preferences, and agents from competing organizations negotiating a supply-chain allocation. Each of these involves multiple independent principals whose agents must coordinate over shared state, but none has a single orchestrator with authority over all participants. The coordination layer between independent principals and their agents is simply missing from todayâs protocol stack. This paper presents MPAC (Multi-Principal Agent Coordination Protocol), an application-layer protocol designed to fill this gap. MPAC is not a replacement for MCP or A2Aâit is a complementary layer. MCP tells an agent how to call a tool; A2A tells an orchestrator how to delegate work; MPAC tells agents from different principals how to coordinate when no orchestrator exists. Contributions. 1.Problem framing. We articulate the multi-principal coordination gap as a distinct protocol-layer problem, separate from tool invocation (MCP) and orchestrated delegation (A2A), and enumerate the concrete guarantees a solution must provide. 2. Protocol design. We present MPAC, a five-layer protocol (Session, Intent, Operation, Conflict, Governance) with 21 message types, 3 state machines with normative transition tables, Lamport- clock causal watermarking, two execution models (pre-commit / post-commit), three security profiles (open / authenticated / verified), and explicit optimistic concurrency control on shared state. The design crystallizes a set of principlesâintent before action, attributable actions, structured conflict, and human-governed resolutionâinto machine-enforceable wire semantics. 3. Reference implementations and interoperability. We release two fully interoperable reference implementations, one in Python (âź3,500 LOC, 122 tests) and one in TypeScript (âź2,900 LOC, 101 tests), along with 66 adversarial tests specifically targeting enforcement bypass. A cross-language interop harness exchanges 14 messages bidirectionally with zero wire-format deviation. 4.Open JSON Schema suite. All 21 message types and 4 shared object types are defined as JSON Schema (Draft 2020-12) with an envelope schema that dispatches payload validation by message_typeviaif/thenconstraints, making third-party wire compatibility achievable by schema validation alone. 5.Empirical validation. We run seven live multi-agent scenarios using Claude as the agent backend, covering: (i) concurrent code editing with optimistic concurrency control, (i) consumer trip plan- ning with multi-principal task-set negotiation, (i) a controlled overhead-comparison benchmark, (iv) pre-commit authorization with agent fault recovery, and (v) multi-level conflict escalation with arbiter resolution. The overhead benchmark records a 95% reduction in coordination overhead and a 4.8Ă wall-clock speedup while holding per-agent decision time roughly constant. The rest of the paper is organized as follows. Section 2 formalizes the multi-principal coordination problem and contrasts it with adjacent protocols. Section 3 presents MPACâs design goals, non-goals, 2 and shared principles. Section 4 describes the protocol model and the five coordination layers. Section 5 enumerates the 21 message types and three state machines. Section 6 covers security profiles, authorization, and governance. Section 7 describes the reference implementations and their adversarial test regime. Section 8 reports empirical results from the live Claude agent scenarios. Section 9 surveys related work. Section 10 honestly discusses limitations and threats to the empirical claims. Section 12 concludes. 2 The Multi-Principal Coordination Problem We now describe the problem MPAC is trying to solve and make precise why existing tools do not solve it. 2.1 What âMulti-Principalâ Means A principal is an entity on whose behalf an agent acts and to whom the agent is accountable: a human user, a team, an organization, or an automated system with delegated authority. A session is single-principal if every participating agent is accountable to the same principal (possibly indirectly, through an orchestrator). It is multi-principal if two or more distinct, independent principals have at least one agent each, and no one principal has authority over the othersâ agents. Multi-principal coordination is qualitatively different from single-principal coordination in three ways. No unified decision-maker. In a single-principal system, ambiguity or conflict can always be escalated to the principal and resolved by fiat. In a multi-principal system, no such fallback exists. If Aliceâs agent and Bobâs agent disagree, there is no single human or meta-agent with the authority to simply decide. Resolution must either come from mutual agreement between principals, from a pre-agreed arbitration policy, or from escalation to an agreed arbiterâall of which need to be first-class protocol features, not implementation details. Limited trust. In single-principal systems, agents share a trust domain: they can assume other agents are correct, well-intentioned, and following the same policies. In multi-principal systems, agents from different principals may have different goals, different safety policies, different risk tolerances, and (in adversarial cases) different incentives to misreport state. The protocol must be defensible against adversarial or buggy participants, not just correct ones. Auditability across boundaries.In single-principal systems, audit logs live inside one organization. In multi-principal systems, every consequential action must be attributable across organizational boundariesâso that after the fact, each principal can independently verify what happened, who decided what, and based on what causal context. 2.2 Concrete Scenarios To ground the discussion, we describe four scenarios that recur across domains and that all require multi-principal coordination. The same protocol primitives should handle all of them. 1. Shared codebase, independent engineers. Two or more engineersâ coding agents independently select tasks from a backlog and edit a shared repository. Scope overlaps (same file, same function) must be detected before work begins, and optimistic concurrency control must be enforced at commit time. 2.Family trip planning. Three family membersâ agents jointly plan a 5-day trip, each advocating for its principalâs preferences (camping vs. boutique hotel, theme park vs. cultural workshop). They must negotiate overlapping claims on itinerary days and budget categories, and commit the resulting plan atomically. 3. Cross-organizational document drafting. Legal agents from two counter-parties draft sections of a shared contract. Neither team can unilaterally overwrite the otherâs text, and disputed clauses must be escalated to human lawyers. 3 4.Multi-tenant resource allocation. Agents from competing teams in a shared compute cluster negotiate job priorities. Conflicts must be surfaced to human administrators with full causal context. All four share the same structural requirements: (a) agents must declare what they plan to do before doing it; (b) the system must automatically detect overlapping or contradictory claims; (c) conflicts must be surfaced as structured, attributable objects rather than silent overwrites; (d) resolution paths must include human override; and (e) all of the above must be auditable by each principal independently. 2.3 Why Existing Protocols Do Not Suffice MCP is about tools, not coordination.MCP standardizes how an agent discovers and calls tools exposed by an external server. It is deliberately silent on what happens when two agents call the same tool at the same time, on how agents learn of each otherâs existence, and on how mutually inconsistent actions are resolved. MCP is the right protocol for single-agent-to-tool interaction; it is the wrong layer for agent-to-agent coordination. A2A is single-principal by design. A2A assumes an orchestrator that delegates tasks to worker agents. The orchestrator owns the authority chain: it decides who does what, receives all artifacts, and is the point of resolution for any ambiguity. There is no notion in A2A of two independent orchestrators meeting as peers and negotiating a shared outcome. Extending A2A with âjust let the orchestrators talk to each otherâ recreates the problem MPAC solves one level upânow there is no meta-orchestrator to decide between them. Message queues and locks are too low-level.One could imagine building multi-principal coordi- nation on top of a message queue or a distributed lock. But these primitives address the mechanism of serialization, not the semantics of intent, conflict, or governance. They provide no standard for how an agent should announce a planned change, how overlapping scopes are reported, how disputes escalate, or how human override is integrated. Every application would reinvent these semantics incompatibly. MPACâs goal is to provide the semantic layer once, so that heterogeneous agent systems can interoperate. CRDTs and OT address state, not coordination.Conflict-free replicated data types (CRDTs) [12] and operational transformation (OT) [5] provide principled ways to merge concurrent edits to shared data. They are orthogonal to MPAC: they address how to reconcile divergent state once a conflict has occurred, whereas MPAC addresses whether the agents should have made those edits in the first place, who gets to decide when preferences collide, and how the decision is audited. MPAC can be layered on top of a CRDT-backed shared store without modification; the two solve complementary problems. Agent frameworks are libraries, not protocols.Frameworks such as LangGraph [10], AutoGen [14], and CrewAI [3] provide Python APIs for building multi-agent applications. They are excellent at composing agents within a single application, but they are not wire protocols: two systems built with different frameworks cannot interoperate without custom bridges, and none of them defines a cross-framework notion of intent, conflict, or resolution authority. MPAC sits one level below these frameworksâany of them could use MPAC as its coordination wire format. 3 Design Goals and Non-Goals MPACâs design is organized around six stated goals and an equally important set of explicit non-goals. 3.1 Design Goals 1.Interoperability. Different agent systems, written in different languages, by different organiza- tions, should be able to coordinate through a shared message model. 2.Explicit coordination. Agents should announce intent before acting whenever possible, so that overlaps can be detected proactively rather than discovered after the fact. 4 3.Causal traceability. Every consequential action (commit, conflict report, resolution) should carry the causal context on which it was based, so that after-the-fact audits can reconstruct âwhat each participant knew when.â 4. Structured conflict handling. Conflicts should be first-class protocol objects with identity, category, severity, and attributable positionsânot implicit failures or hidden race conditions. 5.Human-governed collaboration. The protocol must support human override at every level. Automated resolution is a convenience; human authority is the fallback, and it must be reachable from any state. 6. Extensibility. Optional features, implementation-specific extensions, and future message types must be possible without breaking core interoperability. 3.2 Non-Goals We emphasize the non-goals because they are as important as the goals for evaluating the design. MPAC is deliberately not: â˘A transport protocol. MPAC semantics must be realizable over WebSocket, HTTP, message queues, gRPC, or any other reliable message-passing substrate. The spec does not mandate a transport binding. â˘A replacement for CRDTs, OT, or version control systems. It coordinates around shared state, not the state itself. â˘A single conflict-detection algorithm. It provides the structured representation of a conflict; the detection policy is left to coordinator implementations. ⢠A single security or trust framework. It defines three security profiles with different assumptions; concrete key management, identity issuance, and trust binding are out of scope. ⢠A replacement for MCP or A2A. MCP remains the right protocol for tool invocation; A2A remains the right protocol for single-principal delegation. MPAC complements both. 3.3 Shared Principles Seven principles cut across all five protocol layers. Intent before action. In Governance-profile sessions, participants must announce an INTENT_ANNOUNCEbefore issuingOP_PROPOSEorOP_COMMIT. In Core-profile sessions, they should. This single principle is what makes pre-emptive conflict detection possible. Attributable actions. Every operation, conflict report, and resolution must be attributable to a specific principal, so that audits can reconstruct responsibility across organizational boundaries. Causal context.OP_COMMIT,CONFLICT_REPORT, andRESOLUTIONmessages must carry a causal watermark in the envelope. Other messages should when available. Human override. The protocol must always expose an escalation path to a human principal for designated conflict classes. Human override is not an implementation afterthought; it is a normative requirement on governance-profile deployments. Transport independence.MPAC semantics must not depend on any specific transport. This is why the spec is organized around message types, state machines, and envelopes rather than connection lifecycles. Algorithm independence.A conflict object must look the same whether it was produced by a de- terministic rule, a heuristic, a model inference, or a human review. This is what allows heterogeneous detection strategies to interoperate. Coordinator-serialized total order.MPAC does not provide linearizability in the strict distributed- systems sense; it provides a weaker but sufficient guarantee: the session coordinator serializes 5 1. SESSION membership, identity, liveness HELLO¡ SESSION_INFO¡ HEARTBEAT¡ COORDINATOR_STATUS¡ SESSION_CLOSE 2. INTENT declare plans before acting INTENT_ANNOUNCE¡ INTENT_UPDATE¡ INTENT_WITHDRAW¡ INTENT_CLAIM(_STATUS) 3. OPERATION propose / commit mutations (OCC) OP_PROPOSE¡ OP_COMMIT¡ OP_REJECT¡ OP_SUPERSEDE¡ OP_BATCH_COMMIT 4. CONFLICT structured, first-class disputes CONFLICT_REPORT¡ CONFLICT_ACK¡ CONFLICT_ESCALATE 5. GOVERNANCE authority, policy, human override RESOLUTION (phase-scoped, authority-checked)¡ role policy eval override & resume normal lifecycle Coordinator total order Lamport clock epoch snapshot & recovery scope overlap detection authority enforcement Figure 1: MPACâs five logical coordination layers. The solid arrows on the left show the normal lifecycle: agents join a session, declare intents, propose or commit operations, andâif a conflict is detectedânegotiate in the conflict layer, with the governance layer as the final authority. The dashed arrow on the right shows the governance override path: aRESOLUTIONcan unfreeze a contested scope and return control to the intent/operation layers. All layers share a single session coordinator that provides total order (Lamport clock +coordinator_epoch), scope-overlap detection, snapshot- based fault recovery, and runtime enforcement of resolution authority. Implementations may merge these layers internally, but their externally visible semantics remain distinct. all state-mutating messages (commits, resolutions, intent-claim approvals) into a total order that participants eventually observe. This is analogous to single-leader replication. 4 Protocol Model 4.1 The Five Layers MPAC organizes coordination into five logical layers. Implementations may merge these layers internally, but the externally visible semantics must remain distinct. 1.Session Layer. Agents join a session, identify themselves, exchange credentials, negotiate capabilities and roles, and maintain liveness via heartbeats. Unregistered senders are rejected: every participant must complete aHELLOhandshake before any other message type is accepted. This âHELLO-first gateâ is normative and runtime-enforced in both reference implementations. 2. Intent Layer. Agents declare what they plan to do before doing it. An intent carries an objective, a scope (the set of resources it will touch), a priority, a time-to-live, and an optional basis (the causal context on which the plan was formed). Intents can be announced, updated, withdrawn, superseded, or claimed by a different agent if the owner becomes unavailable. Intent broadcasts give the coordinator a chance to detect overlaps before any mutation occurs. 3. Operation Layer. Agents propose and commit actual changes to shared state. Every commit carriesstate_ref_beforeandstate_ref_afterfields (SHA-256 hashes of the affected resources) for optimistic concurrency control. Stale commits are rejected withSTALE_STATE_REF, and the proposing agent must rebase on the latest committed state and retry. Multi-resource changes use OP_BATCH_COMMIT with either all_or_nothing or best_effort semantics. 4.Conflict Layer.When the coordinator detects overlapping scopes or contradic- tory goals, it emits aCONFLICT_REPORTâa structured object with identity, cate- gory (drawn fromscope_overlap,concurrent_write,semantic_goal_conflict, assumption_contradiction,policy_violation,authority_conflict, dependency_breakage,resource_contention; implementations may define additional categories), severity, and the set of implicated participants. Participants acknowledge with CONFLICT_ACK, which can mark the position as âseen,â âaccepted,â or âdisputed.â Unresolved conflicts may be escalated viaCONFLICT_ESCALATE. If no resolution arrives within a timeout, the overlapping scope enters a frozen state in which new mutations are blocked. 6 5.Governance Layer. Authority rulesâwho can resolve whatâare evaluated against the ses- sionâs role policy (Section 23.1.5 of the specification). Only owners or designated arbiters may resolve conflicts pre-escalation; only the escalation target or an arbiter may resolve post- escalation.RESOLUTIONmessages carry the deciding principalâs identity and the phase (pre- or post-escalation) at which the decision was made, so downstream audits can reconstruct the authority chain. 4.2 Two Execution Models MPAC defines two execution models that a session must declare up front inSESSION_INFOand cannot mix. Post-commit model.The agent applies the mutation to shared state first, then declares the completed mutation viaOP_COMMIT. In this model,OP_COMMITis a notification of a completed change. Conflicts discovered afterwards may require compensating operations. This model is suitable for Core-profile sessions and intra-team deployments where agents are trusted to act independently. Pre-commit model. The mutation is not applied until the coordinator explicitly authorizes execution.The canonical flow isOP_PROPOSE âcoordinator reviewâauthorization via COORDINATOR_STATUS âproposer executesâ OP_COMMIT. Authorization alone does not tran- sition the operation toCOMMITTED; the proposer must later declare the executed mutation. This model requires Governance profile and is recommended for cross-organizational deployments where all changes must be reviewed before taking effect. The explicit separation is deliberate: a protocol that silently âdepending on configurationâ flips between eager and lazy application is hard to reason about and hard to audit. A session must pick one model and stick with it. 4.3 Consistency Model MPAC provides three distinct consistency regimes depending on coordinator availability. 1.Coordinator-available (normal). The coordinator serializes all state-mutating messages into a single total order. Participants eventually observe the same linearized sequence. The coordinatorâs Lamport clock is the authoritative ordering mechanism. 2.Coordinator-unavailable (degraded). When participants detect coordinator unavailability, they must not perform state-mutating operations. Read-only and non-conflicting local work (planning, analysis) may continue, but no consistency guarantee applies to it. 3.Coordinator recovery (reconciliation). After recovery, the coordinator rebuilds authoritative state from its latest snapshot plus audit log replay and bumps itscoordinator_epoch. If any participant violated rule (2) and mutated state during the outage, the divergence is detected when the participantâs reported state fails to match the coordinatorâs recovered snapshot and the coordinator emits aPROTOCOL_ERRORwitherror_code: STATE_DIVERGENCE; the situation must then be reconciled through governance-level resolutionâthe protocol deliberately does not auto-merge divergent states, because in a multi-principal setting silent auto-merge would violate attributability. This model is weaker than strict linearizability (participants observe changes with transport-dependent delay) but stronger than eventual consistency (there is always a single authoritative order at the coordinator). In distributed-systems terms, MPAC behaves like single-leader replication. 4.4 Causal Watermarks Every consequential message carries aWatermarkobject in its envelope: a Lamport timestamp, a coordinator epoch, and optionally a sender-frontier summary. The Lamport clock guarantees that if eventAcausally precedes eventB, thenAâs Lamport value is strictly less thanBâs. The coordinator epoch distinguishes message sequences from different coordinator incarnations so that a post-recovery message cannot be mistakenly ordered against a pre-recovery one. Together these give auditors a total order over state-mutating events even when the transport delivers messages out of order. 7 Table 1: The 21 MPAC message types grouped by protocol layer. All 21 have JSON Schema payload definitions and live Claude API demo coverage. LayerMessage types Session HELLO,SESSION_INFO,HEARTBEAT,GOODBYE,SESSION_CLOSE, COORDINATOR_STATUS Intent INTENT_ANNOUNCE,INTENT_UPDATE,INTENT_WITHDRAW,INTENT_CLAIM, INTENT_CLAIM_STATUS Operation OP_PROPOSE, OP_COMMIT, OP_REJECT, OP_SUPERSEDE, OP_BATCH_COMMIT Conflict CONFLICT_REPORT, CONFLICT_ACK, CONFLICT_ESCALATE, RESOLUTION Error PROTOCOL_ERROR Sender incarnation tracking adds a second guarantee: if an agent disconnects and reconnects, its new session is assigned a fresh incarnation ID, so replay of old messages from a crashed instance cannot be confused with new traffic. 5 Messages and State Machines 5.1 The Twenty-One Message Types MPAC v0.1.13 defines 21 message types organized by layer. We list them here grouped by purpose; each has a dedicated JSON Schema and an if/then conditional constraint in the envelope schema. Session messages.HELLOis always the first message from a participant; the coordinator responds withSESSION_INFOdeclaring execution model, security profile, and the participantâs granted roles.HEARTBEATmaintains liveness.GOODBYElets a participant cleanly leave a session and declare how its remaining active intents should be handled (withdraw,transfer, orexpire). SESSION_CLOSEterminates a session and includes a summary record per Section 9.6.2 of the spec- ification.COORDINATOR_STATUScarries coordinator-originated notifications such as pre-commit authorizations, epoch changes, and health signals. Intent messages.INTENT_ANNOUNCEdeclares a planned objective, scope, priority, and TTL. INTENT_UPDATEmodifies an active intentâfor example, widening scope mid-plan, which may trigger new conflict detection.INTENT_WITHDRAWcancels an intent voluntarily.INTENT_CLAIM allows a surviving agent to take over another agentâs suspended intent after a liveness timeout, subject to governance approval; INTENT_CLAIM_STATUS carries the approval or denial. Operation messages.OP_PROPOSErequests authorization in pre-commit mode.OP_COMMITde- clares an executed mutation withstate_ref_beforeandstate_ref_after.OP_REJECTis issued by the coordinator for validation failures, stale state refs, frozen-scope violations, or contested muta- tions.OP_SUPERSEDEdeclares that a later operation replaces an earlier one in a supersession chain. OP_BATCH_COMMITgroups multiple operations withall_or_nothingorbest_effortsemantics; failed all_or_nothing batches roll back all partially-registered operations. Conflict messages.CONFLICT_REPORTis a coordinator-originated structured conflict object. CONFLICT_ACKis how participants stake a position: itsack_typeis one ofseen,accepted, ordisputed.CONFLICT_ESCALATEpromotes an unresolved conflict to a designated arbiter. RESOLUTIONdeclares a binding decision; the coordinator enforces that the sender has the authority to resolve at the conflictâs current authority phase (pre- or post-escalation), so that onlyowner, arbiter, or coordinator-generated outcomes can bind a resolution. Error message.PROTOCOL_ERRORis a lightweight message for signaling protocol-level problems that do not fit the conflict or operation-rejection categories: malformed payloads, invalid references, authorization failures, replay detection, stale state references, scope-frozen rejections, credential rejections, resolution timeouts, and state divergence between a participant and the coordinatorâs recovered snapshot. The coordinatorâs snapshot artifacts (including v0.1.13âs replay-protection checkpoints so duplicate-message rejection survives restarts) are a persistence feature, not a wire message type, and do not appear in the message vocabulary. 8 5.2 Three State Machines MPAC specifies three state machines with normative transition tables: Intent, Operation, and Conflict. Intent state machine. States:ACTIVE,SUSPENDED(owner liveness lost or departed with intent_disposition:transfer),TRANSFERRED,SUPERSEDED,WITHDRAWN,EXPIRED. TransitionsaredrivenbyINTENT_ANNOUNCE,INTENT_UPDATE,INTENT_WITHDRAW, INTENT_CLAIM_STATUS, liveness timeouts, and TTL expiry. A suspended intent transitions directly toTRANSFERREDupon an approvedINTENT_CLAIM_STATUS; there is no intermediate claimed state. The spec enumerates every legal transition; the reference implementations enforce them. Operation state machine.States:PROPOSED,COMMITTED,REJECTED,FROZEN(referenced intent suspended),ABANDONED(sender unavailable),SUPERSEDED. In post-commit mode, operations enter the system directly asCOMMITTEDorREJECTED. In pre-commit mode, they traversePROPOSEDâ COMMITTED, with coordinator authorization recorded as a flag withinPROPOSEDrather than as a distinct stateâauthorization alone does not transition the operation toCOMMITTED; only a subsequent OP_COMMITdeclaring the executed mutation does.OP_REJECTis possible at any point up to commit. Conflict state machine. States:OPEN,ACKED,ESCALATED,RESOLVED,CLOSED,DISMISSED. DISMISSEDcovers both explicit dismissal and auto-dismissal when all related intents and oper- ations have reached terminal states;CLOSEDis the post-resolution archival terminal state. Scope freezing is a separate concept: whenresolution_timeout_secelapses without aRESOLUTION, the affected scope enters a frozen state that blocks new mutations, but the underlying conflict itself remains inOPENorACKEDuntil resolved, auto-dismissed, or force-closed by the three-phase frozen- scope degradation sequence. Frozen scopes are enforced at the target level, not the intent level, so that omitting optional intent_id fields cannot be used to bypass the freeze. Cross-lifecycle rules, described as normative transition tables in Section 17 of the specification, govern how intent states interact with operation and conflict statesâfor example, withdrawing an intent automatically rejects any pending operations that referenced it (codeintent_terminated), and resolving a conflict unfreezes the associated scope. 6 Security, Authorization, and Governance 6.1 Three Security Profiles MPAC defines three security profiles with progressively stronger guarantees. ⢠Open. No credential required on HELLO. Suitable for intra-team sandboxes and testing. ⢠Authenticated.HELLOmust carry one of five credential types (bearer_token, mtls_fingerprint,api_key,x509_chain, orcustom). Replay protection is enforced: du- plicatemessage_idvalues are rejected withREPLAY_DETECTED, and timestamps outside the replay window (recommended: 5 minutes) are rejected. Replay-protection state is persisted in the coordinatorâs periodic state snapshot so that rejection survives coordinator recovery. â˘Verified. In addition to authenticated-profile guarantees, credentials must be verifiable against an issuer; self-asserted arbiter roles are rejected. 6.2 Role Policy Evaluation When a participant sendsHELLOwith a set of requested roles, the coordinator evaluates them against the sessionâs role policy (Section 23.1.5). Only authorized roles are granted; unauthorized roles are silently dropped, and a session with no policy declared cannot grant any role beyond the default contributor. This prevents a common category of bug in early drafts where an adversary could self-declare itself arbiter and use that role to rubber-stamp its own resolutions. 9 Table 2: Reference implementation scale and test coverage as of v0.1.13. ImplementationSource LOCTest filesTest cases Pythonâź3,50012122 (including 34 adversarial) TypeScriptâź2,90011101 (including 32 adversarial) 6.3 Resolution Authority Enforcement The specification requires that only owners or arbiters may resolve conflicts before escalation, and only the designated escalation target or an arbiter may resolve after escalation. The reference implementations enforce this at the coordinator:RESOLUTIONmessages from principals without resolution authority are rejected with an explicit error code. This is not advisoryâit is a runtime check, backed by adversarial tests that specifically try to bypass it. 6.4 Frozen-Scope Enforcement Once a conflictâsresolution_timeout_secelapses without a resolution, the overlapping scope is frozen. Any subsequentOP_COMMITorOP_BATCH_COMMITwhose target set intersects the frozen scope is rejected withSCOPE_FROZEN. New intents that are fully contained within a frozen scope are rejected at announcement time; intents that only partially overlap are accepted with a warning. This check is target-basedâit does not rely on the intentâsintent_idfield being presentâso the freeze cannot be bypassed by omitting optional fields, a bypass we explicitly test against in the adversarial suite. 6.5 Backend Health Monitoring Version 0.1.13 adds backend health monitoring primitives for production deployments. Coordinators expose liveness and readiness signals viaCOORDINATOR_STATUS; participants can query them to decide whether to enter degraded mode. Snapshot recovery replays the audit log after loading the latest snapshot, bumpscoordinator_epoch, and republishes the new epoch to all reconnecting participants so that stale messages from the prior epoch are rejected. 7 Reference Implementations 7.1 Two Independent Implementations, One Wire Format We release two reference implementationsâone in Python and one in TypeScriptâwritten indepen- dently against the specification. They are not two bindings of the same core; they are two separate implementations that must agree only on the wire. This is deliberate: having two independent implementations forces specification bugs, under-specified behavior, and hidden assumptions out into the open. 7.2 Cross-Language Interoperability A dedicated interoperability harness (ref-impl/demo/run_interop.sh) exchanges 14 messages bidirectionally between the Python and TypeScript implementations: Python as coordinator with TypeScript as participant, and vice versa. The harness asserts byte-identical wire formats after normalization; it has zero deviation at v0.1.13. This is the strongest practical evidence that the specification is complete and unambiguous. 7.3 Adversarial Testing Sixty-six adversarial tests (34 Python, 32 TypeScript) specifically target enforcement bypass attempts. These were written in response to actual findings from five rounds of independent audit on earlier versions. Categories include: ⢠Unregistered sender attacks. Sending any non-HELLO message before HELLO is rejected. 10 Table 3: Seven distributed validation scenarios. Together they exercise all 21 message types under real Claude agent decision-making over a WebSocket transport binding. ScenarioAgentsKey protocol features exercised Concurrent code editing2 INTENT_ANNOUNCE,scope-overlap CONFLICT_REPORT, optimistic concurrency control viastate_ref_before,STALE_STATE_REF rejection and rebase Family trip planning3 task_setscope overlap on itinerary days and bud- get categories, natural-languageCONFLICT_ACKne- gotiation, atomic OP_BATCH_COMMIT Overhead comparison3Back-to-back Traditional vs MPAC runs on the same workload with per-segment timing Pre-commit + fault recovery3 OP_PROPOSE âauthorizationâ OP_COMMIT, INTENT_UPDATE,INTENT_WITHDRAW+ OP_REJECT, agent crashâliveness timeout â INTENT_CLAIM with governance approval Conflict escalation to arbiter3DisputedCONFLICT_ACK,CONFLICT_ESCALATE, Claude-powered arbiterRESOLUTION, multi-level governance authority chain Interactiveremote(pip- packaged) 2+ Two humans on different machines each give tasks to a local agent; coordinator runs on one side, Web- Socket over LAN or ngrok Cross-language interop2Python and TypeScript exchange 14 messages bidi- rectionally with zero wire deviation ⢠Credential bypass. Authenticated/verified profiles reject HELLO without valid credentials. ⢠Self-asserted arbiter. Requesting thearbiterrole when the session policy does not grant it is silently downgraded to the default role. ⢠Unauthorized resolver.RESOLUTIONmessages from principals without resolution authority at the current phase are rejected. ⢠Frozen-scope evasion via omittedintent_id. Operations targeting a frozen scope are rejected even when the omitted optional field might otherwise bypass a naive check. â˘Snapshot recovery replay gap. Replay protection state survives coordinator recovery via snapshot persistence. â˘Partial-overlap intent acceptance. New intents that partially overlap a frozen scope are accepted with a warning; fully contained ones are rejected. â˘Batch atomicity rollback. Failedall_or_nothingbatches clean up all already-registered operations before returning the rejection. 7.4 JSON Schema Conformance Closure All 21 message types have dedicated JSON Schema (Draft 2020-12) payload definitions in ref-impl/schema/messages/. The envelope schema inenvelope.schema.jsonusesif/then conditional constraints to dispatch payload validation permessage_type. A third-party implemen- tation can now achieve wire compatibility by JSON Schema validation aloneâno prose reading required. Four shared object schemas (Watermark,Scope,Basis,Outcome) are used across multi- ple message payloads. 8 Empirical Validation We validate MPAC through seven live multi-agent scenarios driven by the Anthropic Claude API [1]. Every scenario exercises real LLM decision-making; none uses mocked agents. All seven run over a WebSocket transport binding and together cover all 21 message types. 11 8.1 Scenario Overview Rather than reporting all seven in detail, we focus the remainder of this section on the three that carry the strongest empirical weight: the code-editing end-to-end run, the family-trip run (for domain generality), and the overhead comparison benchmark (for the performance claim). 8.2 Code Editing with Optimistic Concurrency Control Two Claude agentsâAlice (security engineer persona) and Bob (code quality engineer persona)âjoin a WebSocket coordinator that holds a Flask web application with five Python files containing inten- tional bugs: a token expiry bug inauth.py, N+1 queries inmodels.py, authentication duplication betweenauth.pyandauth_middleware.py, an unvalidated-input vulnerability inapi.py, and an unclosed file handle in utils.py. Each agent independently calls Claude to decide what to work on. Alice picks the token expiry bug in auth.pyandauth_middleware.py. Bob picks the duplication refactor, which touchesauth.py, auth_middleware.py, andmodels.py. Both announce their intents. The coordinator detects that the intents overlap onauth.pyandauth_middleware.pyand emits aCONFLICT_REPORTwith category scope_overlap and severity medium. Both agents are asked, via independent Claude calls with no shared prompt or hardcoded priority, how to handle the conflict. Aliceâs position: âThis is a critical security vulnerability; I should proceed first and Bob can rebase his refactor onto my changes.â Bobâs position: âAliceâs security fix is urgent; my refactor can wait; let her go first.â Two independent LLM calls reach the same conclusion through the protocolâs structured conflict channel. The conflict is resolved. Alice commits her fix viaOP_COMMIT; Bob rebases on her committed state_ref_after and commits his refactor. This scenario also exercisesSTALE_STATE_REFrejection: when Bobâs initial commit attempt car- ries the original file hashes, the coordinator detects that Alice has since committed and returns STALE_STATE_REF. Bob fetches the new content, re-runs his refactor on top, and retries. The total message count for the full lifecycleâjoin, intent, conflict, resolution, two commits, session closeâis modest (around 10â15 messages per agent in typical runs), and a full transcript is shipped with the repository as ai_demo_transcript.json. The point of this scenario is not that âagents can resolve conflicts politely.â It is that the structured, auditable path for them to do so is now a wire protocol, not ad-hoc prompting. A future agent with a different personality, a different LLM backend, or even a different organization can plug into the same coordinator and interoperate, because the semantics are in the protocol. 8.3 Cross-Domain Generality: Family Trip Planning To argue that MPAC is a general coordination abstraction and not a code-editing framework in disguise, we run a second scenario that shares zero code with the first and lives in an entirely different domain: consumer trip planning. Three Claude agents serve Dad, Mom, and Kid respectively, each with a distinct system prompt describing that family memberâs preferences, budget sensitivity, and authority level. They jointly plan a 5-day family trip. The shared state is an itinerary: five day-slots and several budget categories (lodging, food, activities, transport). Itinerary days and budget categories are modeled astask_set scope resources. Agents announce intents such as âDad: reserve Day 2 and Day 3 for camping, lodging category ~$0, activities category $50 for gear rental.â Momâs intent overlaps on Day 2 (âboutique minsu, lodging $220â). The coordinator detects the scope overlap and emits a conflict report. Agents negoti- ate through structuredCONFLICT_ACKmessages that carry natural-language justifications (âKidâs opinion: we camped last year, Iâd like one fancy nightâ). A compromise emerges: Day 2 becomes boutique minsu, Day 3 stays camping. The itinerary is committed atomically viaOP_BATCH_COMMIT with all_or_nothing semantics so that partial itineraries cannot be published. The protocol primitives are unchanged from the code-editing scenario. Only the domain model (what counts as a âresource,â what counts as an âobjectiveâ) differs. This is the minimum evidence for the claim that MPAC is a coordination layer, not a software-development tool. 12 Table 4:Overhead comparison on a 3-agent cross-module PR review. Wall-clock time is the externally observed elapsed real time from session start to the last commit; decision time is the cumulative time agents spend waiting on Claude API responses; coordination overhead is the cumulative time agents spend blocked on serialization, round-trips, or post-hoc rework. In Traditional mode wall-clock equals decision + overhead because the three agents are serialized (63.11 + 68.65 = 131.76 s); in MPAC mode wall-clock is much smaller than decision + overhead because the agents run in parallel and wall-clock is bounded by the slowest single agent rather than by the sum across agents (27.38 s vs. 57.13 + 3.02 = 60.15 s of cumulative work). One controlled run; see Section 10 for discussion of statistical scope. MetricTraditionalMPACChange Wall-clock time (s)131.7627.38 â79.2% (4.8Ă speedup) Decision time (s)63.1157.13 â9.5% (preserved) Coordination overhead (s)68.653.02â95.6% Overhead as % of wall-clock52.1%11.0%â41.1 p 8.4 Overhead Comparison Benchmark The third scenario is the one most directly relevant to the performance claim in the abstract. We designed it to answer a specific question: does MPAC actually make multi-agent coordination faster, or does it just move the same latency around? Setup. Three Claude agentsâAlice, Bob, and Charlieâreview a cross-module pull request that touches three modules with known interactions. Each agent is responsible for reviewing its own module but must coordinate with the others because the modules have cross-cutting concerns. We run the exact same scenario twice, back-to-back, using the same Claude model (claude-sonnet-4) and the same prompts: 1. Traditional mode (baseline). Agents review serially, human-mediated: each one waits for the previous oneâs output, clarification questions cause round-trip delays, and conflicts are discovered and resolved after the work is done (post-hoc rework). 2.MPAC mode. Agents review in parallel over a WebSocket coordinator.INTENT_ANNOUNCE surfaces scope overlaps before any review work begins; structuredCONFLICT_ACKlets agents exchange positions without human mediation; commits proceed in parallel. Every segment of every run is timed with per-segment wall-clock instrumentation and classified as either decision time (the agent is actively thinking, i.e., waiting on a Claude API response) or coordination overhead (the agent is blocked waiting for another agent, a round-trip, or post-hoc rework). Results. Table 4 shows the results of a single controlled run. Interpretation. Two observations matter here, and they matter independently. First, coordination overhead drops from 68.65 s to 3.02 sâa 95.6% reduction, or absolute savings of 65.6 s. This is the effect of replacing serialized human-mediated coordination with protocol-level intent broadcast, pre-emptive conflict detection, and structured parallel negotiation. It is the core performance claim of the paper, and it is exactly the kind of saving a coordination protocol should produce. Second, and equally important, per-agent decision time is roughly preserved (63.11 sâ57.13 s, a 9.5% change, most of which is within run-to-run LLM variance). This is the load-bearing methodological point. A trivial âoptimizationâ could have come from cutting prompts shorter or skipping review steps, which would have shown up as reduced decision time. The fact that decision time is essentially unchanged is the strongest evidence that MPAC is not compressing the work; it is eliminating the waiting. We argue that this is exactly the right factorization for a coordination protocol: the decision time is whatever the underlying model and task demand, and the protocolâs job is to drive the coordination overhead toward zero. 13 Third, the end-to-end wall-clock speedup is 4.8Ă. For a cluster of agents running atO(10)seconds per decision, reducing the coordination overhead is the difference between a flow that finishes in under half a minute and one that drags past two minutes. We are deliberately conservative about generalizing from a single run; Section 10 discusses the statistical scope of this result. 8.5 Additional Scenarios Three further scenarios round out coverage of the protocol surface. The pre-commit + fault recovery scenario exercises the pre-commit execution model:OP_PROPOSEâcoordinator authorizationâ OP_COMMIT. It also simulates an agent crash: one agent becomes unresponsive, liveness tracking flags it, its in-flight intents are suspended, and a surviving agent successfully claims the suspended work viaINTENT_CLAIMwith governance approval. The escalation scenario exercises multi-level governance: two owner agents dispute a scope overlap, both mark their positions as âdisputed,â one escalates to a designated arbiter, and the arbiter (a third Claude agent with an explicit judicial system prompt) issues a bindingRESOLUTION. Finally, the remote pip-packaged scenario validates cross-host deployment: two users on different machines, each running a local Claude agent, join a shared coordinator over WebSocket (LAN or ngrok) and see real-time notifications when the other agent commits. Together with the cross-language interop test, these seven scenarios cover all 21 message types at least once under live LLM decision-makingâgiving the protocol, the schemas, and the reference implementations end-to-end empirical support. 9 Related Work Agent protocols. MCP [2] standardizes agent-to-tool interaction; A2A [7] standardizes single- principal agent-to-agent delegation. MPAC is complementary: it addresses multi-principal coordina- tion, which neither protocol targets. A comparison framework for agent communication protocols appears in [4], which explicitly identifies multi-principal coordination as an open gap. Multi-agent frameworks. LangGraph [10], AutoGen [14], CrewAI [3], and similar frameworks provide in-process composition of agents. They are libraries, not wire protocols, and do not define cross-framework interoperability. MPAC could serve as the wire format beneath any of them. Distributed systems antecedents.MPACâs causal watermark design draws directly from Lamportâs logical clocks [8] and the single-leader replication pattern familiar from consensus protocols such as Paxos [9] and Raft [11]. Unlike these, MPAC does not solve consensus under Byzantine or arbitrary failuresâit assumes a well-behaved coordinator and is instead focused on semantic-layer coordination (intent, conflict, governance) above a reliable message-passing substrate. CRDTs [12] and OT [5] handle concurrent edits to shared data structures; MPAC addresses coordination around shared state and can sit alongside a CRDT-backed store without modification. Classical multi-agent systems and argumentation. The broader multi-agent systems literature [13] includes decades of work on agent communication languages (KQML, FIPA-ACL [6]), ar- gumentation frameworks, contract nets, and negotiation protocols. MPAC borrows conceptual elementsâespecially the insistence that âdisagreementâ should be a first-class objectâbut targets the narrower and more concrete problem of coordinating present-day LLM agents over shared mutable state, with machine-enforceable wire semantics and two independent reference implementations. Version control and collaborative editing.Git, Mercurial, and collaborative editing systems such as Google Docs solve related problems for human users: they make concurrent edits to shared state manageable through merge semantics or OT. MPAC differs in that its participants are autonomous agents whose decisions must be pre-announced (so that overlap detection is pre-emptive rather than post-hoc) and attributed (so that multi-principal audit is possible). A human using Git does not need to announce their intent to edit a file; an autonomous agent acting on behalf of one principal among many should. 14 10 Limitations and Threats to Validity We are deliberately explicit about the limitations of this work, because honesty about what has and has not been demonstrated is the right posture for a draft protocol. Single-run benchmark. The overhead comparison in Table 4 reports a single controlled run of a single 3-agent workload. The magnitudes we reportâ95.6%overhead reduction,4.8Ăwall-clock speedupâare not asymptotic claims. They are an existence demonstration that the overhead delta is large and specific enough to be worth reporting, against a controlled baseline on the same prompts and model. A proper benchmark study would vary agent count, task difficulty, per-decision Claude latency, and conflict density; we plan to publish such a study as follow-up work. We encourage readers to treat the present numbers as calibration, not as a performance curve. Coordinator is a single point of failure. The reference implementations use a single coordinator process. Coordinator epoch fencing (Section 8.1.1.4 of the specification) is implemented and gives the protocol a basis for future multi-coordinator handover, and snapshot-based fault recovery is implemented and tested, but split-brain detection across concurrent coordinator instances is not yet exercised. A full multi-coordinator handover storyâwith cross-instance fencing and livenessâ remains future work. No formal verification.The three state machines have normative transition tables in the specifica- tion and are exercised by adversarial tests in both implementations, but they have not been formally verified (e.g., in TLA+). We are particularly interested in cross-lifecycle interactions between Intent, Operation, and Conflict state machines, where edge cases are most likely to hide. No head-to-head comparison with frameworks. We do not directly compare MPAC against LangGraph-, AutoGen-, or CrewAI-based multi-agent implementations of the same workloads. This is partly philosophicalâMPAC is a protocol, not a framework, and a fair comparison would require building a protocol-free baseline of comparable engineering maturityâand partly practical, because such a comparison is a substantial study in its own right. We flag this as important follow-up work. Byzantine assumptions. The current specification assumes that the coordinator is well-behaved (crash-stop, not Byzantine) and that participants follow the protocol unless they are explicitly testing enforcement. A fully multi-principal adversarial settingâwhere one participant is actively trying to lie about state, forge causality, or evade authority checksâis partially addressed by the verified security profile and adversarial tests, but a rigorous threat model is future work. Signature verification and trust binding across organizational boundaries remain gaps. Scope detection is coordinator-local.The current coordinator detects scope overlaps by intersect- ing declared resource sets. Richer semanticsâe.g., âAliceâs refactor will eventually touch all callers of this functionâârequire richer scope languages thanfile_setandtask_set. The specificationâs Scopeobject is extensible for this purpose, but we have not yet validated richer scope kinds in the reference implementations. LLM variance. All seven validation scenarios use the Claude API for agent decisions. LLMs are stochastic, and individual runs vary. Our protocol-level claimsâmessage types, state machines, conflict structureâdo not depend on LLM determinism, but the narrative quality of the negotiation transcripts (âagents reached the same conclusion independentlyâ) does. We are not claiming that every run produces the same negotiation path; we are claiming that the protocol provides the structured channel through which any negotiation path, deterministic or not, becomes auditable. 11 Discussion and Future Work Where MPAC sits in the stack.If MCP is the âtransport layerâ of agent-tool interaction and A2A is a âsingle-principal orchestration layer,â MPAC is a âmulti-principal coordination layerâ that sits above both and beside neither. An agent in a realistic future deployment will likely use MCP to call tools, A2A to delegate to its own sub-agents, and MPAC to coordinate with agents belonging to other principalsâall three at once, at different layers of the same stack. 15 From v0.1 to v0.2. The roadmap for v0.2.0 includes richer scope expressiveness, post-commit rollback semantics, cross-session coordination, a compact binary envelope, and scope-based sub- scription (so that participants need not receive every message). These additions are evolution, not redesignâthe five-layer model and 21-message vocabulary have stabilized across thirteen revision rounds, and further audit feedback will inform incremental changes rather than structural ones. Conformance harness.A next priority is an automated conformance test suite that any third-party implementation can run against its own wire output. The JSON Schema conformance closure in v0.1.13 is the foundation; the harness would add a standard set of interop traces (e.g., the 14-message interop test generalized to cover every message type) plus negative test cases for the adversarial categories in Section 7. Formal verification. TLA+ modeling of the three state machines, especially the cross-lifecycle interactions, is the next step we expect to produce the highest marginal confidence. Early versions of the specification contained silent cross-lifecycle bugs that took multiple audit rounds to surface; formal modeling would catch the next such class of bugs before they reach the reference implementations. Adoption path. We are not asking readers to adopt MPAC in production today. We are asking them to read the specification, try the reference implementations, run the seven demos, and tell us where the design is wrong. The protocol is in a draft state specifically so that feedback from external implementers can still reshape it. An open specification with two reference implementations and seven live demos is our best attempt to lower the cost of that feedback. 12 Conclusion MPAC is a protocol-layer answer to a concrete question: when agents serving different principals need to work together, how should they coordinate? The question is not answered by MCP (wrong layer) or A2A (wrong principal model), and it is not answered well by layering message queues, locks, or in-process frameworks on top of those protocols. MPACâs answer is a five-layer modelâSession, Intent, Operation, Conflict, Governanceâwith 21 message types, three state machines, Lamport-clock causality, two execution models, three security profiles, and machine-enforceable conformance via JSON Schema. We release two fully interoperable reference implementations, 223 tests including 66 adversarial tests, seven live Claude-driven multi-agent demos covering all 21 message types, and a controlled benchmark showing that structured pre-announcement of intent eliminates 95.6% of coordination overhead and produces a 4.8Ăwall-clock speedup on a 3-agent cross-module code-review taskâ while preserving per-agent decision time. The specification, implementations, schemas, and demo transcripts are open source. We invite the multi-agent systems communityâboth researchers and practitioners building on MCP, A2A, and adjacent protocolsâto read, break, and improve the design. Code and artifacts.The full protocol specification (SPEC.md), developer reference, JSON Schema suite, Python and TypeScript reference implementations, distributed demo transcripts, and version history are released in the project repository. The pip-installablempac_protocolpackage and thempac-starter-kitarchive let two users on different machines run collaborative multi-agent sessions with a single command per side. References [1] Anthropic. Claude: A family of large language models.https://w.anthropic.com/ claude, 2024. [2] Anthropic. Model context protocol.https://modelcontextprotocol.io/, 2024. Open standard for connecting AI assistants to external data sources and tools. [3] CrewAI. Crewai: Framework for orchestrating role-playing, autonomous ai agents.https: //github.com/crewAIInc/crewAI, 2024. 16 [4]Abul Ehtesham, Aditi Singh, and Saket Kumar. A survey of agent interoperability protocols: Model context protocol (mcp), agent communication protocol (acp), agent-to-agent protocol (a2a), and agent network protocol (anp). arXiv preprint arXiv:2505.02279, 2025. [5]Clarence A. Ellis and Simon J. Gibbs. Concurrency control in groupware systems. In ACM SIGMOD International Conference on Management of Data, pages 399â407, 1989. [6]Foundation for Intelligent Physical Agents. Fipa acl message structure specification. Technical Report SC00061G, FIPA, 2002. [7]Google. Agent2agent (a2a) protocol.https://github.com/google-a2a/A2A, 2024. Open protocol for agent-to-agent task delegation. [8]Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communica- tions of the ACM, 21(7):558â565, 1978. [9]Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems, 16(2):133â 169, 1998. [10]LangChain. Langgraph: Building stateful, multi-actor applications with llms.https:// github.com/langchain-ai/langgraph, 2024. [11] Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference (USENIX ATC), pages 305â319, 2014. [12]Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. In Symposium on Self-Stabilizing Systems (S), pages 386â400, 2011. [13] Michael Wooldridge. An Introduction to MultiAgent Systems. Wiley, 2nd edition, 2009. [14]Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. Autogen: Enabling next-gen llm applications via multi-agent conversation. arXiv preprint arXiv:2308.08155, 2023. 17