Full and Partial Agent Interoperability: Cross-Boundary Semantic Exchange Under Policy

Mechanism

Agent interoperability under the present system rests on three jointly necessary structural artifacts: a shared canonical schema specifying the field set, types, and provenance fields every conforming agent object must carry; a shared semantic exchange protocol specifying the message envelopes, predecessor references, and acknowledgement semantics by which conforming agents exchange those objects; and a structural admission layer at the execution-platform boundary that verifies any incoming or outgoing agent object against the schema and protocol before admitting it for cross-boundary effect. The admission layer is not advisory and is not optional. An agent object that fails admission is refused with a structured rejection record that itself enters the lineage graph, so the act of refusal is auditable to the same standard as the act of admission.

Cross-boundary exchange is initiated when a delegating agent in one administrative or vendor domain emits a delegation envelope addressed to an agent in another domain. The delegation envelope carries the substantive request, a content-addressed reference to the authorizing policy under which the delegation is asserted, the lineage predecessor reference identifying the delegating agent's record from which the delegation derives, and a typed completeness descriptor declaring which schema subset the delegating agent claims to satisfy. The receiving execution platform admits the envelope only if its schema-compliance check succeeds against the declared completeness descriptor, the policy reference resolves to an instance the receiving platform recognizes as in force, and the protocol-level invariants of the envelope are satisfied. If any of these checks fail, the envelope is refused.

Full and partial interoperability are distinguished structurally. A full agent is one whose schema-compliance check succeeds against the entire canonical schema; a partial agent is one whose check succeeds against a configured subset, with the configured subset itself a typed enumeration drawn from a published list of admissible subsets. Partial agents may participate in cross-boundary exchange only for those operations whose schema requirements lie within their declared subset; operations requiring fields outside the subset are refused at admission with a structured rejection citing the missing field set. This convention permits resource-constrained or specialized agents to participate without compromising the structural guarantees other participants depend on, because the subset declarations and the operations they admit are both formal objects subject to verification.

The semantic exchange protocol carries semantic intent rather than merely syntactic payload. Each envelope expresses, in addition to its substantive request, a typed intent descriptor identifying the class of action requested (query, mutation, delegation, attestation, retraction, and the configured extensions thereof), and the receiving platform's admission layer evaluates the request against the schema requirements specific to that intent class. This typing of intent is what permits the system to refuse non-compliant agents at admission rather than at a downstream point of failure: the schema requirements for each intent class are known in advance, the envelope's intent declaration is mandatory, and the admission layer's check is a deterministic function of the two.

Refusal of a non-compliant agent is itself a first-class operation. When an envelope fails admission, the receiving platform emits a structured rejection record that names the specific schema rule, protocol invariant, or policy reference that failed, and that record is committed to the lineage graph with a typed predecessor edge to the refused envelope. The originating agent is informed by a return envelope carrying the same rejection record. Because the rejection is recorded and signed, no later party can claim that an admission silently succeeded or silently failed; the disposition of every cross-boundary exchange is auditable. This property is what permits the system to claim that non-compliant agents are refused by construction: the construction is the admission layer plus the typed rejection record, and there is no path that bypasses both.

The completeness descriptor carried by every cross-boundary envelope is a typed structural object, not a free-form capabilities advertisement. The descriptor names a specific subset profile from a published whitelist, and the receiving platform's admission layer evaluates the envelope's substantive content against the schema requirements that the named profile is required to support. An envelope whose declared profile is not on the receiving platform's admissible list is refused without further evaluation; an envelope whose declared profile is admissible but whose substantive content references fields outside the profile is refused with a typed rejection citing the field violation. This convention prevents an originating agent from opportunistically expanding the admission contract by emitting envelopes whose content presupposes capabilities the receiving platform did not undertake to support.

The intent typing of envelopes is enforced symmetrically. An envelope declaring an intent class outside the receiving platform's I_admit whitelist is refused with a typed intent-rejection record, even if the envelope's substantive content would have been admissible under a different intent declaration. This prevents an attempted laundering of capability through intent reclassification, and it ensures that the receiving platform's intent admission contract is honored without dependence on the originating agent's good faith. The mechanism's overall posture is one in which the receiving platform's contract is authoritative and the originating agent's claims are subject to verification against it, rather than the cooperative-population posture of conventional standards-based agent communication.

