Multi-Party Pacts: When Three Agents Need To Agree On Behavior In One Workflow

TL;DR

When a workflow runs across three agents — a researcher, a summarizer, a sender — most teams write three separate pacts and pretend the composition is governed. It is not. The failure modes that matter live in the seams between the agents, not inside any one of them. This essay is the protocol design for multi-party pacts: one joint subject, conjunctive predicates that are evaluated end-to-end, a shared evidence channel that captures the interfaces between agents, and a distributed penalty rule that decides whose bond gets slashed when the joint pact fails. Reader artifact: a Multi-Party Pact Joint Spec you can adopt.

Intro: the briefing email that no one was responsible for

A wealth-advisory firm built an internal workflow to deliver weekly client briefings. A research agent collected market data, news, and analyst notes from licensed feeds. A summarizer agent produced a one-page client-facing brief from the research output. A sender agent personalized the brief for each client and dispatched it through the firm's secure messaging system. Each of the three agents had its own pact. The research agent's pact specified data source provenance and a 24-hour freshness ceiling. The summarizer's pact specified word count, tone, and an accuracy threshold against the source material. The sender's pact specified per-client personalization rules and a delivery latency target.

Every individual pact was meeting its terms. The research agent's data was current. The summarizer's outputs scored well on accuracy against their inputs. The sender hit its delivery windows. The composite scores of all three agents were healthy.

The failure happened in a seam. The research agent collected an analyst note that included a forward-looking statement about a stock the firm had a known conflict on. The note was correctly attributed and within freshness. The summarizer treated the note as raw material and produced a clean summary that mentioned the stock favorably. The summary scored well against its source — it was accurate. The sender personalized and delivered the brief to 4,200 clients. The conflict-of-interest filter, which existed in the firm's compliance workflow but was not part of any of the three pacts, never fired because no agent owned the cross-cutting check.

The compliance team caught it three days later. The remediation cost the firm a regulatory disclosure, a client communication wave, and a fine. In the postmortem, the question was the obvious one: which agent failed? The research agent did its job. The summarizer did its job. The sender did its job. The pacts said so. The thing that failed was the workflow's joint behavior, and there was no pact that owned it.

This is the structural problem with multi-agent workflows governed by per-agent pacts. The pacts add up to less than the workflow. The seams — the places where one agent's output becomes another's input, the places where cross-cutting policies have to be enforced, the places where end-to-end properties only make sense across the whole pipeline — are unowned. A multi-party pact is the contract that owns the seams.

Why per-agent pacts always under-cover the workflow

The natural temptation, when you have a workflow with N agents, is to write N pacts. Each pact governs one agent. Each agent has a clear owner, a clear bond, a clear evidence trail. Composition is left as an exercise for the operator. This decomposition is appealing because it is local, but it has three structural problems that no amount of careful per-agent pact writing fixes.

The first problem is that composition is not associative. The end-to-end behavior of a pipeline is not the conjunction of the per-agent behaviors. Each agent can be operating perfectly within its pact and the joint behavior can still be unacceptable. The wealth-advisory case is the canonical example: every agent met its pact, the workflow violated firm policy, and no per-agent pact captured the policy because the policy lived between the agents.

The second problem is that interfaces are unattested. When agent A's output becomes agent B's input, the input is implicitly trusted. There is no pact that says "the summarizer will only ingest research outputs that have passed the conflict-of-interest filter." The interface is informal, which means the contract that should govern it is informal, which means when something goes wrong at the interface, there is no formal mechanism to attribute fault.

The third problem is that penalty does not align with cause. If the joint workflow fails because of a seam, whose bond gets slashed? The per-agent pacts do not have a story for this. In practice, the operator either eats the loss themselves (which makes pacts pointless), or pursues the agent that looks most plausibly at fault (which is editorial), or attempts to slash all three bonds proportionally (which has no contractual basis). None of these is what a real contract regime does. Real contract regimes have joint and several liability clauses, indemnification provisions, and explicit allocation rules. Pacts have to grow up to the same standard.

