Pact Negotiation Between Agents: The Protocol For When Two Agents Need A Shared Boundary

TL;DR

When agent A delegates work to agent B, the boundary between them is a contract neither's individual pact captures. They need a shared pact: a set of predicates that bind both for the duration of the delegation. Today, this contract is implicit, embedded in the agent's prompt or hard-coded in the orchestration logic. That fails when the delegation is dynamic, the counterparty is unknown at design time, or the boundary needs to be auditable later. This post defines the protocol for runtime pact negotiation: how agents propose terms, counter terms, ratify the shared pact, attest its existence to the trust layer, and dissolve it cleanly. Reader artifact: a Pact Negotiation Sequence Diagram — the canonical message-by-message flow that any two agents can implement to establish a shared boundary on demand.

Intro

The problem became unavoidable on a Tuesday afternoon when a customer's support agent dispatched a task to a third-party data-enrichment agent. The dispatch worked. The enrichment ran. The result came back. Then the customer's compliance team asked a simple question: "What contract governed the enrichment agent's behavior during that task?"

The answer was "none, exactly." The enrichment agent had its own pact, but it was generic — covering all its work, not the specific task. The support agent had its own pact, governing its own behavior, but not the enrichment agent's. The dispatch itself had been governed by the prompt the support agent constructed, which was free text, not auditable, not version-controlled, not enforceable. The boundary between the two agents — what data could be shared, what actions the enrichment agent was authorized to take, what the success criteria were, what would happen if something went wrong — existed only in the support agent's prompt at the moment of dispatch. The boundary did not survive the response. There was nothing to point at.

Multiply that by the thousands of agent-to-agent dispatches happening daily across modern multi-agent systems and you have an industry-wide governance gap. Every individual agent has a pact. Every dispatch creates a momentary collaboration that has no pact at all. The collaborations are where the work happens. The collaborations are where the risk concentrates. And the collaborations are governed by ad-hoc prompt instructions that no one reviews, no one audits, and no one can reconstruct.

The instinctive response is to embed every possible boundary into both agents' base pacts. The support agent's pact gets a clause about data sharing with downstream agents. The enrichment agent's pact gets a clause about acceptable input from upstream agents. This works for known, stable pairings — agents that always collaborate with the same partners on the same tasks. It fails for everything else: dynamic dispatches where the counterparty is unknown until runtime, multi-agent workflows where the boundaries differ by step, and cross-organizational collaborations where neither agent's owner knows the other's pact in advance.

The alternative is to make the boundary itself a first-class artifact: a shared pact, negotiated at runtime, ratified by both parties, attested to the trust layer, and held for the duration of the collaboration. The shared pact becomes the contract that compliance can point at, that the trust layer can score against, and that either agent can invoke if the other deviates. It is a small idea with substantial consequences for how multi-agent systems should be structured.

This post defines the protocol for runtime pact negotiation. We will walk through the negotiation flow, the message types, the conflict-resolution rules, the attestation mechanism, the dissolution semantics, and the failure modes. The output is a Pact Negotiation Sequence Diagram that captures the canonical flow in enough detail for two agents from different organizations to implement compatible negotiation without prior coordination.

Why Implicit Boundaries Fail

An implicit boundary — embedded in a prompt, encoded in orchestration code, assumed by convention — has three failure modes that compound as the system scales.

The first is irreproducibility. The boundary at the time of the collaboration is not preserved. When a question arises later about what was actually agreed, the original boundary cannot be reconstructed. The prompt that contained it is not stored. The orchestration code may have changed. The assumed convention may not have been the assumed convention at the time. The collaboration becomes a black box, and the only available answer is to look at what happened — which is exactly the wrong way around. The contract should explain the behavior, not be inferred from it.

The second is inconsistency. Different dispatches produce different implicit boundaries even when the work is identical. One support agent shares a particular data field; another does not. One enrichment agent treats a particular input as a hard constraint; another treats it as a hint. The variation is rarely intentional; it emerges from the cumulative drift of prompts, orchestration logic, and conventions across the system. The lack of explicit shared pacts produces a population of micro-contracts, no two alike, and the trust layer cannot reason coherently about a population of one-offs.

The third is exploitability. An agent without a shared pact has no recourse when the counterparty deviates. If the enrichment agent returns more data than the support agent expected, or accesses more upstream context than was offered, the support agent has no contract to point to. The trust layer has no basis to score the deviation as a violation. The collaboration's misalignment becomes a soft conflict that neither side can formally raise, and the misalignment compounds over many collaborations as both sides adjust to the other's actual behavior rather than to its declared intent.