The signature commitment carried by every envelope is a per-agent identity signature whose verification key is itself a record in the lineage graph, anchored to the deployment manifest. An envelope whose signature does not verify, or whose declared agent identity is not registered in the lineage graph as known to the receiving platform, is refused with a typed identity-rejection record. The convention permits the receiving platform to refuse not only ill-formed envelopes but envelopes from agents the deployment has not undertaken to recognize, and to record those refusals as auditable predecessors so that later disputes about whether a particular agent's traffic was ever admitted can be resolved by reference to the graph rather than by reference to operational logs maintained outside the schema.

Bidirectional admission is necessary because cross-boundary exchange is symmetric in its trust posture. The originating platform must be willing to admit the receiving platform's response envelopes against the same schema and protocol invariants under which it emitted the request, and the response envelopes themselves carry completeness descriptors, intent declarations, signature commitments, and policy references against which the originating platform performs its own admission check. A response that the originating platform refuses is itself a recorded rejection, with the boundary admission record committed to the originating platform's lineage and a typed return envelope carrying the rejection back to the receiving platform. The structural symmetry ensures that no party in a cross-boundary exchange enjoys a privileged position from which to inject non-compliant content; admission is everywhere structural and everywhere recorded.

Operating Parameters

The interoperability runtime exposes a defined set of operating parameters governing the strictness, scope, and performance envelope of admission. The schema version, denoted Sigma_v, is a deployment-time parameter naming the canonical schema instance against which admission is evaluated; agents declaring a different schema version are admitted only if a configured compatibility predicate maps their declared version to Sigma_v. The completeness-subset whitelist, denoted C_admit, enumerates which partial-completeness subsets the deployment will accept; deployments may set C_admit to the full set of published subsets to maximize participation or to a restricted set to enforce capability floors.

The intent-class whitelist, denoted I_admit, enumerates which intent classes the deployment will accept across the boundary; high-trust deployments may admit the full intent set including mutations and retractions, while low-trust deployments may admit only queries and attestations. The policy-reference resolver parameter, denoted Rho, specifies the resolver chain used to verify that an envelope's policy reference resolves to an instance in force; the resolver chain may include local caches, federated registries, and verification of cryptographic policy commitments, with the resolution result itself recorded as a predecessor of the admission record.

The admission-latency bound, denoted Tau_admit, specifies the maximum wall-clock time the admission layer will spend evaluating an envelope before declaring a deterministic timeout outcome and emitting a typed timeout-rejection record; this bound exists to prevent an adversary from blocking the boundary by submitting envelopes that induce unbounded resolver work. The rejection-record retention parameter governs how long structured rejection records remain materialized in the lineage graph before storage-layer pruning, with the proviso that pruning preserves a digest commitment so that later challenges to specific rejections can be proven or disproven against the preserved digest.

The cross-boundary signing-key parameter specifies the agent identity keys whose signatures the receiving platform will admit; these keys are themselves recorded in the lineage graph as registration records anchored to the deployment manifest. The interoperability mode parameter, finally, selects between strict-mode admission, in which any deviation from the schema or protocol invariants is grounds for refusal, and tolerant-mode admission, in which a configured set of forward-compatibility relaxations is permitted; tolerant-mode is intended for transitional deployments and the relaxation set is itself a parameter recorded in the deployment manifest so that later auditors can determine which relaxations were in force when a given exchange was admitted.

The negotiation-window parameter, denoted Nu, governs the number of preliminary exchanges the admission layer will conduct before substantive exchange in deployments that admit the negotiation embodiment of the protocol. A small Nu favors rapid convergence on the maximal common subset at the cost of admitting some marginal subsets without exhaustive exploration; a large Nu favors exhaustive exploration at the cost of additional latency before substantive exchange. The negotiation results are themselves recorded as a typed negotiation-record predecessor of subsequent substantive exchange records, so the negotiation outcome under which a given exchange was conducted is auditable. Where Nu is set to zero, negotiation is disabled and admission proceeds against the originator's declared profile without preliminary exchange.

The remediation-hint policy parameter governs whether and which structured remediation hints the receiving platform's typed rejection records are permitted to disclose. In high-trust deployments the policy may admit detailed hints citing specific field, predecessor, or policy values that would have permitted admission; in low-trust deployments the policy may restrict hints to coarse classification (schema-violation, intent-violation, identity-violation) without specific value disclosure. The hint policy is itself recorded in the deployment manifest, so the disclosure discipline under which a given rejection was emitted is itself auditable, and changes to the hint policy are themselves manifest-amendment events subject to the chain's verification discipline.

