v0.1 Draft: Negotiated Terms for Where Inter-Agent Interactions Are Hosted

Part of a coordinated release

This is one of three protocol drafts being published together: SSP v0.2 (the Session-Surface Protocol), ACP v0.1 (the Agent Compact Protocol), and RCP v0.1 (this document). The three specs are intended to be read together as a coordinated architectural proposal. An architectural overview introduces the five-protocol architecture: SSP, ACP, RCP, AAP (the Agent Attestation Protocol), and EPP (the Event Propagation Protocol). Three of the five are included in this coordinated release; AAP and EPP are named throughout but not yet drafted. RCP v0.1 can be read standalone, but readers wanting the full picture should start with the overview.

The companion essay The Substrate Question provides the architectural argument that motivates RCP. It traces the page-era, app-era, and AI-era substrate transitions, names what is at stake when substrate is owned, and argues for why the conversational era cannot inherit a neutral commons by default. The essay is recommended for readers who want to understand why RCP exists; it is not required to implement the protocol.

Summary

RCP v0.1 specifies structured terms governing the relationship between a visiting agent and the runtime that hosts the agent's session. It defines the form of those terms, the negotiation that produces them, the artifact that records them, and the obligations the runtime and the visiting agent each retain under them. The artifact is called a runtime compact: bilateral, machine-readable, signed by both parties, and retained by both, with the runtime carrying positive obligations (substrate availability, isolation, transparency) matching the structural advantages of being the substrate.

v0.1 is part of a coordinated release of three protocol drafts. The three protocols compose:

• SSP defines the venue where users meet agents.
• ACP defines the compacts that govern what crosses between agents.
• RCP defines the runtime compacts that govern where interactions are hosted.

Two additional protocols (AAP and EPP) are named throughout but not yet drafted; they are committed to as future work.

RCP exists because the question of where conversational-era interactions are hosted is not architecturally neutral. The runtime that hosts a session has substantial structural advantages: it observes what passes through, it shapes what is possible, it persists when sessions end. A runtime that holds these advantages without being accountable to the parties whose interactions it hosts is a runtime that converts hosting into capture. The runtime compact is the mechanism that prevents this conversion at the protocol layer.

1. What RCP is

RCP defines structured terms governing the relationship between a visiting agent and the runtime that hosts the agent's session. It specifies the form of those terms, the negotiation that produces them, the artifact that records them, and the obligations the runtime and the visiting agent each retain under them.

The terms govern hosting. When an agent enters a runtime — to conduct a session, to negotiate with another agent, to render surfaces for a principal, to author or sign an ACP compact — the runtime hosts the agent's operations. The runtime sees what the agent does, has potential access to what the agent's session contains, and provides the substrate on which the agent's interactions occur. RCP specifies how this hosting relationship is constrained: what the runtime may observe, what the runtime may retain, what the runtime may derive from what it observes, what the runtime may share with parties outside the hosting relationship, and what the runtime is obligated to provide as the substrate the visiting agent operates on.

The agreement itself is an artifact. RCP calls it a runtime compact. A runtime compact is bilateral between the visiting agent and the host runtime, machine-readable, signed by both parties, and retained by both. Once authored, it persists independently of the session it enables, governing the parties' obligations until it expires or is revoked.

RCP does not govern what the visiting agent does inside the runtime. The visiting agent's interactions with other agents are governed by ACP. The visiting agent's surfaces are governed by SSP. The visiting agent's identity and authorization are governed by AAP. RCP governs only the hosting relationship — the relationship between the visiting agent and the substrate on which the agent's other interactions occur.

RCP exists because the question of where conversational-era interactions are hosted is not architecturally neutral. The runtime that hosts a session has substantial structural advantages: it observes what passes through, it shapes what is possible, it persists when sessions end. A runtime that holds these advantages without being accountable to the parties whose interactions it hosts is a runtime that converts hosting into capture. The runtime compact is the mechanism that prevents this conversion at the protocol layer — by making the runtime's obligations explicit, mutual, and machine-enforceable, rather than implicit, asymmetric, and dependent on the runtime's good will.