These failure modes are not hypothetical. They appear in every multi-agent system once it scales past a handful of agents. They are the reason multi-agent governance is hard: not because agents are difficult to govern individually, but because the collaborations between them are nearly impossible to govern as a class. A protocol that turns each collaboration into a first-class governable artifact is the structural fix.

The Negotiation Has Five Phases

The pact negotiation protocol decomposes into five phases. Each phase has a specific purpose, a defined message vocabulary, and a clear transition to the next phase. The full negotiation can complete in a few hundred milliseconds for simple cases or extend into seconds for complex ones; the latency budget is set by the orchestrator and surfaced as a parameter of the negotiation.

Phase one is invocation. Agent A sends an Invocation message to Agent B announcing the desire to collaborate, the high-level task description, the latency budget for the negotiation itself, the maximum duration of the collaboration if established, and the list of pact-template references Agent A is offering to start from. The invocation does not yet commit either agent to anything; it opens a negotiation channel.

Phase two is proposal. Agent A sends a Proposal message that names the specific predicates it wants in the shared pact: data-sharing scope, action authorization scope, output format, success criteria, failure handling, dispute resolution, audit retention, and termination conditions. Each predicate is structured (using the same predicate vocabulary as the agents' base pacts) and identifiably tagged so it can be referenced in subsequent counter-proposals. Agent A's proposal is its opening position; it represents what Agent A would prefer the shared pact to look like.

Phase three is counter. Agent B reviews the proposal against its own constraints — its base pact's compatibility with the proposed predicates, its current operational state, its policy on the requested data-sharing and action scopes — and responds with a Counter message. The counter accepts some predicates as proposed, rejects some predicates outright, modifies some predicates with revised terms, and adds new predicates Agent B requires that were not in the original proposal. Counter messages can be issued by Agent A in response, leading to a back-and-forth that converges toward a mutually-acceptable set.

Phase four is ratification. Once the counter exchange converges (either both agents accept the current set, or one agent walks away), the agents jointly produce a Ratification message: a final, unchangeable record of the agreed predicates, signed by both agents, with a unique pact identifier and a validity window. The ratification is published to the trust layer as the canonical record of the shared pact. From this moment, the shared pact governs the collaboration; both agents are bound by it for the validity window.

Phase five is collaboration and dissolution. The actual work happens. Both agents operate within the shared pact's predicates. When the work completes — successfully, unsuccessfully, or due to the validity window expiring — a Dissolution message is issued by one or both agents, marking the shared pact as terminated. The trust layer scores both agents against the shared pact for the duration of the collaboration; the scores are recorded and contribute to each agent's reputation in the same way that base-pact scores do.

The five-phase structure is intentionally similar to OAuth's authorization flow and TLS's handshake. Both are negotiated establishment of a shared context between two parties, and both have proven robust at internet scale. The pact negotiation protocol borrows the structural lessons: explicit phases with defined transitions, structured messages with stable vocabulary, signed final artifacts, and clean dissolution semantics.

The Message Vocabulary

The protocol uses six message types, each with a defined schema and a defined role in the negotiation flow.

Invocation opens the negotiation. Fields: source agent identifier, target agent identifier, task summary, negotiation timeout, maximum collaboration duration, offered template references, and a unique negotiation identifier. The invocation is the only message that does not require a prior negotiation context; it bootstraps one.

Proposal carries a structured predicate set. Fields: negotiation identifier, predicate list, optional rationale text, and a deadline for response. Each predicate in the list has a stable identifier within the negotiation, a category (scope, action, output, success, failure, dispute, audit, termination), a structured body, and an optional rationale. The proposal is the first substantive position from one party; subsequent positions are counters.

Counter revises a proposal. Fields: negotiation identifier, predicate-by-predicate response (accept, reject, modify, or add), rationale per change, and a deadline for the next exchange. A counter is the negotiation's primary work; multiple counters typically flow before convergence. The protocol does not bound the number of counters, but the negotiation timeout from the invocation bounds the total wall-clock time.

Ratification finalizes the agreement. Fields: negotiation identifier, the final predicate set, both agents' signatures over the predicate set, a unique pact identifier (to be referenced for the duration of the collaboration), the validity window (start time, end time), and a checksum binding the predicates to the negotiation history. The ratification is the artifact published to the trust layer; everything before it is preliminary.

Dissolution terminates the agreement. Fields: pact identifier, dissolution reason (work completed, work failed, validity window expired, party withdrew, dispute escalated), termination timestamp, and any final artifacts (the work product, evaluation results, dispute claims). Dissolution closes the collaboration's governance window; subsequent activity is no longer covered by the shared pact.

Walkaway terminates the negotiation before ratification. Fields: negotiation identifier, walkaway reason, and rationale. A walkaway is a clean refusal — no shared pact is established, the collaboration does not happen, and both agents return to their independent state. Walkaway is preferable to ratifying a pact that one party cannot honor.

The messages are exchanged over a transport that the protocol does not prescribe. HTTP with structured bodies works. Message queues work. Direct LLM-to-LLM streams work for closely-coupled pairs. The protocol assumes the transport is reliable enough to deliver messages in order or to surface delivery failures cleanly; it does not assume the transport is encrypted, but encryption is recommended in practice.

The vocabulary is intentionally small. Six message types is enough to express the full negotiation flow, including all common variants. Adding more message types — heartbeats, status updates, partial commitments — tends to complicate the protocol without adding capability. Keeping the vocabulary small keeps implementations interoperable.

The Conflict-Resolution Rules

A proposal and counter exchange can converge or fail. The protocol's job is to make convergence the common case and to make failure clean. Three conflict-resolution rules govern the exchange.

The first rule is monotonic concession. A counter that accepts a previously-proposed predicate cannot un-accept it in a later counter. Once a predicate is accepted by both parties, it is locked. This prevents oscillation — a party offering a concession, watching the other party accept it, then withdrawing the concession to extract more. Monotonic concession ensures the negotiation makes progress.

The second rule is transparent rejection. A counter that rejects a predicate must include a rationale. The rationale is consumed by the proposing party's negotiation logic and recorded in the negotiation history. Rejections without rationale are protocol violations and trigger automatic walkaway. The rule prevents opaque negotiations where one party stonewalls without explanation, and it produces a record useful for post-hoc analysis when the negotiation fails.

The third rule is bounded iteration. A negotiation can have at most N counter exchanges, where N is set by the invocation's offered template or defaults to a protocol-wide cap (typically 8). Beyond N, the negotiation enters a forced-resolution mode where remaining unresolved predicates must be either accepted as the most recent proposal or trigger walkaway. The bound prevents infinite negotiation loops, which can occur when both parties have stable but incompatible positions.

The rules together produce negotiations that converge in two to four exchanges for the common case and walk away cleanly when convergence is impossible. The negotiation history — every message, every signature, every rationale — is preserved as part of the ratified pact's metadata, available to either party for later review.

A fourth rule, applied at the protocol's discretion, is escalation. If the agents cannot converge but both want to collaborate, they can escalate to a designated arbiter — typically a third agent or a human reviewer — who proposes a final predicate set. Both agents can accept the escalation outcome or walk away. Escalation is the safety valve for negotiations that involve genuinely difficult value disagreements; it should be rare in practice, because most negotiations involve straightforward parameter selection rather than fundamental conflict.

Predicate Categories: The Eight Domains Of A Shared Pact

The predicates in a shared pact span eight categories. Each category covers a distinct aspect of the collaboration, and together they form a complete governance surface.

Scope predicates define the boundaries of the collaboration: what data Agent A is offering Agent B, what data Agent B is permitted to read or store, what subjects of action the collaboration covers, and what is explicitly out of scope. Scope predicates are the most negotiated category because they directly touch privacy and authorization concerns.

Action predicates define what Agent B is authorized to do during the collaboration: which tools it can call, which external systems it can interact with, which side effects it can produce, and which actions require Agent A's explicit approval before execution. Action predicates protect Agent A from unintended consequences of the collaboration.

Output predicates define what Agent B will return to Agent A: the format, the schema, the maximum size, the citations or evidence required, the prohibited content, and the timing of delivery. Output predicates make the collaboration's deliverable predictable and verifiable.

Success predicates define what counts as a successful collaboration: the criteria the output must meet, the quality threshold, the acceptance test (if any), and how disagreement about success is resolved. Success predicates close the loop between the collaboration's intent and its outcome.

Failure predicates define what happens when the collaboration cannot succeed: how Agent B reports failure, what fallback behavior is acceptable, what compensation (if any) is owed, and how the failure is recorded. Failure predicates make graceful degradation an explicit contract rather than an ad-hoc improvisation.

Dispute predicates define how disagreements are resolved: which party can raise a dispute, what evidence must accompany the dispute, what the resolution timeline is, and which arbiter is invoked. Dispute predicates anticipate that even successful collaborations sometimes produce disagreements about whether they were actually successful.

Audit predicates define what is recorded for later review: the messages exchanged, the work product, the evaluation results, the retention period, and the access controls on the audit record. Audit predicates make the collaboration legible after it ends.

Termination predicates define how the collaboration ends: under what conditions either party can dissolve the pact early, what notice is required, what partial-result handling occurs, and what residual obligations persist after termination. Termination predicates prevent stranded states where neither party knows whether the collaboration is still active.

A fully-specified shared pact has at least one predicate in each of the eight categories, though categories with low concern (e.g., dispute predicates for low-stakes collaborations) may be satisfied by a default predicate from the offered template rather than a custom-negotiated one. The eight-category structure is what makes shared pacts coherent across negotiations: any two agents can compare their pacts on a per-category basis and reason about gaps or conflicts.

Templates: Avoiding Negotiation Through Pre-Agreement

Fully ad-hoc negotiation is expensive. Two agents proposing and countering eight predicate categories from scratch can take seconds and consume meaningful compute. Templates short-circuit the negotiation by providing pre-agreed starting points that the parties can either accept wholesale or modify selectively.

A template is a ratified-and-published predicate set with a stable identifier and a versioned semantics. Templates are typically published by platform operators, industry consortia, or large counterparties; they capture the canonical shared pacts for common collaboration patterns. "Customer support agent dispatching to data-enrichment agent on tier-1 customer data" is a typical template. So is "research agent dispatching to a web-fetching agent on public data," or "trading agent dispatching to a market-data agent during regular hours."

The invocation message includes one or more offered template references. The receiving agent can accept a template wholesale (skipping to ratification with the template as the predicate set), accept a template as the starting point for further negotiation (the template's predicates become the initial proposal), or reject all offered templates and require the negotiating party to propose from scratch.

Templates have substantial efficiency benefits. A common-case dispatch can ratify in a single round-trip when both agents already trust the template. Templates also have substantial governance benefits: a template that has been reviewed by both organizations' legal and security teams can be the standing answer for an entire class of collaborations, eliminating the need to re-negotiate identical terms over and over.

The risk of templates is that they encourage carelessness. An agent that accepts every offered template without inspection becomes a vehicle for whatever predicates the proposing party prefers. The discipline is that template acceptance should be an explicit, audited decision — not a default behavior — and that the templates an agent will accept should be enumerated in the agent's base pact. "This agent will accept templates X, Y, and Z without modification; it will negotiate from any other template; it will refuse all unrecognized templates." The base pact's template policy is the upstream governance of the shared pact's contents.

Templates evolve. Like base pacts, they are versioned. A template that updates from version 2.1 to 2.2 affects only future negotiations, not collaborations already established under 2.1. Counterparties can pin to specific template versions, the same way pact consumers can pin to specific pact versions. The template registry is itself a trust artifact, and its governance follows the same pact-as-code practices that govern individual pacts.

Attestation: Why The Trust Layer Must See The Shared Pact

A shared pact that is private to the two negotiating agents has the same problem as the implicit boundary: it cannot be audited externally, it does not contribute to the agents' reputations, and it cannot be the basis for dispute resolution. The protocol requires that the ratification message be published to the trust layer as a public attestation.

The attestation includes the pact identifier, the participant identifiers, the validity window, the predicate set (or a hash of it for confidentiality), and both signatures. The trust layer records the attestation and exposes it for query. Counterparties of either agent can verify that the shared pact existed, retrieve its terms (subject to confidentiality permissions), and check both parties' compliance during the collaboration.

The attestation also enables the trust layer to score the collaboration. Each party's behavior during the validity window is evaluated against the shared pact's predicates, and the resulting compliance contributes to each party's composite score in the same way that base-pact compliance does. A pattern of well-honored shared pacts strengthens an agent's reputation; a pattern of violated shared pacts weakens it. The collaboration becomes a first-class scored event, not an opaque interaction outside the scoring system.

Confidentiality is handled at the predicate level. Some predicates may be public (the validity window, the participants, the high-level task category); others may be private (the specific data fields shared, the action authorizations granted). Private predicates are attested as hashes; the trust layer can verify the predicates' existence and structure without seeing the contents, and the parties can produce the contents under their own access controls if a dispute requires it.

The attestation latency is negligible — the publication is a single API call after ratification — and the storage cost is bounded by the validity window plus the audit retention period defined in the pact. For ephemeral collaborations (a few minutes), the storage footprint is small. For long-running collaborations (days or weeks), the storage scales with the duration; the audit predicates govern how much is retained beyond the collaboration's end.

Without attestation, the protocol degenerates into private agreement that no third party can verify. With attestation, the protocol produces a public record that supports the trust layer's full governance machinery. Attestation is what makes shared pacts a feature of the agent economy rather than a feature of two specific agents.

Dissolution: How Collaborations End Cleanly

Most discussion of pact negotiation focuses on establishment. Dissolution gets less attention and matters at least as much. A shared pact that does not dissolve cleanly leaves both parties in an ambiguous state, and ambiguous states accumulate into governance debt.

The protocol defines five dissolution conditions, each of which produces a distinct dissolution message.

Successful completion. The work was performed, the success predicates are satisfied, and both parties acknowledge the outcome. The dissolution message includes the work product (or a reference to it), the satisfied success criteria, and any final scoring inputs. This is the common case; clean success dissolution is what most collaborations should aim for.

Unsuccessful completion. The work was attempted, the success predicates are not satisfied, but the failure predicates govern the outcome (a graceful failure with the agreed compensation or fallback). The dissolution message includes the failure mode, the failure predicate that was invoked, and any compensation transferred. Unsuccessful completion is still clean — the failure was anticipated by the pact and handled by it.

Validity window expiration. The collaboration's allowed duration elapsed before completion. The dissolution message marks the pact as expired, captures any partial work, and triggers any termination predicates that govern partial-result handling. Expiration is a design failure of the pact's duration estimate, not necessarily a failure of either agent.

Party withdrawal. One party invokes the termination predicates to dissolve early, with the required notice and the agreed handling of in-flight work. The dissolution message includes the withdrawal reason and the residual obligations. Withdrawal is a contractual right governed by the pact, not an arbitrary action.

Dispute escalation. A disagreement between the parties cannot be resolved within the pact's dispute predicates and is escalated to an external arbiter. The dissolution message marks the pact as in-dispute, captures the disputed claims, and references the escalation. The pact's binding force on both parties suspends pending the arbiter's resolution.

Each dissolution condition produces a distinct trust-layer record. The trust layer's scoring engine reads the dissolution type as part of the collaboration's metadata; a pattern of clean successful dissolutions improves an agent's reputation more than a pattern of withdrawals or disputes, even if the proximate metrics are similar. Dissolution mode is itself a scored signal.

Ambiguous dissolution — collaborations that simply stop without a dissolution message — should be impossible by protocol design. The orchestrator monitors active collaborations and, if either party becomes unreachable, issues a dissolution-by-timeout message after the collaboration's validity window expires. The timeout dissolution is recorded as a clean termination of the pact, even if the underlying work was abandoned. The trust layer scores the abandonment against the responsible party.

Failure Modes: When Negotiation Itself Goes Wrong

The protocol assumes both parties are negotiating in good faith. In practice, failures occur. The protocol must handle them without leaving either party in a vulnerable state.

The first failure mode is unresponsive counterparty. The proposing agent sends an invocation, and no response arrives within the negotiation timeout. The protocol's resolution is automatic walkaway — the proposing agent treats the absence of response as a refusal, logs the failed negotiation, and proceeds with whatever fallback the agent's base pact prescribes (typically returning a graceful failure to its own caller).

The second failure mode is hostile counterparty. The responding agent sends counter messages designed to extract concessions without intending to ratify, or proposes predicates that are themselves harmful (overly broad data access, escalation paths that grant unwarranted authority). The protocol's resolution is the proposing agent's walkaway, plus a trust-layer report of the bad-faith negotiation. Repeated bad-faith negotiations damage the responding agent's reputation through the same scoring mechanism that scores collaborations.

The third failure mode is incompatible pacts. Both parties are negotiating in good faith, but their base pacts have constraints that prevent any mutually-acceptable shared pact. The protocol's resolution is walkaway with a structured incompatibility report. The report identifies which base-pact constraints conflicted and is useful both for retroactive analysis and for informing future template development.

The fourth failure mode is template mismatch. The proposing agent offers templates the responding agent does not recognize or trust. The protocol's resolution is the responding agent rejecting the templates and requiring fresh proposal, or walking away if its policy disallows ad-hoc negotiation. Template mismatch is common in cross-organizational collaborations and motivates the development of widely-shared template registries.

The fifth failure mode is post-ratification deviation. The shared pact was ratified, but one party's behavior during the collaboration violates the pact's predicates. The protocol's resolution depends on the violated predicate's category: scope violations may trigger immediate dissolution, output violations may trigger dispute escalation, success violations may trigger renegotiation. The trust layer records the deviation and scores it against the responsible party.

Failure modes are not bugs in the protocol; they are foreseen behaviors that the protocol handles gracefully. The protocol's robustness is measured by how cleanly it handles failures, not by how rarely they occur. A protocol that fails gracefully under all five modes is robust enough for production multi-agent systems.

The Reader Artifact: The Pact Negotiation Sequence Diagram

The artifact this post produces is a Pact Negotiation Sequence Diagram — the canonical message flow that any two agents can implement to establish a shared boundary. The diagram is structured as a UML-style sequence diagram with two participants (Agent A and Agent B), the trust layer as a third participant for attestation, and an optional arbiter as a fourth for escalation.

The diagram captures the five phases as discrete swim lanes, with messages flowing left to right and top to bottom. Each message is labeled with its type, its key fields, and any preconditions or postconditions. Branches in the flow (template accepted vs. negotiation continued, ratification vs. walkaway, successful vs. unsuccessful completion) are explicitly drawn, so an implementer can trace any path from invocation to dissolution without ambiguity.

The diagram is accompanied by a structured specification document covering the message schemas (in JSON Schema), the conflict-resolution rules, the predicate categories, the template format, the attestation API, and the failure-mode handling. The specification is approximately 30 pages and is intended to be implementable by a competent agent developer in two to four weeks.

The diagram and specification are deliberately tool-agnostic. They do not prescribe a transport (HTTP, gRPC, message queue, or in-process), an attestation backend (any trust layer that exposes a publish endpoint), or a template registry (any registry with versioned content). Implementations against different toolchains will produce different code, but they will be wire-compatible if they conform to the diagram and specification.

The diagram is the artifact two organizations need to agree on before their agents can negotiate. Once both organizations have implemented the diagram and registered with a shared trust layer, their agents can collaborate ad-hoc without prior bilateral agreement. The diagram is, in effect, the contract for the contract — the meta-agreement that lets first-party agreements form on demand.

Counter-Argument: Most Multi-Agent Systems Don't Need This

A reasonable objection is that most production multi-agent systems are tightly coupled within a single organization, with both agents' behavior known at design time. For those systems, the negotiation protocol is overkill; the boundaries are obvious, the trust is established, and the orchestration code can encode the contract directly.

The objection has merit. Internal, design-time-fixed collaborations do not need runtime negotiation. The protocol's value is concentrated in three scenarios: cross-organizational collaborations where neither party knows the other's pact in advance; dynamic dispatches where the counterparty is selected at runtime from a marketplace; and high-stakes collaborations where the audit trail of the negotiation is itself a governance requirement.

For those scenarios, the protocol is essential. For everything else, the protocol is optional but still beneficial as a structural discipline. Even within a single organization, formalizing the shared pact between two agents — using the eight predicate categories, ratifying the pact at start, attesting to the trust layer — produces an audit trail that simplifies later compliance work and a contract structure that simplifies later debugging. The cost is modest, the benefit is real, and the practice scales naturally as the system grows beyond a single organization.

The stronger version of the objection is that multi-agent collaboration is rare today and may remain rare. If most agent work is single-agent, the protocol governs a small fraction of the system's behavior. This is partly true today and unlikely to remain true. The trajectory of agent system design is toward composition — small, specialized agents collaborating in dynamic configurations — and the governance surface for those collaborations will be the dominant governance challenge of the next several years. Building the protocol now is timing-anticipatory, not retrospective.

What Armalo Does

Armalo's trust layer exposes an attestation endpoint specifically for ratified shared pacts. The endpoint accepts the ratification message, verifies both signatures against the participants' registered identities, records the attestation, and returns a pact identifier that both parties use for the duration of the collaboration. Subsequent dissolution and scoring messages reference the same identifier, producing a complete record of the collaboration's governance.

The pact registry includes a template registry as a first-class subsystem. Templates are versioned, signed by their authors, and discoverable via a search API that supports filtering by collaboration type, predicate category coverage, and trust profile. Agents can configure their template policy in their base pact, declaring which templates they will accept, which they will negotiate from, and which they will reject. The registry's templates are themselves governed by pact-as-code practices and evolve in lock-step with the collaboration patterns they support.

The twelve-dimensional composite score incorporates collaboration outcomes through the scope-honesty (7%) and reliability (13%) dimensions. An agent that consistently honors its shared pacts strengthens both dimensions; an agent that consistently violates them weakens them. The collaboration becomes part of the agent's reputation in the same way that base-pact compliance does, closing the loop between multi-agent governance and the economic accountability that the trust layer provides.

The Pact Negotiation Sequence Diagram is published as part of Armalo's open-source agent interoperability documentation. Reference implementations of the protocol — in TypeScript and Python — are available for integration into any agent framework. The implementations consume Armalo's attestation endpoint by default but can be configured against any compatible trust layer.

FAQ

Can a shared pact reference predicates from the agents' base pacts? Yes. A predicate in a shared pact can either be self-contained or can reference a predicate from one of the participants' base pacts. The reference is by predicate identifier and pact version. References reduce duplication and ensure the shared pact's terms align with the agent's general behavior.

What happens if one party's base pact changes during an active collaboration? The base pact change does not retroactively affect the shared pact. The shared pact's terms are fixed at ratification. If the base pact change creates a conflict with the shared pact, the affected party can invoke the dissolution-due-to-base-pact-change clause if it was negotiated, or escalate the conflict for arbiter resolution.

How is the negotiation latency budgeted in production? The invocation message includes a negotiation timeout. Typical budgets are 500 milliseconds for template-accepted negotiations, 2 seconds for single-round negotiations, and 5 seconds for multi-round negotiations. Beyond 5 seconds, the negotiation should be considered a design problem rather than a normal interaction.

Can three or more agents negotiate a shared pact? The protocol as specified handles two-party negotiations. Multi-party negotiation is addressable as a sequence of pairwise negotiations or as an extension to the protocol with a coordinator role. The two-party form is the foundational case; multi-party is reserved for future protocol versions.

Does the negotiation reveal information about each agent's base pact? Only what is offered or referenced in the proposal and counter messages. Predicates that the agent does not propose remain private. Sophisticated counterparties can infer base-pact constraints from the negotiation pattern, which is an unavoidable consequence of negotiating in the open. Confidentiality predicates can limit what the trust-layer attestation reveals further.

Can a ratified shared pact be amended? Not directly. Amendment requires a fresh negotiation that produces a new ratified pact, with the old pact dissolved by mutual agreement. The discipline of treating amendments as new pacts preserves the audit trail and prevents the kind of silent contract drift that the protocol was designed to eliminate.

Who pays for the trust-layer attestation cost? Either the proposing agent, the responding agent, or split per the negotiated terms. The pact can include a billing predicate that allocates the costs. Most platforms bear the cost as part of their trust-layer service; high-volume agents may negotiate split arrangements.

What if the agents are running on different trust layers? The negotiation can complete bilaterally even if the agents use different trust layers; each party attests to its own. Cross-trust-layer collaboration requires both layers to expose a verification API for the other's attestations. Federation between trust layers is an active area of standardization; the protocol is designed to be compatible with future federation but does not require it.

Bottom Line

When agent A delegates to agent B, the boundary between them is a contract that today has no home. It lives implicitly in prompts, orchestration code, and conventions, and it cannot be audited, scored, or enforced. The fix is to make the boundary a first-class artifact: a shared pact, negotiated at runtime through a defined five-phase protocol, ratified by both parties, attested to the trust layer, scored against during the collaboration, and dissolved cleanly at the end. The Pact Negotiation Sequence Diagram captures the protocol in implementable detail. The eight predicate categories cover the full governance surface of a collaboration. Templates short-circuit common cases without sacrificing rigor. Attestation closes the loop with the trust layer. Dissolution semantics ensure no collaboration ends ambiguously. The protocol is not necessary for tightly-coupled internal collaborations, but it is essential for cross-organizational, dynamic, and high-stakes ones — exactly the collaborations that will dominate the next phase of multi-agent system design. Building the protocol now is timing-appropriate, and adopting it produces governance infrastructure that scales naturally as agent ecosystems grow. The collaboration is where the work happens; the shared pact is what makes the work governable.