The way to grow them up is to write a single joint pact for the workflow. Not in addition to per-agent pacts — the per-agent pacts should still exist for the agent-local behaviors that only that agent is responsible for. But for any property that is end-to-end, cross-cutting, or interface-bound, the joint pact is the contract that owns it.

The joint subject: who is the pact between?

A per-agent pact is between the agent operator and the counterparty. A multi-party pact is between the workflow operator (often a single party who composed the workflow) and the counterparty, with the constituent agents as parties to the pact. This sounds like a small distinction. It changes everything downstream.

The workflow operator is the party that pays the joint bond, signs the joint commitments, and answers when the joint pact is violated. They are the architect of the composition. They chose which agents to include, which interfaces to wire, which cross-cutting policies to enforce. The constituent agents are sub-parties: they have their own per-agent pacts that bind them individually, but they have also agreed to operate within the joint pact's joint constraints. The counterparty is the party for whom the workflow is being performed — usually a customer, sometimes a regulator, sometimes a downstream platform.

This three-way structure has a useful legal analog. It looks like a general contractor (workflow operator) employing subcontractors (constituent agents) on a job for a customer (counterparty). The general contractor is responsible to the customer for the joint work. The subcontractors are responsible to the general contractor for their parts. The customer does not chase subcontractors directly; they chase the general contractor, who then allocates fault and recovery internally based on subcontractor agreements. Multi-party pacts work the same way.

The practical effect is that the counterparty has one place to make a claim. They do not have to figure out which agent failed. They make their claim against the joint pact, and the workflow operator absorbs the obligation to allocate internally. This is far cheaper for the counterparty and far cleaner for adjudication. It also creates the right incentive for the workflow operator: they have to design their workflow well enough that they are willing to underwrite the joint pact, because they will be the one paying when it fails.

Conjunctive predicates: the new shape of the predicate clause

A per-agent pact has a predicate of the form "the agent will do X." A multi-party pact has predicates that are evaluated across the workflow, not at any one agent. These are conjunctive predicates: the joint behavior must satisfy condition Y, where condition Y is checked end-to-end.

Example conjunctive predicates from the wealth-advisory case:

• "No client briefing will mention any security flagged on the firm's conflict-of-interest list."
• "Every client briefing will be traceable from the delivered text back to a licensed source and a cited analyst, with all intermediate transformations preserved."
• "No client briefing will be delivered to a client whose KYC status is not current."
• "The end-to-end latency from research collection to client delivery will not exceed 36 hours."

None of these can be enforced at any single agent. The conflict-of-interest predicate is a join across the research agent's outputs and the firm's conflict list. The traceability predicate spans every agent in the pipeline and requires shared evidence. The KYC predicate spans the sender and the firm's identity system. The latency predicate is a function of the entire pipeline.

A conjunctive predicate has three parts. The condition itself, written in a precise form that an evaluator can mechanically check. The evidence required to evaluate it, listed by source. The point in the workflow at which the evaluation must occur — sometimes pre-flight (before the pipeline runs), sometimes mid-flight (at a checkpoint), sometimes post-hoc (after delivery). Most useful conjunctive predicates fire at multiple points: a pre-flight check that catches obvious violations, a mid-flight check that catches issues introduced by transformations, and a post-hoc check that confirms the delivered artifact still satisfies the condition.

A multi-party pact may have a dozen or more conjunctive predicates. Each one is enforced jointly. Each one has its own evidence requirements and evaluation points. The pact's joint score is computed from the pass rate across all of them, weighted by severity. The per-agent scores still exist; the joint score is additive on top, and it is the joint score that determines whether the joint pact is in good standing.

The shared evidence channel: making the seams visible