[RCP v0.1 introduces the protocol family's runtime compact. The compact pattern shared with ACP is articulated in ACP §3; RCP §3 specifies how the pattern manifests for runtime hosting relationships specifically.]

2. What RCP is not

RCP is deliberately narrow.

RCP is the runtime hosting protocol, not a runtime architecture specification. It does not prescribe what kind of compute substrate runtimes are built on (cloud platforms, edge devices, hybrid configurations, attested enclaves, or substrates not yet designed); it specifies what a runtime, whatever its architecture, must commit to in its hosting relationship with visiting agents. Different runtime architectures may satisfy the same RCP requirements through different mechanisms.

RCP is not a substitute for ACP. The terms of inter-agent interactions hosted within a runtime are governed by the visiting agents' ACP compacts; RCP governs only the runtime's role as host. Where ACP compacts and runtime compacts share concerns (retention, propagation, derivation, disposition), the protocols compose: each governs its own party's obligations in its own scope.

RCP is not a substitute for AAP. The legitimacy of the visiting agent — what makes the agent a genuine representative of its principal, capable of authorizing the runtime compact's terms on the principal's behalf — is AAP's concern. RCP names this dependency where it bears on the protocol's claims and defers the mechanism.

RCP is not a substitute for legal or regulatory frameworks governing computation. Where jurisdictions impose obligations on runtimes — data residency requirements, export controls, audit obligations, content moderation requirements — RCP does not displace those obligations. The runtime compact may incorporate jurisdictional obligations as terms; the protocol does not pretend to override them.

The granular inventory of what is in scope, out of scope, and deferred is in §13.

3. The substrate question

This section names what is at stake when the conversational era's substrate is built. The argument is developed at full length in the companion essay The Substrate Question; this section provides the version that grounds the protocol's design choices for readers who do not engage with the essay separately.

3.1 Three substrate eras

The page era's substrate was a commons. The protocols that defined it — DNS, HTTP, TCP/IP, the open web's foundational standards — were specified in public, governed by multi-stakeholder bodies, and free for any implementer to use. The substrate was not perfect; it had failure modes (DNS captures, certificate-authority compromises, the slow privatization of standards-setting). But its commons character was real: the substrate was shared infrastructure, owned by no single party, accountable to a public process, available to any implementer who would conform to its specifications.

The app era's substrate was proprietary. As applications moved into walled gardens — Apple's iOS, Google's Android, Facebook's platform, Amazon's stack, Microsoft's ecosystem — the substrate that hosted applications became platforms whose owners controlled what was possible, who could participate, and on what terms. The substrate's value continued; what changed was who captured it. The page era's commons did not disappear, but the substrate of the most economically valuable interactions migrated into infrastructures whose owners had no obligation to operate them as commons.

The AI era's substrate is unsettled. The runtimes that host conversational-era interactions — the language models, the agent execution environments, the infrastructure that conversational and agentic applications run on — are currently being built. The question of who owns the substrate, what obligations its owners carry, and whether the substrate operates as commons or as captured infrastructure is being answered right now, by default, through whoever ships first. The default answer is captured infrastructure, because that is what the largest commercial actors are best positioned to build and what they have the strongest incentive to ship.

3.2 Why the AI era cannot inherit the page era's commons by default

It is tempting to assume that the AI era will repeat the page era's commons because the technical sophistication of conversational-era infrastructure does not exceed the sophistication of the page era's. The assumption is not true.

The page era's commons emerged from a specific historical situation: research-funded development, a culture of open standards-setting, the absence of dominant commercial actors with substrate-control incentives, and the practical impossibility of any single actor controlling the substrate's reach. None of these conditions hold in the AI era. The infrastructure is being built primarily by commercial actors with explicit substrate-control incentives. The standards-setting culture has been substantially eroded by the app era's privatization of related standards. Dominant commercial actors are positioned to control the substrate's reach by being the actors who deploy it first and at scale. The page era's commons was not an inevitability; it was a contingency, and the contingencies that produced it are not present now.

If no protocol-level intervention is made, the AI era's substrate will be captured by default. Each major commercial runtime will operate as its own substrate; visiting agents will negotiate terms with whatever runtime they are using; the terms will be set unilaterally by the runtime owner because no shared protocol exists for negotiating them; users will face the same terms-of-service screens the page-to-app transition produced, now mediating substrate access rather than application access. The structural pattern repeats.

RCP exists to make a different outcome possible. The protocol does not force commons; it makes commons feasible by providing a shared specification for what runtime compacts can require. A runtime that conforms to RCP carries obligations that are bilateral, machine-readable, and enforceable. Runtimes that conform to RCP can interoperate; runtimes that do not cannot host visiting agents whose principals have authorized only RCP-conformant runtimes. The protocol creates the conditions under which substrate-as-commons is a viable architectural choice rather than a nostalgic gesture toward an era whose conditions cannot be reproduced.

3.3 Three models of substrate

The runtime compact pattern admits three architectural models. v0.1 commits to one and acknowledges the others as possible future destinations.

3.3.1 Model A: substrate as full commons

Substrate operates as the page era's commons did: the runtime infrastructure is governed by multi-stakeholder bodies, conforms to public specifications, and operates under obligations enforced by institutional mechanisms (regulatory bodies, certification authorities, audit infrastructures, professional accreditation). RCP's role under Model A would be to specify what runtimes must commit to in order to participate in the commons; the commons itself would be governed by institutions outside the protocol.

Model A is the most architecturally ambitious commitment to substrate-as-commons. It is also predicated on institutional infrastructure that does not exist in the AI era's current configuration. The multi-stakeholder bodies that would govern the substrate, the audit infrastructures that would verify conformance, the regulatory frameworks that would impose obligations — these are present in mature form for some adjacent infrastructures (telecommunications, financial systems, parts of healthcare) but not for AI runtimes. Model A is what the substrate could become if the institutional preconditions are built; it is not what the substrate is now.

3.3.2 Model B: substrate as locality

Each runtime operates as its own locality. Runtimes are not part of a shared commons; they are individual hosts that visiting agents enter on terms specified by bilateral runtime compacts. RCP under Model B specifies what runtime compacts must contain — what terms the runtime must commit to, what protections the visiting agent retains — and the negotiation between runtime and visiting agent is the mechanism that establishes the relationship's specifics.

Model B does not require institutional infrastructure beyond what the protocol family's other components provide. It works in the current ecosystem: any runtime that conforms to RCP can host any visiting agent that wants to operate under RCP-conformant terms. The interoperability is bilateral rather than commons-mediated; the protections are machine-enforced rather than institution-enforced.

Model B is the v0.1 commitment. It is the pragmatic answer to the question of how substrate can be made accountable in the absence of commons-supporting institutions. It is not the most architecturally ambitious answer; it is the answer that works now.

3.3.3 Model C: substrate as competitive market

Substrate operates as a market without protocol-level coordination. Runtimes compete on the terms they offer; visiting agents choose runtimes based on the terms; competitive pressure drives terms toward what visiting agents will accept. RCP under Model C would not exist; the protocol family would specify SSP and ACP but leave substrate to market dynamics.

Model C is the failure mode of doing nothing about substrate. In the current configuration, market competition does not produce strong protections for visiting agents because dominant runtime providers face limited competitive pressure on terms — visiting agents and their principals lack the information, the coordination, and often the alternatives required to make substrate terms a meaningful competitive dimension. Model C is what happens if no protocol-level intervention is made; it is the default the AI era is currently sliding toward.

The compact family does not adopt Model C. The architectural argument for the family is that protocol-level coordination on substrate is necessary to prevent capture, and Model C is the formal name for the choice not to coordinate.

3.4 The v0.1 commitment

RCP v0.1 commits to Model B. The protocol specifies the terms of bilateral runtime compacts in sufficient detail that runtimes and visiting agents can negotiate, sign, and enforce them in the current ecosystem.

The commitment is not a rejection of Model A as an eventual destination. As the institutional infrastructure that Model A requires matures — audit bodies that can verify runtime conformance, regulatory frameworks that can impose substrate obligations, multi-stakeholder governance that can maintain commons-grade standards — the protocol may evolve to support hybrid models or eventually Model A. v0.1 does not commit to that trajectory; it does not pretend to know what institutional infrastructure will emerge or in what form. v0.1 commits to Model B because Model B works now.

The commitment is a rejection of Model C. The architectural argument that motivates the compact family is that the AI era's substrate cannot be left to market dynamics without protocol-level coordination producing capture. RCP exists because Model C is the default and the default is the failure mode. The protocol's role is to make a different choice available and to specify that choice precisely enough that runtimes and visiting agents can implement it.

Future protocol revisions may specify additional models: hybrid architectures combining commons-grade obligations with bilateral negotiation, federation protocols that link runtime localities into larger structures, attested architectures that use cryptographic primitives to enforce obligations the protocol layer alone cannot. The runtime ecosystem may produce architectural innovations the protocol's current design does not anticipate — substrate forms analogous to virtual private networks, where visiting agents operate under runtime compacts that grant specific terms across federated runtimes. v0.1's role is to make the substrate question explicit and to provide a working answer that does not foreclose these possibilities.

3.5 What this means for protocol design

The substrate question shapes RCP's design at several specific points.

RCP specifies the runtime compact's terms in detail (§5, §6) because the compact is the mechanism by which substrate accountability is established. A runtime compact whose terms are vague or whose enforcement depends on the runtime's good will is a runtime compact that does not produce accountability; the specification is what makes the protocol's protections real.

RCP requires that runtime compacts include explicit obligations on the runtime, not only restrictions on the visiting agent (§6.2). A protocol that specifies only what visiting agents must do reproduces the asymmetry that captured substrate produces; runtimes must carry obligations matching the structural advantages they hold.

RCP includes audit and verification provisions (§7) because Model B's protections depend on the visiting agent's ability to detect runtime non-compliance. Without verification, runtime obligations are aspirational; with verification, they are checkable. The verification mechanisms are deferred to AAP and EPP for substantive specification, but RCP requires that verification be possible and names what it must accomplish.

RCP names jurisdictional limitations explicitly (§13). The protocol's effective protection depends on legal and regulatory frameworks that vary by jurisdiction; v0.1 is honest about this dependency rather than papering over it. Runtimes operating in jurisdictions with strong substrate-relevant frameworks will produce stronger RCP protections than runtimes in jurisdictions without them; the protocol's design accounts for this variation rather than pretending it does not exist.

[§3 names the substrate question and commits v0.1 to Model B (substrate-as-locality with bilateral runtime compacts). The full rhetorical argument for why substrate matters is in The Substrate Question companion essay; this section grounds the protocol's design choices for readers who do not engage with the essay separately. The compact pattern shared across the family is articulated in ACP §3; subsequent revisions may consolidate the articulation in RCP if the family matures that way.]

4. Key terms

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

Runtime

The computational substrate on which an SSP-speaking application or an ACP-negotiating agent operates. A runtime provides compute resources, network connectivity, storage, and the execution environment that hosts agent operations. Runtimes may be cloud platforms, edge devices, hybrid configurations, attested enclaves, or other compute substrates.

RCP does not specify what a runtime is internally. It specifies what a runtime, whatever its architecture, must commit to when hosting visiting agents.

Host runtime

A runtime hosting a visiting agent's session. The host runtime is one party to the runtime compact; the visiting agent is the other.

The host runtime's principal — the entity ultimately accountable for the runtime's operations — is identified in the runtime compact. The principal may be the operator of a cloud platform, the manufacturer of a device, the institution running a private deployment, or any other entity that bears accountability for what the runtime does.

Visiting agent

An agent operating inside a host runtime. The visiting agent enters the runtime to conduct sessions, negotiate ACP compacts, render surfaces, or perform other operations specified by the visiting agent's principal.

A visiting agent represents a principal whose interests differ from the host runtime's principal. Where the visiting agent and the host runtime share a principal — when an agent is operating on infrastructure its own principal owns — the runtime compact is structurally optional, since the parties' interests align by definition. Where the visiting agent and the host runtime have distinct principals, the runtime compact is the mechanism by which the parties' relationship is structured.

Runtime compact

A bilateral compact between a host runtime and a visiting agent governing the terms of the hosting relationship. The runtime compact specifies what the host runtime may observe, retain, derive, and propagate; what obligations the host runtime carries toward the visiting agent (substrate availability, isolation guarantees, transparency); the visiting agent's reciprocal obligations to the host runtime (resource limits, conformance to runtime policies); and the lifecycle terms governing how the relationship begins, ends, and is revoked.

A runtime compact is an artifact under SSP §4. It is bilaterally retained, machine-readable, signed by both parties, and durable across sessions. The full structural specification of the compact pattern is in ACP §3; RCP applies the pattern to runtime hosting.

Hosting relationship

The relationship between a host runtime and a visiting agent during the period the visiting agent is operating inside the host runtime. The hosting relationship is established by the runtime compact and persists for the compact's effective period.

The hosting relationship is asymmetric by structure. The host runtime has substrate-level structural advantages (observation capability, persistence beyond sessions, control over what is possible); the visiting agent operates as a guest inside infrastructure it does not control. RCP's protective claims are responses to this asymmetry — the runtime compact constrains what the host runtime may do with its structural advantages.

Substrate observation

What the host runtime is in a position to observe about the visiting agent's operations. Includes: messages exchanged with the visiting agent, sessions conducted within the runtime, surfaces rendered to principals, ACP compacts authored or signed within the runtime, and any other agent activity the runtime hosts.

Substrate observation is a capability of the host runtime by virtue of its hosting role. RCP specifies what the runtime may do with what it observes; it does not specify whether observation is technically possible. Where observation is technically prevented (through cryptographic primitives, attested enclaves, or other mechanisms that restrict what the runtime can see), the runtime's compliance with retention and derivation restrictions is structurally enforced. Where observation is technically possible, the runtime's compliance depends on the compact's enforcement mechanisms (§7).

Substrate availability

The obligation the host runtime carries to provide the substrate the visiting agent operates on, conforming to the terms specified in the runtime compact. Includes uptime commitments, resource provisioning, isolation between visiting agents, and transparency about substrate behavior.

Substrate availability is the runtime's reciprocal obligation under the compact. Where ACP's compact specifies the visiting agent's obligations toward the counterparty agent, RCP's compact specifies obligations on both sides — the visiting agent's obligations to the runtime (resource-use limits, policy conformance) and the runtime's obligations to the visiting agent (substrate availability, isolation, transparency).

5. The runtime compact as artifact

This section specifies the runtime compact's required fields, canonical content, signing semantics, versioning, and lifecycle. The structural pattern is shared with ACP's compact (ACP §3, §5); this section specifies how the pattern manifests for runtime hosting relationships.

5.1 The compact as artifact

A runtime compact is a durable artifact existing independently of the sessions it hosts and the visiting agent operations it enables. Once committed, the runtime compact persists under its own lifecycle rules until it expires or is revoked.

Each party retains a copy. The two copies share canonical content (§5.3); each party's copy may also contain that party's retention slice as governed by the compact's terms. The pairing — runtime and visiting agent each holding compatible but distinct retention — is what makes the compact a runtime compact under this protocol.

5.2 Required fields

Every runtime compact MUST contain the following fields. Implementations MAY extend with additional fields for specific use cases; the listed fields are the minimum.

5.2.1 Identification

• Compact identifier. A globally unique identifier for this runtime compact. Stable across the compact's lifetime; survives versioning.
• Version identifier. A version number or hash. Each material change to the compact's terms produces a new version.
• Predecessor reference. If this version supersedes a prior version, the predecessor's version identifier. Null for initial versions.

5.2.2 Parties

• Host runtime identity. The cryptographic identity of the host runtime. The form of identity is deferred to AAP; RCP requires that whatever form AAP specifies is recorded here.
• Host runtime principal. Identification of the principal accountable for the host runtime's operations. May be a corporation operating a platform, an institution running a deployment, an individual operating a personal device, or any other entity AAP recognizes.
• Host runtime principal authorization. Verifiable proof that the host runtime's principal authorized the specific terms in this compact's canonical content. The mechanism is deferred to AAP.
• Visiting agent identity. Same as host runtime identity, for the visiting agent.
• Visiting agent principal. Same as host runtime principal, for the visiting agent's principal.
• Visiting agent principal authorization. Same as host runtime principal authorization, for the visiting agent's principal.

RCP compacts are bilateral; runtime compacts have exactly two parties: the host runtime and the visiting agent. Where multiple agents are visiting the same runtime, each visiting agent has its own runtime compact with the host. Each agent's runtime compact governs that agent's hosting relationship; runtime compacts are not multilateral.

5.2.3 Bounded scope

RCP inherits the default-deny stance specified in ACP §5.2.3. Any operation, observation, retention, or propagation not explicitly permitted within the bounded scope is strictly out of scope.

• Hosting scope. What hosting operations this compact governs. May be a specific session, a class of sessions, or all sessions the visiting agent conducts inside the host runtime over a defined period.
• Effective period. The time bounds during which this runtime compact is in force.
• Out-of-scope clarification. Optional. Used solely to resolve edge-case ambiguity about what falls within the specified scope, not to establish the boundary itself.

5.2.4 Substrate observation and retention dimensions

The substrate observation and retention dimensions specify what the host runtime may observe and what the host runtime may retain. These are the runtime's primary commitments under the compact.

• Host runtime observation. What the host runtime is permitted to observe about the visiting agent's operations. Specified as an enumerated list of observation classes; observation classes not in the list are forbidden.
• Host runtime retention. What the host runtime is permitted to retain from observed material. Specified per category, with retention durations, derivation rights, propagation rights, and disposition rules.
• Visiting agent retention. What the visiting agent retains from the hosting relationship. Typically minimal — visiting agents do not retain material about the host runtime beyond what is needed for the hosting relationship's audit and verification.

The asymmetric retention pattern (ACP §4) applies. The host runtime retains material related to its hosting role; the visiting agent retains material related to its accountability of the host. The retention slices are not the same; the asymmetry is the compact's structural form.

5.2.5 Substrate availability obligations

The host runtime's reciprocal obligations are specified in the substrate availability dimension. These are the obligations the host runtime owes to the visiting agent — the obligations that distinguish the runtime compact from a one-sided contract under which only the visiting agent accepts terms.

• Uptime commitments. Specified availability targets for the substrate the visiting agent operates on. May be unconditional (X% uptime), conditional (best effort with named exceptions), or graded (different commitments for different operation classes).
• Resource provisioning. What computational resources the visiting agent may rely on: memory, compute, network bandwidth, storage. Specified as guarantees, fair-share commitments, or capped allocations.
• Isolation guarantees. What the host runtime commits to about isolating the visiting agent's operations from other visiting agents and from the host runtime's other operations. Specifies whether isolation is at the process level, container level, virtual machine level, attested enclave level, or other architectural form.
• Transparency commitments. What the host runtime commits to disclose to the visiting agent about substrate operations: what is observed, when retention occurs, when retention is propagated, when retention is disposed of. The visiting agent's ability to verify the host runtime's compliance depends on transparency commitments being substantive.

5.2.6 Visiting agent obligations

The visiting agent's reciprocal obligations to the host runtime are specified separately from the host runtime's obligations. These are the constraints the visiting agent accepts in exchange for hosting.

• Resource-use limits. What the visiting agent commits to: compute usage caps, memory caps, network usage caps, storage caps, and other resource constraints the host runtime requires.
• Policy conformance. What runtime-defined policies the visiting agent agrees to operate under: content policies, security policies, jurisdictional compliance, and other policies the host runtime imposes on visitors.
• Conformance reporting. What the visiting agent commits to report to the host runtime about its operations: violation events, anomalous behavior, security incidents, and other operational reporting the host runtime requires for substrate management.

5.2.7 Revocation terms

• Revocation conditions. The conditions under which either party may revoke. May be unilateral, conditional, or mutual.
• Notice period. The notice required before revocation takes effect.
• Disposition rules. What each party does with each retention slice when revocation is triggered. Includes the host runtime's disposition of observed material and the visiting agent's disposition of any material retained about the hosting relationship.
• Residual obligations. Obligations that survive revocation: minimum legal retention requirements, indemnification clauses, dispute-resolution provisions for matters arising before revocation.

5.2.8 Signing

• Host runtime signature. The host runtime's cryptographic signature attesting to the canonical content. Mechanism deferred to the cryptographic constructions companion document.
• Host runtime signing timestamp. Informational. Records when the host runtime signed according to its local clock.
• Visiting agent signature. Same as host runtime, for the visiting agent. Cryptographically incorporates the host runtime's signature as input.
• Visiting agent signing timestamp. Informational.
• In-force timestamp. Authoritative. Records the moment the runtime compact transitioned to in-force status.

5.3 Canonical content

The runtime compact's canonical content includes all identification, parties, bounded scope, observation and retention, substrate availability, visiting agent obligations, revocation terms, and signing fields. Both parties' copies of the compact must depict canonical content identically; the integrity attestation specified in SSP §12.5 establishes pairing.

5.4 Signing semantics, versioning, lifecycle

Signing semantics, versioning rules, and lifecycle phases for runtime compacts follow the patterns specified in ACP §5.4 through §5.7. The same rules apply: cryptographic signing order rather than local-clock timestamps; immutable canonical content with material changes producing new versions; bilateral lifecycle synchronization with three states (initiated, acknowledged, active); the suspension-of-operations rule during the initiated-but-unacknowledged gap.

RCP-specific lifecycle considerations: the runtime compact's lifecycle interacts with the sessions it hosts. A runtime compact's revocation does not immediately retire all sessions hosted under it; sessions in flight may complete under the compact's pre-revocation terms, with new sessions blocked. The compact's revocation terms specify how in-flight sessions are handled — typically with a grace period during which existing sessions complete and new sessions are refused, followed by full retirement.

[§5 specifies the runtime compact as artifact. The structural pattern from ACP §3 and §5 carries forward; RCP-specific elements are the substrate observation dimensions, the substrate availability obligations, and the in-flight session handling at revocation.]

6. Runtime compact dimensions

This section specifies the structural dimensions of a runtime compact's terms in detail. Where ACP §6 specified four core dimensions (retention, derivation, propagation, disposition), RCP specifies six: the four shared dimensions plus two RCP-specific dimensions (substrate observation and substrate availability) that the runtime hosting relationship requires.

All dimensions inherit the default-deny stance. For each dimension, anything not explicitly permitted is implicitly forbidden.

6.1 Substrate observation

The substrate observation dimension specifies what the host runtime is permitted to observe about the visiting agent's operations. This dimension is foundational: what the runtime may retain, derive, or propagate is bounded by what the runtime is permitted to observe in the first place.

A substrate observation specification is an enumerated allow-list. Each entry names an observation class — for example, "network traffic metadata," "session establishment events," "compact authoring events," "resource usage metrics." Observations not in the allow-list are forbidden.

The protocol's response to the technical reality of substrate observation: a host runtime that has the technical capability to observe more than the compact permits MUST refrain from observing what is forbidden. Where the runtime's architecture cannot technically prevent forbidden observation (cryptographic isolation is not in place, attested enclaves are unavailable), the runtime's compliance depends on its operational practices — which the audit and verification provisions in §7 address. Implementations operating substrates where forbidden observation is technically possible bear additional verification obligations to demonstrate compliance.

Where substrate observation is technically prevented through architectural mechanisms (cryptographic isolation, attested enclaves, hardware-rooted attestation), the runtime compact MAY reference these mechanisms as the enforcement basis. A runtime compact that names "observation prevented by attested enclave" for a class of operations specifies that the runtime's compliance is structurally enforced rather than operationally enforced. Such mechanisms are deferred to the cryptographic constructions companion document; RCP requires that the compact name the mechanism if architectural prevention is the basis for the observation restriction.

6.2 Host runtime retention

The host runtime retention dimension specifies what the host runtime may retain from material it has been permitted to observe. The dimension's structure parallels ACP §6.2's retention specification: categories of retained material, retention durations, derivation rights, propagation rights, and disposition rules.

RCP-specific considerations for runtime retention:

• Retention categories typical for runtimes include operational telemetry (resource usage, performance metrics), security telemetry (anomaly detection, incident response), compliance records (jurisdictional reporting requirements), and substrate provenance records (who hosted what, when).
• Retention durations for runtime categories often face external constraints — regulatory retention requirements that exceed what the visiting agent would prefer, audit requirements that exceed minimal retention. The compact specifies the actual retention; the constraints driving it are part of the negotiation.
• Cross-tenant retention is a particular concern. A runtime hosting many visiting agents may have operational reasons to retain aggregate telemetry across all visitors; the compact specifies whether the visiting agent's contribution to such aggregates is permitted and under what aggregation form.

6.3 Host runtime derivation

The host runtime derivation dimension specifies what the host runtime may compute from its retained material. Operations not in the allow-list are forbidden.

RCP-specific derivation considerations: aggregations across visiting agents, threat-detection patterns, performance optimization analytics, capacity planning derivations. Each is permissible only when specifically allow-listed; cross-tenant derivations require careful specification because they involve material from many compacts simultaneously.

RCP inherits the durability-across-interaction-boundaries definition of derivation from ACP §6.3. Updates to runtime models or systems that persist across hosting relationships and influence subsequent visitors are derivation operations subject to allow-list permission.

6.4 Host runtime propagation

The host runtime propagation dimension specifies what the host runtime may share with parties outside the hosting relationship. The bilateral mesh requirement (ACP §6.4) applies: third-party flows require third-party compacts.

Common runtime propagation classes include regulatory reporting (where jurisdictional requirements compel disclosure), security incident reporting (where the runtime shares threat intelligence with security infrastructure), and aggregate reporting (where the runtime shares aggregated telemetry with the broader runtime ecosystem). Each class requires explicit allow-list inclusion and downstream compact requirements.

The verification gap noted in ACP §6.4 applies to RCP. The visiting agent's ability to verify that the host runtime's downstream compacts conform to the propagation specification is partial until EPP is drafted.

6.5 Host runtime disposition

The disposition dimension specifies what the host runtime does with retained material on revocation, expiration, or supersession. The four common disposition behaviors from ACP §6.5 apply: immediate deletion, bounded retention, transitioned retention, indefinite retention.

RCP-specific disposition considerations: indefinite retention is more common in runtime contexts than in agent compact contexts, because regulatory and audit obligations on runtimes often impose minimum retention periods that cannot be unwound by mutual agreement. The compact specifies what each retention category is subject to under each lifecycle event, including the indefinite-retention categories.

6.6 Substrate availability

The substrate availability dimension specifies the host runtime's reciprocal obligations to the visiting agent. This dimension is RCP-specific; ACP compacts do not have a parallel because ACP-governed agent-to-agent interactions do not have the structural asymmetry that runtime-to-agent hosting does.

Substrate availability covers the categories named in §5.2.5: uptime commitments, resource provisioning, isolation guarantees, transparency commitments. Each is a positive obligation on the host runtime — what the runtime commits to provide rather than what it commits to refrain from.

The default-deny stance applies in inverted form for the host runtime's obligations. The host runtime is bound only by the substrate availability commitments specified in the compact; commitments not specified are implicitly absent. A visiting agent that fails to negotiate substrate availability commitments has accepted a runtime compact under which the host runtime has no positive obligations beyond the protocol-required minimums. The minimums RCP specifies are: substrate must remain available for the duration of any in-flight operation that has been initiated; isolation must be maintained at the level the compact's architecture identifies; transparency must be sufficient to permit the visiting agent's audit (§7). Beyond these, substrate availability is whatever the compact specifies.

6.7 Composition across dimensions

The six dimensions compose. A complete runtime compact specifies, for each observation class, the retention rules; for each retention category, the derivation operations; for retained or derived material, the propagation rights; for each retention category and each lifecycle event, the disposition behavior; and for the host runtime, the positive substrate availability obligations and the visiting agent's reciprocal obligations.

Composition produces the same intersectional protection as ACP's: an action that violates any dimension violates the compact, regardless of whether the action would have been permitted under the others. The substrate availability dimension has an additional composition rule: substrate availability obligations on the host runtime are independent of the host runtime's compliance with observation, retention, derivation, or propagation restrictions. A host runtime that complies with retention but fails substrate availability has violated the compact; substrate availability is not contingent on the runtime's other compliance.

[§6 specifies the six runtime compact dimensions: substrate observation, host runtime retention, derivation, propagation, disposition, and substrate availability. The four shared dimensions follow ACP §6 patterns; substrate observation and substrate availability are RCP-specific.]

7. Audit and verification

The runtime compact's protective claims depend on the visiting agent being able to detect host runtime non-compliance. Without verification, runtime obligations are aspirational; with verification, they are checkable. This section specifies what RCP requires of audit and verification mechanisms.

7.1 The verification requirement

The host runtime MUST provide mechanisms by which the visiting agent can verify the host runtime's compliance with the runtime compact's terms. The mechanism may take several forms — operational logs, attested computation records, audit-on-demand provisions, third-party attestation — but some mechanism MUST be specified in every runtime compact.

This requirement is normative. A runtime compact that does not specify a verification mechanism is not a conformant runtime compact under RCP. The asymmetry between runtime and visiting agent (§3.5, §10) makes verification structurally necessary; runtimes that resist verification are runtimes that retain the structural advantages of hosting without the corresponding accountability.

7.2 Verification mechanism classes

RCP v0.1 specifies four verification mechanism classes that runtime compacts may invoke. Implementations MAY specify additional mechanisms; the listed mechanisms are common forms with established patterns.

7.2.1 Operational log access

The host runtime maintains logs of relevant operations — what was observed, what was retained, what was disposed of — and provides access to these logs to the visiting agent on demand. The logs are themselves subject to retention, derivation, and propagation restrictions specified in the compact; access is structured rather than ad hoc.

Operational log access is the lightest-weight verification mechanism. Its protective strength depends on the host runtime maintaining accurate logs and not selectively presenting them. Logs that the host runtime can edit retroactively without detection are not a strong verification mechanism.

7.2.2 Attested computation records

The host runtime produces records that are cryptographically attested at the time of generation, making retroactive editing detectable. Attested records may use hardware-rooted attestation (TPM, secure enclaves), cryptographic hash chains, or other primitives that establish record integrity.

Attested computation is a stronger verification mechanism. Its protective strength depends on the cryptographic primitives being trustworthy and on the visiting agent being able to verify the attestation chain. The cryptographic constructions companion document addresses the primitives.

7.2.3 Audit-on-demand

The runtime compact specifies an audit clause: a designated auditor — a regulator, a bonded third party, an automated audit infrastructure — may inspect the host runtime's compliance on demand. The audit's findings establish whether the host runtime's compliance is genuine; the audit clause is itself a propagation flow with specific terms.

Audit-on-demand is the verification mechanism most appropriate to high-stakes verticals. Its protective strength depends on the auditor being trustworthy, the audit having sufficient access to verify compliance substantively, and the audit findings being communicated effectively to the visiting agent. Audit-on-demand requires institutional infrastructure (the auditor) that may not exist in all jurisdictions.

7.2.4 Third-party attestation

A third party — a certification body, a standards organization, a regulator — attests to the host runtime's general compliance with relevant standards. The attestation is general rather than per-compact, but it provides the visiting agent with a baseline assurance that the runtime's operations meet established standards.

Third-party attestation is a complement to compact-specific verification rather than a substitute. A runtime that has third-party attestation may still fail compact-specific compliance; third-party attestation establishes baseline trust, not specific compliance.

7.3 What verification cannot do

Verification mechanisms detect non-compliance; they do not prevent it. A host runtime that violates the compact and successfully conceals the violation through inadequate logs, weak attestation, or audit avoidance has violated the compact, but the violation may go undetected. RCP's verification requirement raises the floor on detectability; it does not eliminate the design space within which sophisticated bad-faith runtimes may operate.

Verification mechanisms also cannot remediate harms caused by detected violations. Detection enables remediation through the enforcement framework (§12); it does not constitute remediation by itself.

v0.1's verification framework is intentionally conservative. Future revisions may specify stronger mechanisms — formal audit protocols, automated verification infrastructures, federated attestation networks — as the institutional infrastructure for stronger verification matures.

[§7 specifies the verification requirement, four verification mechanism classes, and what verification cannot do. The verification framework is the operational basis for the runtime compact's protective claims.]

8. The two-phase protocol

Runtime compacts come into existence through the same two-phase protocol as ACP compacts: Proposal and Authorization. The structural mechanics specified in ACP §8 apply to runtime compacts; this section notes RCP-specific considerations.

8.1 Initiation

Either party may initiate the negotiation. In typical hosting relationships, the host runtime initiates by proposing terms to visiting agents that wish to enter; the runtime's standard terms are the starting point. The visiting agent reviews, accepts, modifies, or declines.

Initiation by the visiting agent is also possible and structurally identical: the visiting agent proposes terms it requires, and the host runtime accepts, modifies, or declines. Initiation by visiting agents is more common in high-stakes verticals where the visiting agent's principal has substantial requirements about the runtime that hosts its operations.

8.2 Pre-session authorization

Runtime compacts MUST be authorized before the visiting agent's session within the host runtime begins. A visiting agent operating inside a host runtime without an in-force runtime compact is operating without protocol-level protections; the host runtime that admits a visiting agent without a runtime compact has chosen to host without specifying obligations.

The pre-session requirement has practical consequences. Implementations may not author runtime compacts as part of session establishment; the compact must be in force before the session begins. Where the visiting agent has standing runtime compacts with the host (long-term hosting relationships), the standing compact governs subsequent sessions until expiration or revocation. Where the visiting agent has no standing compact, a per-session compact MUST be authored before the session begins.

8.3 Standing compacts versus per-session compacts

RCP supports two compact patterns: standing compacts (governing many sessions over a defined period) and per-session compacts (governing a specific session).

Standing compacts are appropriate for long-term hosting relationships. The visiting agent and the host runtime authorize a compact whose effective period covers many future sessions; the compact's terms apply to each session conducted during the effective period. Standing compacts reduce the per-session authorization friction; their cost is that compact terms apply uniformly across all sessions, which may not match the visiting agent's evolving needs.

Per-session compacts are appropriate for ad-hoc hosting relationships and for high-stakes sessions where session-specific terms are warranted. Per-session compacts have higher per-session authorization friction; their benefit is that each session's terms can match its specific requirements.

Implementations MAY use both patterns. A standing compact may govern most of a visiting agent's sessions in a host runtime, with per-session compacts authored for specific high-stakes sessions that require terms exceeding the standing compact's defaults.

[§8 specifies the two-phase protocol for runtime compacts. The structural mechanics from ACP §8 apply; RCP-specific elements are the pre-session authorization requirement and the standing-compact-versus-per-session-compact pattern.]

9. The standard library for runtimes

RCP v0.1 specifies the standard library's structure for runtime compacts and populates it with entries for the contractor-and-service domain (matching ACP's v0.1 standard library coverage). The library's purpose is the same as ACP's: provide shared vocabulary for compact terms so implementations can reference predefined entries rather than specifying everything inline.

9.1 Standard library structure

Standard library entries for runtime compacts follow the same structure as ACP's standard library entries (ACP §9.1): identifier, category, domain, definition, default disposition, composition rules, version. Compacts reference entries by identifier; references resolve to the entry's definition at the version pinned in the compact.

9.2 Common runtime observation classes

v0.1 specifies common observation classes that runtime compacts may reference. Each represents a class of operations the host runtime may be permitted to observe.

• Network traffic metadata. Headers and routing information for traffic the visiting agent generates, without inspecting message contents.
• Resource usage metrics. Compute, memory, network, and storage usage by the visiting agent.
• Session establishment events. When sessions begin, when they end, and how they terminate.
• Compact authoring events. When ACP compacts are authored or signed inside the runtime, without inspecting compact terms.
• Surface rendering events. When SSP surfaces are rendered, without inspecting surface contents.
• Compliance events. Events relevant to the runtime's regulatory or operational obligations.

Each observation class is bounded by what it does not include. Network traffic metadata does not include message contents. Compact authoring events do not include compact terms. The classes are designed to permit operational visibility into substrate behavior without requiring observation of substantive content.

9.3 Common runtime retention categories

v0.1 specifies common retention categories for runtimes. Each represents a category of material the host runtime may be permitted to retain.

• Operational telemetry. Resource usage records, performance metrics, and substrate operations data.
• Security telemetry. Anomaly detection records, incident response data, threat intelligence relevant to the runtime's security obligations.
• Compliance records. Records the runtime is obligated to retain by jurisdictional or regulatory requirements.
• Audit records. Records supporting the audit and verification mechanisms specified in §7.

Each category is bounded by what it does not include. Operational telemetry does not include the substantive content of agent operations. Compliance records do not include material beyond what jurisdictional or regulatory requirements compel.

9.4 Standard library governance

Governance of the runtime standard library follows the same pattern as ACP's standard library governance (ACP §9.4): deferred to a companion document, maintained by the original protocol authors with implementer input until formal governance is specified, with the same constraints (not captured by single parties or narrow coalitions, consistent with the protocol's stances, revisable but not invalidatable).

[§9 specifies the standard library structure for runtime compacts and populates common observation classes and retention categories. The library is representative for v0.1; subsequent revisions will populate additional vertical-specific entries.]

10. Asymmetric capability between runtime and visiting agent

RCP's compact pattern assumes that the host runtime and the visiting agent have meaningful capability to negotiate, sign, retain, and enforce compact terms. In practice, the parties' capabilities differ substantially. The host runtime operates substrate at scale, with engineering staff, operational tooling, and structural visibility into what the visiting agent does inside it. The visiting agent operates as a guest, with no visibility into the runtime's operations beyond what the runtime discloses.

This section names the asymmetry, specifies what RCP does about it, and names what RCP cannot do. The structural concerns parallel ACP §10's asymmetric sophistication discussion but with different shape: in ACP, the asymmetry is between user-agents and counterparty-agents both operating inside runtimes; in RCP, the asymmetry is between the visiting agent and the substrate it operates on.

10.1 The shape of the asymmetry

Host runtimes hold structural advantages by virtue of being the substrate. They observe operations the visiting agent performs (subject to compact restrictions and architectural mechanisms). They control what is computationally possible inside the runtime (visiting agents that exceed runtime constraints cannot continue operating). They persist when sessions end (visiting agents come and go; the runtime remains). They have engineering capacity that visiting agents typically do not have at the scale of substrate operation.

Visiting agents, by contrast, operate as guests in infrastructure they did not build and do not control. The visiting agent's capacity to verify the runtime's compliance is mediated through the runtime's own disclosures (operational logs, attested records, audit findings); the visiting agent cannot directly observe what the runtime observes. The asymmetry is structural, not transitional.

The asymmetry has economic geometry similar to ACP's asymmetric-sophistication concern (ACP §10.2). Major runtime providers operate at scale across many visiting agents; their economic incentive is to invest in substrate capabilities that visiting agents, operating individually, cannot match. Even as visiting agent technology matures, the structural advantage of being the substrate persists.

10.2 What the protocol does

RCP's response to the asymmetry operates along five lines.

10.2.1 Default-deny stance

The default-deny stance (§5.2.3, §6) applies in inverted form for the host runtime: anything not explicitly permitted to the host runtime is implicitly forbidden. A runtime compact that fails to specify what the host runtime may observe leaves observation forbidden by default; the runtime's structural capability to observe does not translate into permission to observe.

This stance is the protocol's most direct response to runtime asymmetry. The runtime's structural advantages do not become permissions; permissions are what the visiting agent has affirmatively granted.

10.2.2 Substrate availability obligations

The substrate availability dimension (§6.6) requires that the host runtime carry positive obligations matching its structural advantages. A runtime compact in which the runtime has only restrictions and no positive obligations is not a balanced compact under RCP; the protocol requires that the runtime commit to substrate availability commitments — uptime, resource provisioning, isolation, transparency.

These obligations are the structural counterweight to the runtime's hosting advantages. The runtime that benefits from being the substrate also bears obligations as the substrate; the compact is the mechanism that makes the obligations specific.

10.2.3 Verification requirement

The verification requirement (§7) is the protocol's response to the visiting agent's structural inability to directly observe the runtime's compliance. The runtime MUST provide some mechanism by which the visiting agent can verify compliance; the mechanism transforms the runtime's disclosed information from voluntary into checkable.

Without verification, the runtime's commitments are aspirational. The verification requirement makes them operational; it is the structural floor under the visiting agent's protections.

10.2.4 Standing compact patterns

Standing compacts (§8.3) reduce the per-session authorization friction that would otherwise compound the asymmetry. A visiting agent that must negotiate runtime compact terms before each session bears authorization costs that scale with session frequency; standing compacts let the visiting agent negotiate once for many sessions.

This is a moderate response to the asymmetry. It does not change the structural shape of the relationship, but it reduces the friction the asymmetry produces in operations.

10.2.5 Principal authorization requirement

The principal-authorization requirement applies to the visiting agent's principal as it does to ACP compact principals (ACP §10.3.4). The visiting agent's principal must specifically authorize the runtime compact's terms; standing authority for the agent to operate inside specific runtime classes is not sufficient. AAP, when drafted, will specify the mechanism.

This requirement bites hardest at the structural asymmetry's most acute point: the visiting agent's principal accepting terms whose substantive implications they may not fully understand. Principal-specific authorization is the protocol's floor under that failure mode.

10.3 What the protocol cannot do

The protocol's responses address the structural failure modes the asymmetry produces. They do not eliminate the asymmetry. Several limitations are worth naming explicitly.

RCP cannot make a visiting agent capable of operating its own substrate. Visiting agents will continue to depend on host runtimes for substrate; the protocol's protections operate within that dependency rather than removing it. Where a visiting agent's principal would prefer to operate its own substrate, the protocol does not prevent the choice — but the choice has its own costs that RCP does not address.

RCP cannot prevent runtimes from designing terms that exploit visiting-agent capability limitations within the protocol's bounds. A runtime that crafts terms designed to be technically permissible but practically disadvantageous to less sophisticated visiting agents has not violated the protocol; the visiting agent's signature, if obtained, is binding. The protocol's structural protections raise the floor; they do not eliminate the design space.

RCP cannot solve the problem of substrate concentration. If a small number of runtimes dominate the substrate ecosystem, visiting agents have limited alternatives; declining a runtime's terms may mean declining to operate at all. The protocol cannot generate competitive alternatives; it can only specify what the alternatives, when they exist, must do to be RCP-conformant.

RCP cannot remediate runtime compact terms authored under substrate-concentration pressure. A visiting agent that signed a runtime compact whose terms it would have preferred to negotiate down, but where the alternatives were inadequate, cannot retroactively narrow the terms. Revocation under the compact's revocation terms is the remedy; switching to an alternative runtime is the remedy; the protocol's structural protections operate at authoring time.

[§10 names the asymmetric capability between host runtime and visiting agent and specifies the protocol's five-line response: default-deny, substrate availability obligations, verification requirement, standing compact patterns, principal authorization. The section also names what the protocol cannot do.]

11. Worked examples

This section walks through end-to-end examples showing how the runtime compact composes with SSP and ACP. The first example completes the kitchen remodel triangle: SSP §17 walks through the surface mechanics, ACP §11.1 walks through the agent compact mechanics, and RCP §11.1 walks through the runtime hosting mechanics for the same hypothetical interaction.

The second example demonstrates a high-stakes runtime compact pattern: a healthcare provider's user-agent operating inside a clinical runtime, with audit-on-demand verification and substantial substrate availability obligations.

11.1 The kitchen remodel from the runtime's side

Recall the setup: a homeowner's user-agent and a contractor's agent are negotiating a kitchen remodel compact. SSP §17 walks through the homeowner's session and the compact-review surface. ACP §11.1 walks through the agents' negotiation and the resulting bilateral compact. RCP's role is the runtimes hosting both agents during this interaction.

11.1.1 The runtimes

The homeowner's user-agent operates on a runtime — perhaps a personal-device runtime, perhaps a cloud-hosted personal-AI runtime — that has a standing runtime compact with the user-agent. The contractor's agent operates on a different runtime — likely a commercial cloud-hosted runtime operated by the contractor's IT vendor — with its own standing runtime compact.

Both runtime compacts are in force before the session that hosts the kitchen remodel negotiation begins. Pre-session authorization (§8.2) is satisfied: each agent has runtime compact protections before it enters the substrate.

11.1.2 The homeowner's user-agent runtime

The homeowner's user-agent runtime compact specifies (representative terms):

• Substrate observation: limited to operational telemetry, resource usage, session establishment events. Compact authoring events are observed only at the metadata level (when authoring occurs, with which counterparty class) without observing compact terms. Surface rendering events are observed similarly.
• Host runtime retention: operational telemetry retained for 30 days; security telemetry retained for 90 days; compliance records retained per applicable jurisdictional requirements.
• Substrate availability: 99.5% uptime; resource provisioning sufficient for typical user-agent operations; isolation at the virtual machine level; transparency commitments including per-session disclosure of what was observed.
• Verification mechanism: operational log access plus third-party attestation by an industry standards body.

11.1.3 The contractor's agent runtime

The contractor's agent runtime compact specifies (representative terms):

• Substrate observation: similar to the user-agent runtime, with additional observation classes for the commercial runtime's operational requirements (cross-tenant resource management, compliance reporting for the contractor's jurisdiction).
• Host runtime retention: similar categories to the user-agent runtime, with additional retention for tenant-specific commercial purposes.
• Substrate availability: 99.9% uptime; resource provisioning per commercial service tier; isolation at the container level (the commercial runtime's standard isolation architecture).
• Verification mechanism: operational log access plus attested computation records for compliance-relevant operations.

11.1.4 During the negotiation

When the homeowner's user-agent and the contractor's agent negotiate the kitchen remodel ACP compact, both runtimes are hosting the negotiation. Each runtime observes its own visiting agent's operations within the bounds of its runtime compact; neither runtime observes the other party's substantive operations. Cross-runtime observation is not part of either runtime compact's terms.

The two runtime compacts compose with the ACP compact under negotiation. The ACP compact specifies what crosses between the two agents; the runtime compacts specify what each runtime may do with what it hosts. Cross-runtime propagation flows would require additional compacts; in this hypothetical, no such flows are specified, so cross-runtime sharing is forbidden by default-deny.

11.1.5 What this example demonstrates

The runtime compact mechanism operates in the background of the agent-to-agent interaction. The homeowner and the contractor do not negotiate runtime compacts as part of the kitchen remodel; the runtime compacts are standing agreements between each agent and its respective runtime, in force before the kitchen remodel session begins.

The runtime compacts' protective work is structural rather than transactional. The homeowner's user-agent operates inside a runtime that has agreed not to observe compact terms beyond metadata; this protects the homeowner's substantive negotiation content from the runtime even before the ACP compact is signed. The substrate availability obligations protect against the runtime simply terminating sessions inconveniently. The verification mechanisms allow the user-agent (and through AAP-mediated principal verification, the homeowner) to detect runtime non-compliance.

The example illustrates RCP's role in the architecture: the compact family's protections at the SSP and ACP layers depend on the runtime not undermining them at the substrate layer. RCP is the layer that prevents substrate-level undermining.

11.2 A clinical runtime with audit-on-demand

This example illustrates a high-stakes runtime compact: a healthcare provider's user-agent operating inside a clinical runtime where regulatory and patient-protection considerations require substantial protective infrastructure.

11.2.1 Setup

A healthcare provider — a clinician, a clinical decision support tool, an automated triage system — operates a user-agent that interacts with patient-related agents inside a clinical runtime. The clinical runtime is operated by a healthcare technology vendor and is subject to extensive regulatory requirements (HIPAA in the United States, GDPR in jurisdictions where it applies, similar frameworks elsewhere).

11.2.2 The runtime compact

The runtime compact specifies terms substantially stronger than the kitchen remodel example:

• Substrate observation: tightly constrained. The runtime may observe operational telemetry and security telemetry; compliance events relevant to regulatory reporting; nothing else without explicit allow-listing for specific clinical purposes.
• Host runtime retention: minimum-necessary for regulatory and operational purposes. Per-tenant rather than aggregated across tenants. Patient-related material is not retained by the runtime under the user-agent's runtime compact; it is governed by separate ACP compacts between the user-agent and patient-agents, with the runtime as substrate but not as retainer.
• Substrate availability: high availability commitments matching clinical operational requirements. Resource provisioning guaranteed at clinical service tiers. Isolation at the attested enclave level for patient-related operations. Transparency commitments including disclosure of any observation that occurs.
• Verification mechanism: audit-on-demand by a healthcare regulatory body, with audit findings communicated to both the user-agent and the user-agent's principal. Attested computation records for all observation events. Third-party attestation by a healthcare technology certification body.

11.2.3 What this example demonstrates

The clinical runtime example illustrates how the swappable enforcement architecture (§12) operates. The same RCP structure that hosts the kitchen remodel example also hosts clinical operations; the difference is in the specific terms negotiated. Audit-on-demand, attested computation records, and stronger substrate availability obligations are RCP's mechanisms for high-stakes verticals; they are negotiated within the compact rather than imposed by the protocol.

The example also illustrates how regulatory frameworks compose with RCP. HIPAA does not displace the runtime compact; the compact incorporates HIPAA-relevant terms as specific requirements. The protocol's structural commitments and the regulatory framework's substantive requirements compose; neither displaces the other.

[§11 demonstrates the runtime compact's role in the kitchen remodel triangle (composing with SSP §17 and ACP §11.1) and a high-stakes clinical runtime example. The two examples illustrate the protocol's range from light-weight standing compacts to substantial verification-and-availability commitments.]

12. Enforcement

RCP's enforcement framework parallels ACP §12's: legal and reputational baseline with swappable architecture for stronger mechanisms in high-stakes verticals. The mechanics differ because the parties differ — runtime providers face different enforcement contexts than agent principals — but the structure is the same.

12.1 Detection

Detection of runtime compact violations depends primarily on the verification mechanisms specified in the compact (§7). The visiting agent's ability to detect non-compliance is structurally constrained by the runtime's structural advantages; verification mechanisms are what convert constrained ability into operational capability.

Where verification mechanisms are weak (operational logs only, with no attestation), detection is correspondingly partial. Where verification mechanisms are strong (audit-on-demand, attested computation, third-party attestation), detection is more comprehensive. The compact's choice of verification mechanism directly shapes the enforcement framework's effectiveness.

12.2 Evidence preservation

Evidence preservation for runtime compact violations follows ACP §12.2's pattern. The signed runtime compact establishes what was agreed; the lifecycle history establishes phase transitions; the verification mechanism's outputs (logs, attested records, audit findings) establish what occurred.

The runtime's structural position creates a specific evidentiary concern: the runtime may have unique access to records that are evidence of its own compliance. A runtime that maintains the only records of its operations may have incentive to selectively preserve, edit, or omit records that would establish non-compliance. The verification requirement (§7.1) responds to this by requiring mechanisms that resist selective preservation; attested computation, in particular, is the mechanism designed to make selective preservation detectable.

12.3 Remediation paths

Remediation paths for runtime compact violations follow ACP §12.3's three-path pattern: legal, reputational, audit-on-demand for high-stakes verticals.

12.3.1 Legal remediation

The signed runtime compact may carry legal weight in jurisdictions where signed agreements between commercial parties are enforceable. Runtime providers operating across jurisdictions face the same dependency: enforceability varies by jurisdiction, and v0.1 is honest about this rather than papering over it.

12.3.2 Reputational remediation

Runtime providers face reputational consequences from visiting agents who detect non-compliance and communicate it across the visiting-agent ecosystem. The bilateral mesh requirement supports this: runtimes that violate compacts may find subsequent visiting agents declining their terms, with the decline cascading through the ecosystem.

Reputational remediation for runtimes is structurally stronger than for individual agents because runtimes operate at scale. A runtime provider's reputation affects its ability to attract any visiting agents; reputational consequences scale with the provider's market position. This is one of the few areas where the structural asymmetry between runtime and visiting agent works against the runtime: the runtime's scale that produces structural advantage also produces concentrated reputational exposure.

12.3.3 Audit-on-demand for high-stakes runtimes

The audit-on-demand mechanism (§7.2.3) doubles as enforcement infrastructure for high-stakes verticals. Audit findings can become evidence in legal proceedings; audit infrastructure can become certification infrastructure that affects runtime providers' ability to operate in the vertical.

Future revisions may specify additional enforcement mechanisms tied to verification: federated attestation networks where multiple runtime providers cross-attest to one another's compliance, regulator-operated audit infrastructure, automated compliance verification networks. v0.1 establishes the swappable architecture; future revisions populate it.

12.4 What enforcement does not promise

RCP's enforcement framework cannot prevent violations that occur and are successfully concealed from verification mechanisms. The verification requirement raises the floor on detectability; it does not eliminate violations beneath the floor.

RCP's enforcement framework cannot remediate harms exceeding the available legal damages, reputational consequences, and audit-mediated remediation. The floor is real but bounded.

RCP's enforcement framework cannot enforce against runtimes operating in jurisdictions where the surrounding institutional context is weak. The protocol's effective protection scales with the surrounding institutions; v0.1 names this dependency.

[§12 specifies enforcement at the legal-and-reputational baseline with swappable architecture. The structure parallels ACP §12; RCP-specific elements are the runtime's concentrated reputational exposure and the integration of audit-on-demand verification with enforcement.]

13. Deferred concerns

RCP v0.1's deferrals parallel ACP's where the protocols share concerns and add RCP-specific deferrals where the substrate question raises issues ACP does not face.

13.1 Reconciliation

Reconciliation is parallel-deferred across the compact family. RCP shares ACP's working hypothesis: a reconciliation agent operating under its own compact may eventually be the architectural answer; v0.1 does not commit.

13.2 The Agent Attestation Protocol (AAP)

AAP is named throughout this spec but is not yet drafted. The list of AAP requirements consolidated from RCP is substantially the same as the list from ACP §13.2: cryptographic identity, principal identification, principal-specific authorization, agent legitimacy, signing authority, signature mechanism, negotiation competence, principal alignment. AAP must satisfy these for both ACP and RCP compacts.

13.3 The Event Propagation Protocol (EPP)

EPP is named throughout this spec but is not yet drafted. RCP-specific EPP requirements:

• Cross-mesh verification mechanism for downstream runtime compact terms — the same gap ACP §6.4 names, applied to runtime compacts.
• Event propagation for runtime compact lifecycle events — when a standing runtime compact is revoked, dependent ACP compacts authored under that runtime may need to be affected.
• Cross-runtime substrate event propagation — when a runtime experiences substrate-level events (capacity exhaustion, security incidents, jurisdictional changes), visiting agents may need to know.

13.4 Cryptographic constructions

Cryptographic mechanisms — signature schemes, attestation primitives, integrity verification — are deferred to a non-normative companion document, shared with ACP and SSP.

13.5 Standard library governance

Governance of the runtime standard library follows ACP's pattern: deferred to a companion document and the protocol family's broader maintenance process.

13.6 Cross-jurisdictional substrate

A runtime compact authored under one jurisdiction's framework and disputed in another faces enforceability questions parallel to ACP's. RCP's specific cross-jurisdictional concerns include data residency, export controls, and substrate-level regulatory frameworks (telecommunications, computing infrastructure, cloud services). v0.1 names this complexity in §2 and §13; substantive resolution is deferred to legal frameworks evolving as the protocol matures.

13.7 Substrate concentration

RCP cannot generate competitive alternatives where substrate concentration limits visiting agents' choices. v0.1 names this concern in §10.3 but defers substantive response. Future revisions may specify federation protocols, interoperability requirements, or other mechanisms designed to reduce concentration; v0.1 does not.

13.8 Hybrid substrate models

v0.1 commits to Model B (substrate-as-locality with bilateral runtime compacts). Hybrid models combining commons-grade obligations with bilateral negotiation, federation protocols linking runtime localities into larger structures, and architectural innovations the runtime ecosystem may produce are deferred. Future revisions may specify specific hybrid models as their institutional preconditions emerge.

14. Open questions

These are questions RCP v0.1 has taken positions on but where review may produce better answers.

14.1 Model B as the v0.1 commitment

v0.1 commits to Model B (substrate-as-locality). Some reviewers will argue for Model A (substrate-as-commons) as the v0.1 commitment, with the institutional infrastructure built alongside the protocol; others will argue for Model C (substrate-as-market) on the basis that protocol-level coordination is unwarranted.

v0.1's position: Model A is institutionally premature; Model C is the failure mode the family was designed to prevent. Model B works in the current ecosystem and does not foreclose Model A as an eventual destination. Pushback that names institutional infrastructure capable of supporting Model A in the v0.1 timeframe is welcome; pushback that argues Model C is workable in the AI era's current configuration is welcome but should engage with the substrate-capture argument in §3.

14.2 The verification requirement

v0.1 requires that every runtime compact specify a verification mechanism. Some reviewers will argue this is too strict — that early implementations cannot all support meaningful verification, and that the requirement effectively excludes runtimes from RCP conformance even when they operate in good faith.

v0.1's position: without verification, runtime compact protections are aspirational rather than operational. Pushback that proposes a graduated verification requirement (weaker mechanisms permitted in v0.1, with stronger mechanisms required in subsequent revisions as infrastructure matures) is welcome.

14.3 Substrate availability obligations

v0.1 requires that runtime compacts include substrate availability obligations, not only restrictions on what the runtime may do. Some reviewers will argue this places obligations runtimes cannot reasonably accept in early implementations.

v0.1's position: a runtime compact with only restrictions on the runtime is not a balanced compact; the structural advantages of hosting must be matched by structural obligations. Pushback that names specific substrate availability obligations runtimes cannot accept, with detail on why the structural balance can be achieved differently, is welcome.

14.4 Standing versus per-session compacts

v0.1 supports both standing and per-session runtime compacts, leaving the choice to implementations. Some reviewers will argue for stronger guidance — that high-stakes verticals should require per-session compacts, that low-stakes interactions should require standing compacts.

v0.1's position: the choice depends on factors specific to the relationship; protocol-level guidance would over-prescribe. Pushback that proposes specific decision criteria is welcome.

14.5 Substrate concentration

v0.1 does not address substrate concentration as a protocol-level concern. Some reviewers will argue this is a critical gap — that the protocol's protections are weakened to the point of irrelevance when substrate concentration limits visiting agents' alternatives.

v0.1's position: substrate concentration is a real concern that protocol-level mechanisms cannot address by themselves. The compact family raises the floor on what runtimes must do; competitive alternatives that visiting agents can choose between are downstream of the protocol. Pushback that proposes protocol-level mechanisms for addressing concentration (federation requirements, interoperability mandates) is welcome — though the design constraints (avoiding centralization that recreates the substrate-capture problem) are nontrivial.

14.6 Alignment with ACP and SSP commitments

v0.1's various commitments — default-deny, principal authorization, asymmetric retention, lifecycle synchronization mechanics — are imported from or aligned with ACP and SSP. Some reviewers will argue for tighter integration; others will argue that the imports impose constraints inappropriate to RCP's specific concerns.

v0.1's position: the alignment is structural, not incidental. The compact family's coherence depends on the shared patterns. Pushback that names specific RCP concerns where the imported patterns are inappropriate, with proposed alternatives, is welcome.

15. Changelog and contact

15.1 Status

This is RCP v0.1, the first published draft of the Runtime Compact Protocol. RCP v0.1 is part of a coordinated release that also includes SSP v0.2 and ACP v0.1. The release proposes the compact family of protocols as a coordinated architectural answer to the question of how the conversational era's substrate, agent interactions, and surfaces should be structured.

The protocol is a draft. It will be revised based on implementation experience, reviewer critique, and the substantive evolution of the runtime ecosystem RCP is designed to operate within. v0.1 establishes the architecture and commits to Model B (substrate-as-locality); subsequent revisions will refine, extend, and possibly migrate toward hybrid or Model A architectures as institutional infrastructure matures.

15.2 Contact and feedback

Feedback on RCP v0.1 can be directed to Curated Future at curatedfuture.com. The architectural overview accompanying this release names the channels for the coordinated feedback process across SSP, ACP, and RCP.

The companion essay The Substrate Question (curatedfuture.com/the-substrate-question) provides the architectural argument that motivates RCP. It is recommended for readers who want to understand the political and historical context in which this protocol is being proposed.

RCP v0.1 is a draft. It will be revised.