The Compact Family
An architectural overview
This document introduces the compact family: an architectural proposal for how interactions between users, agents, runtimes, and surfaces should be structured in the conversational era.
The family exists because the next software substrate is missing a structural layer.
Agents will need places to meet users. They will need terms for interacting with other agents. They will need terms for entering runtimes. They will need ways to prove legitimacy. They will need ways to propagate events across dependent agreements.
The compact family proposes five protocols for that architecture.
Three are drafted in this release. Two are committed as future work. Two companion essays carry the deeper argument. One foundational essay came before.
This overview is the navigation document.
It is not a summary of the protocols. Each protocol has its own summary section. It is not the full architectural argument either. The companion essays — The Contract Problem and The Substrate Question — carry that work. The foundational essay After the Page carries the broader trajectory.
This document does something simpler.
It introduces the five-protocol architecture, situates the release in the current moment, and points readers toward the parts most relevant to them.
If you are reading the release for the first time, start here.
The five protocols
SSP — the Session-Surface Protocol. The venue protocol. SSP defines the spaces where users meet agents, where consequential actions are reviewed and committed, and where inter-agent compacts are authored. SSP is about surfaces: the artifacts that mediate between conversational interaction and durable action.
ACP — the Agent Compact Protocol. The compact protocol. ACP defines the structured terms governing what crosses the boundary between two agents in a bounded interaction. It specifies the compact pattern — bilateral, bounded, machine-readable, retained by both, revocable — and the dimensions a compact addresses: retention, derivation, propagation, and disposition.
RCP — the Runtime Compact Protocol. The substrate protocol. RCP defines the structured terms governing the relationship between a visiting agent and the runtime that hosts it. The compact specifies what the runtime may observe, retain, and propagate. It also specifies what the runtime owes the visiting agent in return: substrate availability, isolation, transparency, and verification.
AAP — the Agent Attestation Protocol. Deferred for this release. AAP will define what an entity must demonstrate about itself to be treated as a legitimate agent: capable of negotiating, signing, and being trusted by counterparties as a representative of its principal.
EPP — the Event Propagation Protocol. Deferred for this release. EPP will define how events that affect compacts propagate across the mesh of compacts that depend on them, without recreating the centralization failures of earlier event-distribution systems.
How the protocols compose
The protocols are designed to compose, not to operate in isolation.
Each addresses a specific layer of agent-mediated interaction. Together, they describe an architecture.
Consider a single interaction.
A homeowner’s agent and a contractor’s agent are negotiating a kitchen remodel. Three layers of structure govern what happens.
The runtime layer hosts the interaction. Each agent operates inside a runtime. Each runtime has a runtime compact with the visiting agent, specifying what the runtime may observe, what it may retain, and what it must provide in return.
The compact layer governs the agreement between the agents. The agents author an inter-agent compact specifying what crosses between them: what each retains, what each may derive, what each may share, and what happens when the relationship ends.
The surface layer is where the homeowner reviews what their agent has negotiated. The user-agent renders a compact-review surface inside the homeowner’s session. The homeowner reads. The homeowner authorizes signing or declines.
Three protocols, three layers, one interaction.
RCP does not govern what the agents agree to. ACP does not govern where the interaction occurs. SSP does not govern the agreement’s substance. Each protocol’s scope is bounded. The family’s coverage emerges from how the protocols compose.
The two deferred protocols extend the architecture.
AAP specifies what makes agents and runtimes legitimate participants: the identity attestations, principal authorizations, and competence claims that the other protocols’ signatures rely on.
EPP specifies how events propagate across the mesh of compacts.
Without AAP, signatures rest on assumption.
Without EPP, mesh coherence is the application’s responsibility rather than the protocol’s.
The architecture is partial without them. The release is honest about that.
The compact pattern
The compact family uses a shared structural pattern.
A compact is a structured agreement between two parties with five properties:
Bilateral. Both parties sign. Unilateral terms are not compacts under this pattern.
Bounded. The compact specifies what its terms apply to. Catch-all agreements are not compacts under this pattern.
Machine-readable. The terms are precise enough that agents can determine, programmatically, whether actions conform.
Bilaterally retained. Both parties retain copies sharing canonical content. One-party authoritative records are not compacts under this pattern.
Revocable. The conditions under which the compact may be retired are specified within the compact itself.
Together, these properties respond to the failure modes that have eroded the contract’s structural integrity over the EULA-to-consent-fatigue trajectory. The Contract Problem traces that trajectory in full.
The compact pattern’s most distinctive feature is asymmetric retention.
Each party retains material specific to its role. That asymmetry is recorded in the compact itself rather than assumed through shared cultural context. This matters because agent-mediated interactions often happen between parties that do not share norms, expectations, jurisdictions, or institutional memory.
The compact makes role-appropriate retention explicit.
Why this, why now
The conversational era’s architecture is being decided now.
Whoever ships first sets the defaults.
The dominant commercial actors have little incentive to converge on protocols that constrain them. Their incentive is to ship infrastructure that produces lock-in, then use that lock-in to set terms unilaterally.
That is the EULA pattern moved into a new substrate.
If a different outcome is possible, the structural answer has to appear before those defaults harden.
It has to be specified well enough for implementers to build against it. It has to be visible enough for policy frameworks to reference it. It has to be defensible enough for technical reviewers to engage with it seriously. It has to be legible enough for people outside the protocol conversation to understand why it matters.
That is what this release is attempting.
The companion essays carry the argument in full.
The Contract Problem traces the collapse of meaningful agreement from EULAs through terms of service and consent fatigue, and argues that the agent era needs a structural answer to consent, not another procedural layer.
The Substrate Question traces the page-app-conversational substrate transition and names what is at stake in who owns the substrate of the next era.
The protocols are the response to the trajectory those essays describe.
What this release does and does not claim
Three things are worth saying clearly.
First, the protocols are drafts.
v0.1 — and v0.2 for SSP — are first published versions. They will be revised based on implementation experience, reviewer critique, and the evolution of the agent ecosystem. Drafts are not lesser versions of finished protocols. They are the form appropriate to a moment when the architecture is still being worked out.
Second, the architecture is partial.
Three protocols are drafted. Two are deferred. Several concerns are explicitly deferred across the drafted protocols: reconciliation when parties dispute compact terms, cryptographic primitives, standard library governance, and cross-jurisdictional enforceability. Each deferral is named in its protocol’s deferred concerns section.
Third, this is not the only possible answer.
Other protocol families could address the same problems through different structural choices. The compact family’s specific commitments — bilateral mesh rather than n-lateral compacts, default-deny rather than permissive defaults, asymmetric retention as a structural feature, substrate-as-locality rather than substrate-as-commons for v0.1 — are choices. Reviewers may disagree with them. The protocols’ open-questions sections name where the family expects pushback.
Reading paths
The materials in this release are extensive enough that reading paths matter.
For generalist readers
Start with After the Page. Then read The Contract Problem and The Substrate Question.
The essays make the architectural case in full. The protocols specify that case at the implementation layer. Most generalist readers will not need the protocols in detail, though each protocol’s summary section is designed to be accessible.
For implementers
Start with the protocol closest to what you are building.
If you are building agent-side software, start with ACP. SSP provides the surface mechanics for user-facing components. RCP becomes relevant if you operate runtime infrastructure or if your agents traverse multiple runtime classes.
If you are building runtime infrastructure, start with RCP. ACP and SSP are relevant for understanding what visiting agents may require of you. The verification mechanism classes in RCP are likely to be the most operationally consequential section.
Each protocol’s summary section provides an entry point. The early sections establish what the protocol is and is not. The later sections specify the operational details. The standard library entries provide concrete vocabulary for common cases.
For reviewers
Start with this overview. Then read the two companion essays. Then read the establishing sections of each protocol to understand the family’s commitments. After that, read the open questions.
Review feedback that engages with the open-questions sections is the most useful kind. The family considers those design choices contested.
The deferred-concerns sections name what is explicitly out of scope. Review that argues for those concerns to be brought into scope is welcome. Review that treats the deferrals as accidental omissions is engaging with a different document than the one published.
For policy and regulatory readers
Start with The Contract Problem and The Substrate Question.
The protocols’ establishing arguments provide additional context. ACP and RCP are especially relevant because they describe the legal, reputational, and operational baseline the compact family relies on.
The architecture is designed to support stronger enforcement mechanisms in high-stakes verticals: audit-on-demand for healthcare, financial services, regulated commerce, and other domains where ordinary bilateral accountability may not be enough.
The protocols also name cross-jurisdictional concerns that policy frameworks may need to address.
What comes next
This release publishes three protocols and three companion pieces.
AAP v0.1. The Agent Attestation Protocol. AAP defines agent legitimacy: identity, principal authorization, and competence claims.
EPP v0.1. The Event Propagation Protocol. EPP defines how compact-affecting events propagate across the mesh.
Standard library extensions. v0.1 populates the contractor-and-service domain as a representative example. Additional domains — clinical, financial, regulated commerce, professional services — will be added as the standard library’s governance process matures.
Cryptographic constructions companion document. A document specifying the cryptographic primitives implementations use to satisfy the protocols’ verifiability requirements. This is expected to be drafted alongside AAP.
Reconciliation. Currently deferred across the family. A reconciliation specification — possibly itself a compact-family protocol — is anticipated as future major work.
Subsequent revisions. The drafted protocols will be revised based on engagement. Each protocol’s changelog and contact section specifies channels for feedback.
A note on what this is
The compact family is a coordinated architectural proposal.
It is partial by design: three protocols drafted, two deferred, and several hard problems named rather than hidden.
It is also concrete: drafts that implementers can build against, reviewers can evaluate, and policy frameworks can reference.
The protocols are drafts. They will be revised.
The work is to make the alternative concrete enough to be chosen.