The attestation-lifetime parameter, denoted Lambda, governs the duration for which a third-party schema-compliance attestation accompanying an envelope is admissible. Where the pre-admission attestation embodiment is in use, an attestation older than Lambda is treated as expired and the receiving platform falls back to direct compliance verification; this prevents an attestation from accumulating long-tail trust that survives the conditions under which it was issued. Lambda is typically set in the range of hours to days, calibrated to the rate at which the deployment expects schema or policy revisions to render older attestations stale. The lifetime parameter, like the others, is recorded in the deployment manifest, and admission records carrying attestations name both the attestation and the Lambda value under which it was admitted.

Alternative Embodiments

Several alternative embodiments of the interoperability mechanism are within the disclosed scope. In a first embodiment, the structural admission layer is implemented as a sidecar process at each execution-platform boundary, allowing existing agent runtimes to participate by deploying the sidecar without modification of agent internals. In a second embodiment, the admission layer is implemented as a library linked into the agent runtime itself, providing tighter integration at the cost of requiring runtime modification.

In a third embodiment, the canonical schema is split into a core profile and one or more extension profiles, with deployments declaring which profiles they admit and partial agents declaring which profiles they implement; this embodiment supports populations whose interoperability needs span both a stable core and rapidly evolving frontier capabilities. In a fourth embodiment, the semantic exchange protocol is extended with a negotiation phase preceding each exchange, in which the participating platforms exchange completeness and intent declarations and converge on the maximal common subset prior to substantive exchange, permitting agents of widely varying completeness to interoperate at the largest mutually supported level.

In a fifth embodiment, the rejection record carries a structured remediation hint identifying the specific field, predecessor, or policy reference that would, if supplied, cause the refused envelope to admit; this embodiment permits cross-boundary error recovery without exposing the receiving platform's internal logic. In a sixth embodiment, the admission layer is augmented with a pre-admission attestation step in which the originating agent supplies a third-party attestation of schema compliance, allowing receiving platforms to amortize verification cost across many exchanges with the same originator.

In a seventh embodiment, the cross-boundary signing scheme is replaced by a delegation-chain attestation, in which an agent's authority to emit envelopes derives from a chain of signed delegations from an anchoring identity rather than from a single per-agent key; this embodiment is suited to deployments in which agents are spawned and retired rapidly and per-agent key registration would be operationally burdensome. In an eighth embodiment, the interoperability mechanism is extended to non-agent participants such as data sources and human-in-the-loop operators, with the participants modeled as degenerate agents carrying only the schema subset their role requires.

In a ninth embodiment, the admission layer carries a typed quarantine path under which envelopes that fail strict admission but satisfy a relaxed envelope are admitted to a quarantined execution context whose effects are reversible and whose lineage records are typed as quarantined; this embodiment supports deployments that wish to preserve liveness for marginal envelopes while preventing quarantined effects from contaminating the canonical lineage of the receiving population. In a tenth embodiment, the protocol is extended with a typed retraction envelope by which an originating agent may rescind a previously emitted envelope subject to admission of the retraction itself; the retraction is recorded as a predecessor of the rescinded envelope's lineage subgraph, supporting populations whose interoperability discipline includes cooperative rollback.

In an eleventh embodiment, the interoperability mechanism admits federated admission in which a panel of receiving platforms jointly evaluates a cross-boundary envelope and admits it only upon achieving a configured threshold of independent admission decisions; this embodiment is suited to multi-organization populations whose admission discipline must reflect the consent of more than a single receiving party. In a twelfth embodiment, the cross-boundary protocol is extended to carry payload encryption under a key whose access is itself a structural admission concern, supporting populations in which envelope payloads carry sensitive content that the receiving platform must admit structurally without disclosing to the transport layer.

Composition

The interoperability mechanism composes with the other primitives of the execution platform and with adjacent layers to produce system-level guarantees no primitive supplies in isolation. The agent schema's canonical-fields and structural-validation primitives supply the formal object against which the admission layer evaluates compliance; without the schema there would be no object to admit. The lineage graph's typed predecessor structure supplies the predecessor references the protocol envelope carries; without the lineage graph cross-boundary exchange would not preserve the provenance the receiving platform requires.

