Delete README.md

README.md

@@ -1,796 +0,0 @@
----
-title: Interoperability
-emoji: 🔗
-colorFrom: blue
-colorTo: indigo
-sdk: static
-pinned: false
----
-
-# Interoperability
-
-**Open interoperability for AI models, agents, tools, data, infrastructure, and enterprise systems.**
-
-Interoperability is becoming a defining systems problem in artificial intelligence. Modern AI no longer lives inside one model, one vendor, or one application. A useful AI system may combine a foundation model, an inference provider, an agent runtime, external tools, enterprise APIs, retrieval systems, identity services, observability layers, and other agents. The value of each component increasingly depends on whether it can work with the rest.
-
-This organization studies and builds practical resources for **AI interoperability**: the ability of heterogeneous AI systems to exchange information, discover capabilities, invoke tools, coordinate tasks, preserve structure, respect security boundaries, and remain portable across implementations.
-
-Our focus is practical and open. We are interested in specifications, protocols, compatibility patterns, reference architectures, benchmarks, datasets, and tools that make AI systems easier to connect and harder to lock into a single stack.
-
-> **Working definition:** AI interoperability is the ability of models, agents, tools, data systems, and infrastructure to exchange information and work together across different platforms, providers, frameworks, and protocols with predictable semantics.
-
----
-
-## Why AI interoperability matters
-
-The AI stack is fragmenting and integrating at the same time.
-
-Teams can choose among many models, inference providers, agent frameworks, vector stores, tool servers, API styles, cloud platforms, and deployment environments. This diversity is useful: it encourages specialization, competition, and experimentation. But it also creates integration cost.
-
-Without interoperability, organizations repeatedly rebuild adapters, schemas, authentication logic, tool wrappers, routing logic, and observability pipelines. Systems become tightly coupled to one provider. Agents cannot reliably discover or delegate to one another. Tool interfaces drift. Structured outputs fail at boundaries. Security policies become inconsistent across components.
-
-Interoperability reduces this friction by making interfaces explicit.
-
-Good interoperability does **not** mean that every system must use the same implementation. It means systems can cooperate through shared contracts, discoverable capabilities, stable schemas, and well-defined behavior.
-
-That makes interoperability relevant to:
-
-- AI agents and multi-agent systems
-- model and inference portability
-- tool use and function calling
-- enterprise API integration
-- data exchange and retrieval
-- cloud and provider portability
-- robotics and physical AI
-- identity and authorization
-- observability and tracing
-- evaluation and validation
-- long-running autonomous workflows
-
----
-
-# The interoperability stack
-
-AI interoperability is not one problem. It is a stack of related problems.
-
-## 1. Model interoperability
-
-Model interoperability is the ability to move between models or model providers without rebuilding the surrounding application.
-
-Important concerns include:
-
-- common request and response structures
-- message and role semantics
-- tool-call representation
-- multimodal input and output
-- streaming behavior
-- structured outputs
-- context-window differences
-- model-specific capabilities
-- tokenization and prompt portability
-- provider-specific extensions
-
-A system may support multiple models while still being poorly interoperable if switching models changes application behavior in undocumented ways.
-
-**Goal:** make models replaceable enough that applications can choose the best model for cost, latency, capability, privacy, or availability.
-
----
-
-## 2. Agent interoperability
-
-Agent interoperability concerns communication and collaboration between autonomous or semi-autonomous AI systems.
-
-A useful interoperable agent environment should make it possible to:
-
-1. discover another agent,
-2. understand its capabilities,
-3. create or delegate a task,
-4. exchange structured information,
-5. receive progress and results,
-6. handle failure and retries,
-7. preserve identity and authorization boundaries.
-
-The **Agent2Agent (A2A) Protocol** is an important open standard in this area. Its specification is designed for communication between independent agents that may be built with different frameworks, languages, or vendors.
-
-Agent interoperability is different from tool interoperability: an agent is not merely a callable function. It may have its own goals, state, policies, skills, and task lifecycle.
-
----
-
-## 3. Tool interoperability
-
-Tool interoperability is the ability for AI systems to discover and invoke external capabilities through consistent interfaces.
-
-The **Model Context Protocol (MCP)** has become an important open protocol for connecting AI applications to tools and contextual resources. An MCP-compatible client can connect to MCP servers that expose tools or other capabilities.
-
-Hugging Face itself supports MCP connections to Hub resources and MCP-compatible Spaces, making tool interoperability directly relevant to the Hugging Face ecosystem.
-
-Typical tool-interoperability questions include:
-
-- How are tools discovered?
-- How are tool schemas represented?
-- How are arguments validated?
-- How are results returned?
-- How is authentication handled?
-- Can tools stream results?
-- What happens when a tool fails?
-- Can the same tool be used by different agent runtimes?
-
----
-
-## 4. Data interoperability
-
-AI systems depend on data moving between many components: documents, embeddings, databases, vector stores, event streams, multimodal assets, logs, memory systems, and training datasets.
-
-Data interoperability requires more than compatible file formats. It includes:
-
-- schema consistency
-- metadata
-- identifiers
-- provenance
-- typing
-- versioning
-- encoding
-- units
-- permissions
-- privacy constraints
-- semantic meaning
-
-**JSON Schema**, typed API definitions, dataset cards, metadata standards, and explicit data contracts all contribute to reliable data exchange.
-
-A system can be syntactically compatible while still being semantically incompatible. Two services may both accept JSON but interpret the same field differently. Interoperability therefore depends on shared meaning, not only shared serialization.
-
----
-
-## 5. Infrastructure interoperability
-
-AI infrastructure includes inference providers, GPUs and accelerators, serving frameworks, orchestration systems, queues, storage, observability, deployment platforms, and cloud environments.
-
-Infrastructure interoperability makes it easier to:
-
-- route workloads across providers
-- move models between serving backends
-- compare latency and cost
-- fail over when a provider is unavailable
-- preserve metrics across environments
-- avoid hard dependencies on one runtime
-- deploy the same workload at cloud, edge, or on-premises locations
-
-This layer becomes more important as inference becomes distributed and heterogeneous.
-
----
-
-## 6. Security and identity interoperability
-
-Connected AI systems need consistent answers to basic security questions:
-
-- Who is calling?
-- What is the caller allowed to do?
-- Which user or organization does the request represent?
-- What credentials can be delegated?
-- Which scopes apply?
-- How are secrets protected?
-- How is consent represented?
-- Can actions be audited later?
-
-Protocols without identity, authorization, and policy integration may connect systems technically while leaving enterprise interoperability incomplete.
-
-Interoperability therefore has to include security boundaries rather than bypass them.
-
----
-
-# Core protocols and standards
-
-No single protocol solves the entire interoperability stack. Different standards operate at different layers.
-
-| Technology | Primary purpose | Typical relationship | What it helps standardize |
-|---|---|---|---|
-| **MCP** | Connect AI clients/agents to tools and contextual capabilities | Agent ↔ Tool / Resource | Discovery, tool invocation, resources, interaction |
-| **A2A** | Communication and collaboration between independent agents | Agent ↔ Agent | Discovery, tasks, messages, collaboration |
-| **OpenAPI** | Describe HTTP APIs | Application ↔ Service | Endpoints, operations, schemas, parameters |
-| **JSON Schema** | Describe and validate structured JSON data | Data ↔ Data / API | Types, constraints, structured contracts |
-| **OAuth 2.x / related profiles** | Authorization | Identity ↔ Service | Delegated access and scopes |
-| **gRPC / Protocol Buffers** | Typed remote procedure calls | Service ↔ Service | Methods, messages, high-performance RPC |
-
-These technologies are often complementary rather than competitive.
-
-A multi-agent application may use:
-
-- **A2A** for agent-to-agent collaboration,
-- **MCP** for agent-to-tool access,
-- **OpenAPI** for existing enterprise services,
-- **JSON Schema** for structured contracts,
-- an authorization framework for secure access,
-- and observability standards for traces and diagnostics.
-
-The useful question is therefore rarely “Which one protocol wins?” A better question is:
-
-> **Which interoperability layer does this protocol solve, and how does it compose with the others?**
-
----
-
-# MCP and A2A are complementary
-
-MCP and A2A are frequently discussed together, but they address different interaction patterns.
-
-## MCP: agent or application to capability
-
-MCP is useful when an AI client needs access to tools, resources, or contextual capabilities exposed by a server.
-
-Think:
-
-**assistant → tool**
-
-Examples:
-
-- search a knowledge base,
-- call an internal business function,
-- run a Hugging Face Space as a tool,
-- inspect a dataset,
-- trigger a workflow,
-- retrieve contextual information.
-
-## A2A: agent to agent
-
-A2A is designed for independent agents to discover each other and collaborate on tasks.
-
-Think:
-
-**agent → agent**
-
-Examples:
-
-- a procurement agent delegates supplier research,
-- a planning agent asks a logistics agent to optimize a route,
-- an enterprise coordinator sends work to a specialist agent,
-- two independently implemented agents exchange task state.
-
-A system can use both at the same time:
-
-**User → Agent A → A2A → Agent B → MCP → Tool**
-
-That composition is one of the clearest examples of why AI interoperability is a systems problem rather than a single-protocol problem.
-
----
-
-# Interoperability reference architecture
-
-A practical AI system can be viewed as a set of layers:
-
-```text
-Users / Applications
-        │
-        ▼
-Agents & Agent Runtimes
-        │
-        ├──────── A2A / agent communication ────────► Other Agents
-        │
-        ▼
-Tool & Capability Layer
-        │
-        ├──────── MCP / tool protocols ─────────────► Tools
-        │
-        ├──────── OpenAPI / RPC ────────────────────► Services
-        │
-        ▼
-Models & Inference
-        │
-        ├──────── provider abstraction ─────────────► Inference Providers
-        │
-        ▼
-Data & Context
-        │
-        ├──────── schemas / metadata ───────────────► Data Systems
-        │
-        ▼
-Identity · Security · Observability · Validation
-```
-
-The exact technologies will change. The architectural need for clear boundaries probably will not.
-
----
-
-# What makes an AI system interoperable?
-
-Interoperability is not binary. A system can be interoperable at one layer and locked-in at another.
-
-We use the following dimensions as a practical evaluation framework.
-
-## Discoverability
-
-Can systems discover available capabilities without hard-coded private knowledge?
-
-Examples:
-
-- agent capability cards,
-- server manifests,
-- machine-readable API descriptions,
-- registries.
-
-## Contract clarity
-
-Are inputs, outputs, types, errors, and lifecycle semantics documented and machine-readable?
-
-## Portability
-
-Can a component be replaced with another implementation without rewriting the whole system?
-
-## Composability
-
-Can multiple protocols and systems work together rather than requiring one vertically integrated stack?
-
-## Security
-
-Can identity, authorization, scopes, and policy boundaries survive across system boundaries?
-
-## Observability
-
-Can operators trace requests, tool calls, agent handoffs, failures, latency, and costs across components?
-
-## Validation
-
-Can compatibility be tested rather than merely claimed?
-
-## Versioning
-
-Can systems evolve without silently breaking integrations?
-
-## Failure handling
-
-Are timeouts, retries, unavailable capabilities, partial results, and fallback behavior explicit?
-
-## Semantic consistency
-
-Do connected systems mean the same thing when they exchange the same structured fields?
-
----
-
-# Interoperability vs. integration
-
-These terms are related but not identical.
-
-**Integration** usually means connecting specific systems so that they work together.
-
-**Interoperability** aims for reusable compatibility across systems, vendors, and implementations.
-
-A custom adapter between Product A and Product B is an integration.
-
-A shared protocol that allows Product A, Product B, Product C, and future implementations to communicate through the same contract is interoperability.
-
-Integration solves a connection.
-
-Interoperability reduces the cost of future connections.
-
----
-
-# Interoperability vs. orchestration
-
-Interoperability asks:
-
-> **Can these systems communicate and cooperate?**
-
-Orchestration asks:
-
-> **Which system should act, in what order, under which conditions?**
-
-An orchestration layer benefits from interoperability because it can coordinate components without custom logic for every pair of systems.
-
-This distinction matters for agentic systems. A workflow engine may orchestrate several agents, but the agents still need compatible ways to communicate, use tools, transfer context, and report state.
-
----
-
-# Interoperability vs. observability
-
-Interoperability creates connections.
-
-Observability makes those connections understandable in operation.
-
-A production multi-agent system should ideally expose traces that cross:
-
-- model calls,
-- inference providers,
-- tool invocations,
-- agent handoffs,
-- external APIs,
-- validation steps,
-- retries and failures.
-
-Without cross-system observability, technically interoperable systems can still be operationally opaque.
-
----
-
-# Interoperability and validation
-
-Compatibility should be testable.
-
-A strong interoperability test suite can ask:
-
-- Can the system discover the capability?
-- Can it understand the schema?
-- Can it invoke the capability successfully?
-- Does it preserve structured data?
-- Can it recover from invalid inputs?
-- Does authentication work correctly?
-- Are errors machine-readable?
-- Can another implementation reproduce the interaction?
-- Does a version update break the contract?
-
-This organization intends to treat interoperability as something that can be **measured**, not only described.
-
----
-
-# Interoperability and omnimodal AI
-
-Future AI systems increasingly work across text, images, audio, video, structured data, sensor streams, and actions.
-
-That creates new interoperability requirements.
-
-A text-only API may be insufficient when an agent needs to exchange:
-
-- video segments,
-- audio streams,
-- images,
-- 3D representations,
-- sensor observations,
-- actions,
-- temporal state,
-- confidence or uncertainty.
-
-Omnimodal systems therefore make interface design more difficult, not less.
-
-The challenge becomes: how can heterogeneous systems exchange rich modalities while preserving meaning, timing, permissions, and provenance?
-
----
-
-# Interoperability and world models
-
-World models and physical AI add another layer.
-
-A robot or embodied agent may need to combine:
-
-- camera data,
-- proprioception,
-- language instructions,
-- environment state,
-- world-model predictions,
-- planning,
-- external tools,
-- other agents,
-- actuators.
-
-Interoperability becomes the connective tissue between perception, reasoning, simulation, and action.
-
-This is especially relevant when different components come from different vendors or research projects.
-
----
-
-# Interoperability and AGI
-
-No one knows which architectures will produce AGI, or whether AGI will arrive as a single system at all.
-
-But increasingly capable AI systems are likely to operate in heterogeneous environments containing existing software, human organizations, devices, services, and other AI systems.
-
-That makes interoperability a useful research question independently of any specific AGI timeline.
-
-If future AI becomes more autonomous, interoperability questions become more consequential:
-
-- Can systems delegate safely?
-- Can agents negotiate capabilities?
-- Can policy constraints propagate?
-- Can identity survive multi-agent handoffs?
-- Can tools be substituted without changing goals?
-- Can one agent verify another agent's output?
-- Can systems cooperate without exposing internal state?
-- Can organizations retain portability across model providers?
-
-Interoperability is therefore not a claim about AGI. It is an engineering requirement for increasingly connected AI systems.
-
----
-
-# Enterprise use cases
-
-## Multi-agent enterprise workflows
-
-Different departments may operate specialized agents for finance, procurement, support, engineering, security, or legal work. Interoperability can allow them to collaborate without forcing every agent onto the same framework.
-
-## Model-provider portability
-
-Applications can route work between models based on capability, availability, cost, latency, geography, or policy.
-
-## Tool ecosystems
-
-A tool published once through an open interface can potentially serve many compatible clients.
-
-## Cross-cloud AI
-
-Organizations can combine models and infrastructure across cloud, edge, and on-premises environments.
-
-## Robotics and physical AI
-
-Robots can combine models, sensors, planning systems, simulation, and external services from multiple vendors.
-
-## Regulated environments
-
-Explicit interfaces, identity, auditability, and validation are especially valuable where AI actions need to be reviewed or governed.
-
----
-
-# Interoperability maturity model
-
-We use a simple five-level model as a starting point.
-
-| Level | Name | Description |
-|---|---|---|
-| **0** | Isolated | Closed system with proprietary interfaces and no documented portability |
-| **1** | Documented | Interfaces exist and are documented, but integrations are mostly custom |
-| **2** | Structured | Machine-readable schemas and stable contracts are available |
-| **3** | Protocol-compatible | Open or broadly implemented protocols support reusable connections |
-| **4** | Composable | Components can be discovered, substituted, orchestrated, observed, and validated across vendors |
-
-This is not a certification standard. It is a framework for discussing practical interoperability.
-
-Our **Interoperability Readiness** Space will turn these dimensions into an interactive self-assessment.
-
----
-
-# What we are building
-
-This organization is intended to be a practical reference, not only a glossary.
-
-## Protocol Explorer
-
-A structured, filterable reference for protocols and standards relevant to AI interoperability.
-
-Topics include:
-
-- agent-to-agent communication
-- agent-to-tool communication
-- API description
-- structured data contracts
-- authorization
-- RPC
-- observability
-- discovery
-
-## Interoperability Checker
-
-An interactive tool for exploring how common AI components can connect and which interoperability layer is required.
-
-## Interoperability Map
-
-A visual map connecting models, inference, agents, tools, APIs, data, identity, observability, validation, and physical systems.
-
-## Interoperability Readiness
-
-A self-assessment for teams evaluating whether an AI architecture is portable, observable, secure, and protocol-ready.
-
-## Future: Interoperability Benchmark
-
-A reproducible benchmark for testing compatibility claims across agent and tool ecosystems.
-
-Potential benchmark dimensions include:
-
-- capability discovery
-- schema adherence
-- tool invocation
-- agent handoff
-- structured output preservation
-- authentication behavior
-- error handling
-- streaming
-- version compatibility
-- protocol translation
-
----
-
-# Research questions
-
-Some questions we consider especially important:
-
-1. How should agents advertise capabilities in a vendor-neutral way?
-2. Which parts of agent state should be portable?
-3. How should permissions propagate across delegated tasks?
-4. Can agent-to-agent communication preserve provenance?
-5. How should protocols represent multimodal and temporal information?
-6. How can interoperability be benchmarked objectively?
-7. When should adapters translate between protocols, and when should systems implement them natively?
-8. How can observability cross agent and provider boundaries?
-9. How can enterprises avoid protocol-level lock-in?
-10. How should compatibility failures be surfaced to autonomous systems?
-11. Can interoperability support local, cloud, and edge AI equally well?
-12. Which interfaces remain stable as AI capabilities change?
-
----
-
-# Glossary
-
-**A2A** — Agent2Agent Protocol, an open standard for communication and collaboration between independent AI agents.
-
-**Agent** — A software system that can pursue tasks using models, tools, memory, planning, or external services.
-
-**API** — An application programming interface defining how software components communicate.
-
-**Capability discovery** — A mechanism by which a system learns what another system can do.
-
-**Contract** — A machine- or human-readable definition of expected inputs, outputs, behavior, and errors.
-
-**Data interoperability** — The ability of different systems to exchange and correctly interpret data.
-
-**Inference** — Running a trained model to produce outputs from inputs.
-
-**Interoperability** — The ability of independent systems to exchange information and work together through compatible interfaces and semantics.
-
-**MCP** — Model Context Protocol, an open protocol for connecting AI applications with tools and contextual capabilities.
-
-**Model interoperability** — Portability and compatibility across models, providers, and runtimes.
-
-**Observability** — The ability to understand system behavior through traces, logs, metrics, events, and related telemetry.
-
-**OpenAPI** — A specification for describing HTTP APIs in a machine-readable form.
-
-**Orchestration** — Coordinating components, tasks, agents, or workflows.
-
-**Protocol** — A defined set of rules for communication between systems.
-
-**Schema** — A formal description of the expected structure and constraints of data.
-
-**Tool use** — The ability of an AI system to invoke external capabilities.
-
-**Validation** — Testing whether inputs, outputs, behavior, or system interactions satisfy defined requirements.
-
-**Vendor lock-in** — Dependence on one vendor that makes switching difficult or costly.
-
----
-
-# Frequently asked questions
-
-## What is AI interoperability?
-
-AI interoperability is the ability of models, agents, tools, data systems, and infrastructure to exchange information and work together across different platforms, providers, frameworks, and protocols with predictable semantics.
-
-## Why is interoperability important for AI agents?
-
-Agents increasingly rely on external tools, services, models, and other agents. Without shared interfaces, every connection requires custom integration and becomes harder to secure, observe, test, and replace.
-
-## Is MCP an interoperability protocol?
-
-Yes. MCP addresses an important part of AI interoperability by standardizing how compatible AI clients connect to servers that expose tools and contextual capabilities.
-
-## Is A2A the same as MCP?
-
-No. They are complementary. MCP primarily addresses access to tools and contextual capabilities, while A2A is designed for communication and collaboration between independent agents.
-
-## Can MCP and A2A be used together?
-
-Yes. An agent can communicate with another agent using A2A while either agent uses MCP to access tools.
-
-## Is OpenAPI still relevant in agentic AI?
-
-Yes. Existing enterprise systems expose enormous numbers of HTTP APIs. OpenAPI provides machine-readable descriptions of those APIs and can coexist with newer agent protocols.
-
-## Does interoperability mean all models behave identically?
-
-No. Interoperability reduces interface friction; it does not erase differences in model behavior, capability, latency, cost, or safety.
-
-## What is model interoperability?
-
-Model interoperability is the ability to replace or route between models and providers while preserving enough interface and application behavior to avoid major rewrites.
-
-## What is agent interoperability?
-
-Agent interoperability is the ability of independent agents to discover one another, exchange information, coordinate tasks, and collaborate across different frameworks or vendors.
-
-## What is tool interoperability?
-
-Tool interoperability means a tool can be exposed through interfaces that multiple compatible AI clients or agents can understand and invoke.
-
-## How is interoperability different from orchestration?
-
-Interoperability defines whether systems can work together. Orchestration determines how those systems are coordinated.
-
-## How is interoperability different from integration?
-
-Integration connects specific systems. Interoperability creates reusable compatibility that can work across multiple implementations.
-
-## Can interoperability reduce vendor lock-in?
-
-It can reduce switching costs when interfaces, schemas, protocols, and data contracts are portable. It cannot eliminate all differences between vendors.
-
-## Is interoperability relevant to robotics?
-
-Yes. Physical AI systems combine sensors, models, planning, world models, tools, networks, and actuators. Shared interfaces can make these components easier to combine.
-
-## Will interoperability still matter if AGI is achieved?
-
-Very likely as an engineering concern, because advanced systems would still need to interact with software, organizations, devices, data sources, and potentially other AI systems. The exact protocols may change.
-
----
-
-# Source policy
-
-We want this organization to be useful as a technical reference.
-
-Our source policy is simple:
-
-1. Prefer **primary specifications and official documentation**.
-2. Clearly distinguish standards from implementations.
-3. Record versions where version differences matter.
-4. Avoid treating vendor marketing terminology as an open standard.
-5. Separate measured benchmark results from opinion.
-6. Update compatibility information when specifications change.
-7. Publish methodology for future benchmarks.
-8. Correct errors openly.
-
----
-
-# Primary references
-
-The following primary sources are useful starting points:
-
-- **Hugging Face Agents** — https://huggingface.co/docs/hub/agents
-- **Hugging Face MCP Server** — https://huggingface.co/docs/hub/agents-mcp
-- **Hugging Face Spaces as MCP servers** — https://huggingface.co/docs/hub/spaces-mcp-servers
-- **Model Context Protocol** — https://modelcontextprotocol.io/
-- **MCP specification and project updates** — https://blog.modelcontextprotocol.io/
-- **Agent2Agent Protocol (A2A)** — https://a2a-protocol.org/
-- **OpenAPI Initiative** — https://www.openapis.org/
-- **JSON Schema** — https://json-schema.org/
-- **OAuth** — https://oauth.net/
-- **gRPC** — https://grpc.io/
-
-At the time of this update, the current MCP specification line includes the **2026-07-28** release, and A2A documentation lists **1.0.0** as the latest released version. Always consult the official specifications for current details.
-
----
-
-# Contributing
-
-Useful contributions include:
-
-- corrections to protocol metadata
-- missing primary sources
-- interoperability case studies
-- reproducible compatibility tests
-- benchmark proposals
-- protocol adapters
-- datasets
-- implementation notes
-- security considerations
-- examples from real deployments
-
-Please prefer verifiable technical evidence over promotional claims.
-
----
-
-# Research & industry collaborations
-
-We welcome collaboration with:
-
-- AI infrastructure providers
-- model and inference providers
-- agent platforms
-- developer-tool companies
-- cloud and edge providers
-- standards and open-source projects
-- robotics and physical-AI teams
-- enterprise AI groups
-- universities and research labs
-- security, validation, and observability teams
-
-Potential collaboration areas include **protocol research, benchmarks, datasets, interoperability testing, technical integrations, reference implementations, infrastructure support, and public technical demonstrations**.
-
-We are particularly interested in collaborations that produce open, reproducible resources for the wider AI ecosystem.
-
-**Contact:** [agenten@magenta.de](mailto:agenten@magenta.de)
-
----
-
-## Maintained as a living reference
-
-AI interoperability is evolving quickly. Protocol names, versions, implementations, and adoption can change.
-
-This page is maintained as a living reference rather than a frozen taxonomy.
-
-**Last reviewed:** September 2026
-
----
-
-*Interoperability is not about making every AI system the same. It is about making different systems capable of working together.*