Multi-Vendor AI Agent Interoperability

Regulatory Framework

The regulatory landscape for AI agents in 2026 is no longer permissive. The European Union Artificial Intelligence Act (Regulation (EU) 2024/1689) imposes graduated obligations based on risk classification, with Article 25 specifically addressing distributors, importers, and other operators in the AI value chain. A distributor that places an agent on the EU market inherits obligations to verify CE marking, technical documentation, instructions for use, and the operator's quality management system. When an enterprise integrates agents from three vendors into a single workflow, each vendor's compliance posture becomes a component of the integrator's overall posture. The integrator cannot inherit what the integrator cannot inspect.

The NIST AI Risk Management Framework (AI RMF 1.0) and its Generative AI Profile establish the GOVERN, MAP, MEASURE, and MANAGE functions as the U.S. federal expectation for trustworthy AI. ISO/IEC 42001:2023 codifies AI management systems and is increasingly referenced in procurement requirements. ISO/IEC 23894 addresses AI risk management, and ISO/IEC 5338 the AI system lifecycle. ISO/IEC 5230 (OpenChain) defines license-compliance program requirements that apply with full force when AI components are assembled from multiple sources, including open-source components embedded in vendor agents.

Executive Order 14028 on Improving the Nation's Cybersecurity, together with the subsequent OMB memoranda and CISA guidance, requires software bills of materials (SBOM) for federal procurement. The NTIA SBOM minimum elements (supplier name, component name, version, unique identifier, dependency relationship, author, timestamp) are the floor. For AI agents, the equivalent question, what is in this agent, what does it depend on, who authored it, what version is it, becomes intractable when the agent itself is a vendor-defined opaque construct.

Cross-cutting these regimes are emerging interoperability standards: the Model Context Protocol (MCP) for tool and resource exposure to language-model agents, OpenAPI 3.x and AsyncAPI 3.x for synchronous and asynchronous interface description, and a growing body of agent-communication proposals layered on top. These standards address the wire format. They do not address the structural identity of the agent that is communicating.

Architectural Requirement

For multi-vendor AI deployments to satisfy these regimes, the architecture must guarantee five properties. First, every agent participating in the deployment must expose a uniform structural surface against which governance, audit, and conformity assessment can operate, regardless of which vendor produced the agent. Second, the structural surface must be intrinsic, meaning that the absence of any required field disqualifies the object from being an agent rather than producing a partially compliant agent. Third, attribution must be inherent: every action performed by an agent must trace to an identifiable identity and policy, with an unbroken lineage back to authorized state. Fourth, eligibility for execution must be structurally evaluable before action, not asserted after action. Fifth, the schema must be vendor-neutral and stable across versions, so that an integrator's compliance posture does not depend on the goodwill of any single vendor.

These properties together define a canonical agent schema with six typed fields. The fields are not metadata, decoration, or policy hints. They are the constitutive structure of the agent.

Why Procedural Compliance Fails

The dominant approach to multi-vendor AI compliance today is procedural. An enterprise procures agents from vendors A, B, and C; each vendor supplies its own model card, its own AI RMF self-attestation, its own ISO 42001 certificate where available, and its own SBOM in CycloneDX or SPDX format. The integrator assembles these artifacts into a compliance binder. This approach fails for reasons that are now well documented in compliance practice.

The first failure is attestation drift. Each vendor produces its artifacts at the time of release. The agent then operates for months, ingesting tools, accumulating fine-tuned context, and evolving behavior. The original artifact is a photograph of a moving subject. EU AI Act Article 25 distributor obligations and the NIST AI RMF MANAGE function require ongoing assurance, not point-in-time attestation.

The second failure is interface ambiguity. When agent A from vendor X delegates a task to agent B from vendor Y, the protocol carries a request, but the request does not carry the full structural context required to evaluate whether agent B is permitted to perform the task on agent A's behalf. Vendor X's notion of governance may be a system prompt; vendor Y's notion may be an external policy engine. The protocol succeeds. The governance does not transfer.

The third failure is audit incommensurability. When a regulator under the EU AI Act, or an internal audit team under ISO/IEC 42001, asks for evidence that a particular decision was governed by a particular policy, the integrator must reconstruct the answer across three vendor logging formats, three identity schemes, three notions of what counts as an action, and three retention regimes. Procedural compliance generates the appearance of evidence without the structure to evaluate it.

The fourth failure is supply-chain opacity. EO 14028 and the NTIA SBOM minimum elements presume that each component can be enumerated. Vendor agents that internally compose models, retrieval systems, tool servers, and fine-tuning datasets present an SBOM at the wrapper level that does not reflect the operational composition. OpenChain license obligations under ISO/IEC 5230, particularly for embedded open-source components, are evaluated against the wrong artifact.