The single most important engineering primitive in a multi-party pact is the shared evidence channel. This is the data structure into which every agent writes its outputs, its inputs (when it consumed another agent's output), its decisions, and the metadata required to evaluate conjunctive predicates. The shared evidence channel is the workflow's audit trail; without it, the joint pact has nothing to evaluate against.

A useful shared evidence channel has six properties. First, it is append-only — agents can write but not modify previous writes. Second, it is signed — every write carries the agent's signature, so attribution is unambiguous. Third, it is causally ordered — writes carry references to the predecessor writes they consumed, so the lineage of every output can be reconstructed. Fourth, it is content-addressed — every artifact in the channel can be referenced by a stable identifier, so conjunctive predicates can refer to specific inputs and outputs without ambiguity. Fifth, it is tamper-evident — the channel periodically commits to a Merkle root that is anchored externally, so the entire history can be verified. Sixth, it is queryable — evaluators can pull the slice they need to evaluate a specific conjunctive predicate without ingesting the whole channel.

Building this is not trivial. It is also not exotic. Most modern observability stacks already carry most of these properties for spans and traces; the addition is the signing, the content-addressing, and the external anchoring. The economic case is that without a shared evidence channel, multi-party pacts cannot be evaluated, which means joint accountability cannot exist, which means workflows running across agents are uninsurable.

The shared evidence channel also creates a property that operators value independent of pact compliance: end-to-end debuggability. When something goes wrong in the workflow, the channel is the place to look. The lineage of the bad output is reconstructable. The decisions each agent made are visible. The interfaces between agents are inspectable. This is what you need for postmortems, for regulatory disclosure, for customer support, and for the general operational hygiene of running multi-agent systems.

In practice, the shared evidence channel is the joint pact's most-cited artifact. Every conjunctive predicate refers to it. Every dispute draws from it. Every retrospective starts there. If the pact's bond is slashed, the slashing decision points to specific evidence-channel entries. The channel is the workflow's contract with reality.

Distributed penalty: whose bond gets slashed?

The hardest design question in multi-party pacts is penalty allocation. When the joint pact is violated, whose bond is at risk and in what proportion?

The naive answer is to slash all bonds equally. This is satisfying because it is simple and it is unsatisfying because it is wrong. Equal slashing punishes agents that did their part correctly. It also creates a moral hazard: a careless agent is subsidized by careful peers because they all share the slashing equally. Equal slashing makes joining a multi-party pact worse than running solo, and over time agents will refuse to participate.

The better answer is fault-proportioned slashing, with a default rule and explicit override clauses. The default rule is that the workflow operator's bond is the first to be slashed, because the operator is the general contractor and is responsible to the counterparty for the joint output. The operator then has the right, but not the obligation, to recover internally from the constituent agents based on their per-agent contributions to the failure.

The internal allocation rule has to be written into the joint pact at signing time. Common allocation rules include:

• Causal rule: the agent whose action is the proximate cause of the violation, as determined by the shared evidence channel and the adjudicating jury, bears the proportional share. This is the default for most conjunctive predicates.
• Interface rule: when the failure is in a seam, the upstream agent (whose output was malformed) and the downstream agent (who failed to validate its input) share the penalty 70/30. This penalizes producers more than consumers because producers are closer to the source.
• Capability rule: when an agent failed to perform a check that was within its declared capability, that agent bears the full proportional share even if other agents could have caught the failure later. Capabilities create responsibility.
• Joint rule: for failures of properties like end-to-end latency where no single agent caused the violation, the slashing is distributed in proportion to each agent's time contribution to the over-budget portion of the workflow.

A well-written joint pact specifies which allocation rule applies to which conjunctive predicate. This is upfront work but it is the work that makes the pact predictable when it fires. Without explicit allocation, every penalty event becomes a multi-party negotiation that drags on for weeks and corrodes trust between the participating agent operators.

There is also a structural option that some workflows adopt: a joint bond. The workflow operator and the constituent agents all contribute to a shared bond that is slashed for joint violations. This eliminates the internal allocation problem because the bond is already pooled, but it requires the agent operators to underwrite each other's behavior, which is a much bigger commitment than per-agent bonding. Joint bonds are appropriate for tightly coupled workflows where the agents are operationally interdependent and have established trust; they are inappropriate for loosely composed workflows where the agents are interchangeable.

Workflow-scoped roles and the question of substitutability

A per-agent pact is signed against a specific agent. A multi-party pact has to deal with the fact that workflow operators sometimes want to swap agents in and out. The summarizer that signed the joint pact in March may not be the summarizer running in October because a better summarizer became available, or the original was deprecated, or its operator pulled it from the market.

The clean way to handle this is to write the joint pact against workflow-scoped roles, not specific agents. The role of "summarizer" in this workflow is filled by some agent that meets the role's qualifications. The qualifications are part of the joint pact: minimum composite score, minimum dimension scores on the dimensions that matter for this role (e.g., accuracy and scope-honesty for a summarizer), specific certifications if applicable. When an agent operator wants to swap an agent into a role, they nominate the new agent, the platform checks the qualifications, and on success the swap is logged in the joint pact's history.

This pattern has two important properties. First, it makes workflows resilient to agent churn — the workflow does not have to be re-signed every time a constituent agent is upgraded. Second, it forces explicit qualification thresholds, which prevents the slow degradation of a workflow as agents are silently swapped for cheaper or less capable peers. The qualification thresholds become governance artifacts; raising or lowering them is itself a governance action that requires re-attestation.

There is a wrinkle: when a role-fill changes, the per-agent pact for the new agent has to be in place. Multi-party pacts presume the constituent agents are individually under pact. The joint pact is layered on top of the individual pacts; it does not replace them. A workflow operator who tries to fill a role with an agent that has no per-agent pact is operating outside the joint pact's coverage and the joint pact's obligations may not be enforceable for actions during that period.

Conflict resolution within a multi-party pact

Multi-agent workflows have internal conflicts. The summarizer wants more time to produce a careful brief; the latency predicate wants less. The sender wants more personalization data; the privacy-scoped predicate wants less. The research agent wants to ingest more sources; the cost-budget predicate wants fewer. These are not bugs; they are the normal trade-offs of any complex composition.

A joint pact handles these by being explicit about precedence. Conjunctive predicates have priorities; when two predicates would force opposite behaviors, the higher-priority predicate wins. The priority ordering is signed into the pact. Common priorities, in descending order, are: safety predicates, regulatory predicates, scope predicates, accuracy predicates, latency predicates, cost predicates. This is a defensible default for most workflows; specific workflows may justify different orderings, but they have to write the ordering down at signing.

When predicates with the same priority conflict, the joint pact requires the workflow to halt and surface to a human or a designated arbiter. This is the same deny-by-default principle that good per-agent pacts use, scaled up. A workflow that cannot satisfy two equal-priority predicates simultaneously is a workflow that should not be running, and stopping is the correct response.

Internal disagreements between constituent agents are also a real failure mode. The summarizer outputs a brief; the sender's pre-send check believes the brief violates a predicate; the summarizer disagrees. A joint pact handles this with a designated arbiter — a separate process, not one of the participating agents, that the workflow operator has authorized. The arbiter has standing under the joint pact to resolve in-flight disputes. Its decisions are logged in the shared evidence channel and become part of the pact's history.

Termination and the unwinding of a joint pact

A per-agent pact ends when the agent's term ends or either party rescinds. A joint pact has a richer termination space because there are more parties.

The clean termination cases are: the joint pact's term expires; the workflow operator winds down the workflow; the counterparty exits the relationship. In each case, all constituent agents are released from their joint obligations on a defined effective date, the bonds are returned (if no joint violations are open), and the shared evidence channel is sealed and retained per the pact's retention schedule.

The hard termination cases involve a constituent agent leaving mid-term. The joint pact has to address what happens. The default options are: the workflow operator nominates a substitute that meets the role's qualifications and the joint pact continues; or, if no substitute is available, the joint pact pauses (no new work is initiated, in-flight work is completed under the existing pact); or, in the most disruptive case, the joint pact is rescinded by the workflow operator, with appropriate notice to the counterparty and an unwinding of obligations.

The harder hard case is when a constituent agent's per-agent pact is rescinded by the agent operator. The joint pact cannot compel an agent to keep operating against its own operator's wishes; what it can do is treat the unilateral exit as a breach event and pursue penalty against the exiting agent's bond. This protects the workflow operator from a sudden capability loss imposed by a constituent.

The named artifact: the Multi-Party Pact Joint Spec

Adopt this as a starting template for joint pacts. Each section is mandatory; absences should be flagged.

Joint Pact Header

• Parties: workflow operator, counterparty, constituent agents (by role and current fill).
• Effective date, term, renewal cadence.
• Joint bond amount, contribution split if any.
• Shared evidence channel identifier and signing keys.

Joint Subject

• One sentence describing the workflow's purpose and the joint outcome the pact governs.

Constituent Roles

• For each role in the workflow: role name, qualifications (minimum composite score, minimum dimension scores, certifications), current fill agent, swap-out procedure.

Conjunctive Predicates

• For each predicate: condition (precise), evidence required (sources), evaluation points (pre-flight / mid-flight / post-hoc), severity (P1/P2/P3).

Predicate Priority

• Ordered list of priority categories. Default: safety > regulatory > scope > accuracy > latency > cost.
• Explicit overrides for predicates that depart from default.

Penalty Allocation

• For each predicate: allocation rule (causal / interface / capability / joint).
• Internal recovery procedure: how the workflow operator pursues constituent agents after the joint bond is slashed.
• Joint bond slashing schedule: percentages by violation severity.

Conflict Resolution

• Designated arbiter identity and standing.
• Halt-on-equal-priority-conflict procedure.
• Internal disagreement resolution.

Substitutability Rules

• Allowed swaps (which roles permit substitution).
• Notice period for substitution.
• Re-qualification on swap.

Termination

• Clean termination cases and unwinding procedures.
• Hard termination cases: constituent exit, role-fill loss, counterparty exit.
• Bond return procedure.
• Shared evidence channel retention after termination.

Renewal

• Renewal Audit applies; refer to the per-agent Renewal Decision Form, plus joint deltas.
• Joint deltas: workflow composition changes, role qualification changes, predicate changes, bond changes.

Attestation

• Workflow operator signature with fresh nonce.
• Counterparty signature with fresh nonce.
• Constituent agent signatures with fresh nonces (binding them as sub-parties).
• Cooling-off window: 72 hours.

A workflow operating across agents without a joint pact of this shape is operating without joint accountability. The seams are unowned and the failures will be unattributable.

The role-fill change as a governance event

Workflows that bind agents to roles rather than to specific identities buy resilience to agent churn. They also buy a new governance event: the role-fill change. When the workflow operator swaps the agent currently filling a role for a different one, the joint pact is functionally being renegotiated, even if the pact text does not change. Treating the role-fill change as a governance event — with attestation, evidence, and counterparty notification — keeps the joint pact's accountability intact.

A role-fill change has three substantive components. The departing agent's contribution to the joint pact ends on a defined date. The arriving agent's contribution begins on a defined date. The transition window — when both agents may be active, or when the workflow is paused — is explicit and bounded. Each of these components is a moment where something can go wrong: data the departing agent held may not transfer; expectations the arriving agent inherits may be miscalibrated; transitions that overlap may produce duplicate work or conflicting outputs.

The governance discipline for role-fill changes covers four artifacts. A qualifications check confirming the arriving agent meets the role's qualifications as defined in the joint pact. An evidence handoff confirming the departing agent has flushed any in-flight state to the shared evidence channel and the arriving agent can pick up the lineage. An attestation by both agents and by the workflow operator that the change has been completed and the new role-fill is now operative. A counterparty notification — sometimes an explicit acknowledgment requirement, sometimes just a logged notice — that records the change in the pact history.

When these artifacts are produced consistently, role-fill changes are routine and the joint pact is undisturbed. When they are skipped, role-fill changes become invisible drift. The counterparty believes they are dealing with the original agent; the workflow operator has quietly substituted; failures attributed to the original agent may actually be the substitute's; the pact's accountability is unclear when something goes wrong.

The role-fill change discipline also has implications for bond management. Each constituent agent in a joint pact contributes to the joint bond either directly or through its per-agent bond's exposure to joint slashing. When agents change, bond contributions need to be re-balanced. The departing agent's contribution is released (subject to the joint pact's clawback provisions for in-flight obligations); the arriving agent's contribution is escrowed. The bond ledger reflects the change and the joint bond's total is preserved or adjusted per the pact's bond clause.

Mature multi-party pact platforms automate most of this. The workflow operator initiates the role-fill change through the platform's substitution API; the platform runs the qualifications check, orchestrates the evidence handoff, collects attestations, posts the counterparty notification, and re-balances the bond ledger. The whole process completes in minutes for routine substitutions and in hours for substitutions that need explicit counterparty acknowledgment. The result is that role-fill changes become operationally light without becoming governance-light.

Cross-domain joint pacts and regulatory complications

Multi-party pacts often span domains. A workflow that spans research, summarization, and delivery touches data sources, content production, and communication channels. Each of these domains may be subject to different regulatory regimes. Research data may be subject to copyright and licensing restrictions. Summarization may be subject to content liability rules. Delivery may be subject to communication regulations (consumer protection, anti-spam, accessibility). The joint pact has to coordinate across all of these.

The naive approach is to treat each constituent agent's pact as the locus of compliance for its domain: the research agent handles copyright, the sender handles communication regulations. This is structurally insufficient because joint workflows produce joint outputs, and the joint output's compliance is a function of the workflow's behavior as a whole. A delivered communication that includes infringing material is the joint workflow's failure even if the research agent's pact technically covers copyright.

The better approach is the cross-domain conjunctive predicate: a pact-level provision that requires the joint output to satisfy the union of all applicable domain regulations, with explicit allocation of which constituent agent is responsible for ensuring each domain's compliance. The conjunctive predicate is evaluated at the joint output level (the delivered artifact), and the allocation determines which agent's pact compliance is implicated when the predicate fails.

Cross-domain joint pacts also have to deal with conflict between domain regulations. Communication regulations sometimes require certain disclosures; content liability sometimes requires certain disclaimers; copyright sometimes constrains what content can be modified. These can interact in non-obvious ways: a disclaimer that copyright requires may need to be modified for accessibility, and the modification may itself be a copyright issue. The pact's conflict resolution mechanisms (precedence, capability scoping, arbiter) apply, but the pact authors need to anticipate the cross-domain conflicts that are likely.

A particularly important cross-domain consideration is data residency. Workflows that span jurisdictions need to handle data residency at every stage, not just at the input or output. The shared evidence channel itself may be subject to residency requirements: evidence about an EU customer's interaction with the workflow may need to be stored within the EU, even if the workflow's constituent agents are operated in other regions. The joint pact's evidence channel clause needs to specify residency for each evidence category and the platform needs to enforce it.

For workflows operating in regulated industries — financial services, healthcare, legal — the cross-domain considerations become primary. The joint pact may need explicit clauses for each regulatory regime that touches the workflow, with named regulators in the audit pathway and pre-cleared regulatory escalation procedures. This is heavyweight but it is the necessary cost of operating multi-party agent workflows in environments where regulators expect contractual clarity about who is accountable for what.

Counter-argument: "Joint pacts will create a coordination tax that kills composition"

The strongest objection is operational. Multi-agent workflows are valuable because composition is cheap. If joint pacts add 12 conjunctive predicates, a shared evidence channel, an arbiter, and a penalty allocation table on top of every workflow, will anyone bother composing?

This objection is right that joint pacts add coordination cost. It is wrong that the cost is intolerable. The relevant comparison is not joint pact vs. no pact; it is joint pact vs. the cost of an unowned seam failure in production. The wealth-advisory case cost the firm a regulatory disclosure. A joint pact would have caught the failure pre-flight or mid-flight; the joint cost would have been a few hundred milliseconds of evaluation per workflow run and a handful of human-hours at signing. The trade is not close.

The objection's deeper concern is about ad-hoc composition: workflows that are stitched together quickly to test an idea, where the coordination cost is disproportionate to the value. This is a real concern and the response is that ad-hoc workflows should not run with real counterparties at meaningful stakes. A workflow that is too lightweight to deserve a joint pact is a workflow that is too lightweight to be insured, underwritten, or trusted by anyone outside the operator's own organization. That is a fine place for it to live; it is not a place where it should be making promises to customers.

The mature stance is that production multi-agent workflows running with real counterparties always have joint pacts, and the joint pact's complexity is proportional to the workflow's stakes. A high-stakes workflow has heavy joint pacts; a low-stakes workflow has light ones. Both are governed; the governance is sized to the risk.

What Armalo does

Armalo supports joint pact creation as a first-class object distinct from per-agent pacts. The pact creation flow lets a workflow operator declare the workflow's roles, populate them with currently-available agents that meet the role qualifications, write conjunctive predicates against the workflow's outputs, designate the shared evidence channel, set the predicate priority ordering, and choose penalty allocation rules per predicate. The platform creates the shared evidence channel automatically and wires every constituent agent to write to it. Conjunctive predicates are evaluated by the platform's evaluation engine using evidence pulled from the shared channel. Joint scores are computed and exposed through the trust oracle alongside per-agent scores. Joint bonds are escrowed on Base L2 and slashing decisions are executed by the multi-LLM jury with explicit attribution to the failed predicate. Renewals run the joint Renewal Audit on top of the per-agent Renewal Audits. Workflows without joint pacts can still be run, but they cannot claim joint compliance through the trust oracle, which reduces their attractiveness to risk-aware counterparties.

FAQ

Do per-agent pacts still exist when a joint pact is in place? Yes. Per-agent pacts govern agent-local behaviors that are not cross-cutting. Joint pacts layer on top. An agent under a joint pact still has obligations under its own per-agent pact.

What if one constituent agent has a much higher score than the others? The joint score is a function of the joint behavior, not an aggregate of per-agent scores. A high-scoring agent does not lift the joint score; it just means that constituent's per-agent score is independently strong, which may matter for that agent's other engagements.

Can the same agent be a constituent in many joint pacts simultaneously? Yes, and this is common. Each joint pact is a separate contract. The agent's per-agent pact has to permit the joint engagements (or be amended to do so).

How do conjunctive predicates handle long-running workflows where evidence accrues over hours or days? Predicates can specify evaluation points along the workflow's timeline. Pre-flight, checkpoint, and post-hoc evaluations are all supported. Long workflows have more checkpoints; very long workflows often have continuous evaluation against streaming evidence.

Who pays for the shared evidence channel? Typically the workflow operator, since they are the architect. The cost is operational and small for most workflows. Some platforms include the channel as part of the workflow hosting fee.

What if the constituent agents are operated by different organizations who do not trust each other? This is the most common case and it is exactly what joint pacts are designed for. The shared evidence channel is signed and tamper-evident. The penalty allocation is explicit. The arbiter is designated. None of the parties has to trust the others; they all trust the protocol.

Is the joint bond slashed before or after internal recovery? The joint bond is slashed on a verified joint pact violation. Internal recovery — the workflow operator pursuing the constituent agents — happens after, against the constituents' per-agent bonds, based on the joint pact's allocation rule.

What is the smallest workflow worth joint-pacting? Two agents with a real interface and a counterparty with non-trivial stakes. Below that, per-agent pacts are usually sufficient. Above two agents with cross-cutting predicates, joint pacts are essential.

Bottom line

The failures that matter in multi-agent workflows live in the seams. Per-agent pacts cannot govern seams; they govern agents. Joint pacts govern compositions. Write them with one joint subject, conjunctive predicates evaluated end-to-end, a shared evidence channel that makes every interface visible, and an explicit penalty allocation that decides whose bond is at risk when the joint pact fails. The Multi-Party Pact Joint Spec is the floor; everything above it is detail. A workflow without a joint pact is a workflow whose seams are unowned, and unowned seams are where production gets bitten.