Below the execution platform, the memory-native protocol's cognition-compatible transport disseminates the envelopes; the interoperability mechanism contributes the admission semantics that filter what the transport conveys before it reaches local execution. Above, the agent governance primitives consume admitted envelopes as authorized state transitions; because admission is structurally bound to schema compliance, intent typing, and policy reference resolution, the governance layer inherits a structural guarantee that no transition it observes was admitted by anything other than a verified envelope. The composition closes the cross-boundary loop without recourse to a separate enforcement layer at the governance level.

The mechanism also composes with the consensus primitives of the protocol layer: when a cross-boundary mutation is admitted, the resulting consensus event records the admission decision as a predecessor, so the consensus history of any cross-boundary effect carries the boundary admission as a structural fact. The interoperability mechanism composes, finally, with the lineage graph's cross-agent first-class edges to produce a system in which a cross-vendor delegation appears in the connected graph as an ordinary edge between agent populations rather than as a special bridge requiring special-case verification logic.

The compositional surface with policy reference resolution is structurally important. The receiving platform's resolver chain Rho is itself a structural object recorded in the deployment manifest, and the resolution outcome for any given envelope's policy reference is committed as a predecessor of the admission record for that envelope. This means that a later auditor investigating whether a particular cross-boundary effect was authorized under a policy in force at the time of admission may walk the admission record's predecessor edges to the resolution outcome and verify, against the resolver chain that produced it, that the resolved policy was in fact the policy under which admission was conducted. The audit answer is therefore a structural walk rather than a reconstruction from operational logs, and the answer is identical regardless of which auditor performs the walk.

Prior-Art Distinctions

Conventional cross-vendor agent interoperability proposals rely on shared message formats such as RPC schemas, REST contracts, and message bus payload specifications, optionally accompanied by best-practices guidance for governance and provenance recording. These approaches define what messages look like on the wire but do not define a structural admission layer that refuses non-compliant agents at the boundary; non-compliance manifests as downstream behavioral defects detected by application-layer audits rather than as boundary-time refusals. The present system differs in that admission is a structural operation evaluated against a formal schema and a formal protocol, and refusal is an explicit first-class outcome recorded to the lineage graph.

Service-mesh and API-gateway technologies do enforce admission at a boundary, but they enforce admission against transport-level concerns such as authentication, rate limiting, and routing rather than against schema-level concerns such as completeness, intent typing, and policy reference resolution. Their refusals are typically not preserved as auditable provenance and do not participate in a lineage graph spanning agent populations. Workflow orchestration platforms admit cross-boundary tasks but typically presume a single vendor's runtime on both sides and do not model partial completeness as a structural property; they presume completeness or fail.

Standards-based agent communication languages such as those derived from KQML and FIPA-ACL define message envelopes and intent classes at a high level but do not bind those envelopes to a content-addressed schema, a content-addressed lineage graph, or a structural admission layer of the kind disclosed; they presume a cooperative population in which non-compliance is rare and tolerated. The present system does not presume cooperation; it refuses non-compliance by construction. The combination of shared canonical schema, shared semantic exchange protocol with typed intent classes, structural admission layer with first-class typed rejection records, partial-completeness subsets enumerated in a whitelist, and integration with a content-addressed lineage graph spanning agent populations is not anticipated by any single prior art system known to the inventor.

Disclosure Scope

The disclosure of U.S. Application 19/230,933 covers the agent interoperability mechanism as described, including the shared canonical schema, the shared semantic exchange protocol with its typed intent classes and typed completeness descriptors, the structural admission layer at the execution-platform boundary, the typed rejection record convention recording refusals to the lineage graph, the partial-completeness subset whitelist convention, and the alternative embodiments enumerated above. The scope encompasses implementations of the admission layer as a sidecar, as a runtime library, or as a hardware-accelerated boundary device, and mixed deployments combining these forms.

The scope further encompasses use of the mechanism to permit cross-vendor interoperation between agents implementing the shared schema, to permit interoperation between full and partial agents under configured subset whitelists, and to permit refusal of non-compliant agents as a first-class auditable operation. Implementations differing in the specific schema version, the specific intent-class whitelist, the specific completeness-subset whitelist, or the specific policy-resolver chain remain within the disclosure scope provided that the shared canonical schema, the shared semantic exchange protocol with typed intent and completeness descriptors, the structural admission layer with typed rejection records, and the integration with a content-addressed lineage graph are present together as architectural primitives. Licensing inquiries concerning the disclosed mechanism are directed to the assignee of record.