The fifth failure is delegation without eligibility. Procedural systems treat eligibility as a runtime check inside the receiving agent. If the receiving agent is a black box, the eligibility check is opaque to the delegator and to any auditor. The decision to delegate cannot be justified ex ante, only narrated ex post.

What AQ Primitive Provides

The Adaptive Query agent-schema primitive defines six intrinsic typed fields that every agent must carry, regardless of vendor. Governance is the field that encodes the constraints under which the agent is permitted to operate, expressed as evaluable predicates rather than as prose. Memory is the field that holds the agent's state, structured so that any consumer can read it without vendor-specific deserialization. Lineage is the field that records every transition the agent has undergone, with author, timestamp, prior-state reference, and authorizing policy. Execution eligibility is the field that determines, before any action, whether the agent is permitted to perform the action under the current governance and current state. Identity is the field that uniquely names the agent and links it to its issuing authority, supporting cryptographic verification. Policy is the field that holds the rules the agent itself enforces, distinct from the governance that constrains the agent from outside.

With these fields intrinsic, multi-vendor interoperation becomes a structural property rather than a negotiated outcome. When agent A delegates to agent B, agent A inspects agent B's governance and eligibility fields directly. The inspection does not require vendor cooperation; the schema is the contract. If agent B's governance is incompatible with the task's required policy, the delegation is structurally refused before any wire-format exchange occurs.

The lineage field is the substrate on which AI RMF MEASURE and MANAGE functions, ISO/IEC 42001 audit, EU AI Act conformity assessment, and EO 14028 supply-chain attestation operate uniformly. Every action is attributable; every authorization is referenceable; every state is derivable from the recorded transitions. SBOM minimum elements project naturally onto the schema: identity carries supplier and component identifiers, memory references the dependency graph, lineage carries timestamps and authors.

Wire protocols such as MCP, OpenAPI, and AsyncAPI continue to serve their purposes, but they now carry payloads whose structure is canonical. An MCP tool invocation that originates from a schema-conformant agent carries the agent's identity and policy references; the tool server can evaluate eligibility against the same schema rather than against vendor-specific headers.

Compliance Mapping

The mapping from the canonical schema to specific regulatory artifacts is direct. EU AI Act Article 25 distributor obligations are satisfied because the distributor can verify, by structural inspection, that each agent it places on the market exposes the six fields with the required semantics. The technical documentation referenced in Annex IV of the Act projects naturally onto the schema: intended purpose into the policy field, design specifications into governance, monitoring capabilities into lineage.

NIST AI RMF GOVERN maps onto the governance field; MAP onto the relationship between identity and operational context; MEASURE onto the lineage field as the source of truth for performance and incident data; MANAGE onto the eligibility field as the structural enforcement of risk-based gating. ISO/IEC 42001 management-system audits inspect the schema as the controlled artifact.

ISO/IEC 5230 OpenChain license compliance and NTIA SBOM minimum elements are derivable from the identity and memory fields, because the agent's composition is structurally exposed rather than rhetorically described. EO 14028 supply-chain attestation, including the requirements for self-attestation under OMB M-22-18 and successor memoranda, becomes a property of the agent rather than a separate document.

MCP, OpenAPI, and AsyncAPI specifications continue to define the wire interfaces, but the agent objects on either side of the wire are now schema-conformant, so the interface descriptions can reference the canonical fields rather than reinventing them per vendor.

Adoption Pathway

Adoption begins where the regulatory pressure is most concrete: enterprises subject to the EU AI Act and to federal procurement under EO 14028. These organizations require structural answers and have the procurement leverage to demand them. The first stage is to write the canonical schema into procurement specifications, so that any agent acquired from any vendor must expose the six fields. This stage requires no change to internal systems; it changes what enters the perimeter.

The second stage is to instrument the integration layer. The enterprise's agent gateway, whether built on MCP, on a service mesh, or on a custom orchestrator, evaluates schema conformance at every boundary and refuses non-conformant traffic. Vendors respond, because the alternative is exclusion from the deployment. ISO/IEC 42001 audit programs increasingly cite the gateway as a control.

The third stage is to consolidate audit and compliance tooling against the schema. AI RMF documentation, EU AI Act technical files, OpenChain reports, and SBOM exports are generated from the lineage and identity fields rather than assembled from vendor artifacts. The cost of audit drops because the substrate is uniform.

The fourth stage is industry-level standardization. The canonical schema, having proven itself in enterprise deployments, is contributed to standards bodies, ISO/IEC SC 42 for AI, the Linux Foundation's OpenChain and SPDX projects for supply chain, and the relevant working groups for MCP and AsyncAPI. At this stage the schema becomes the default rather than the differentiator, and vendors who do not implement it are recognized as compliance liabilities rather than as alternative architectures.

Throughout this pathway, no organization is asked to abandon a vendor or rebuild a system. The pathway changes what counts as an agent, and the rest follows from the structural change.