---
sidebar_position: 5
title: "Interoperability"
slug: /architecture/interoperability
question: Which open protocols can ABI clients use?

---

# Interoperability

ABI is built on open protocols at every integration point. Every interface uses a standard that exists independently of ABI: no proprietary SDK required, no lock-in to a particular cloud, identity provider, or model vendor.

---

## Semantic interoperability

The knowledge graph is queryable with SPARQL, the W3C standard for RDF query. In code, `services.triple_store.query(sparql)` runs a query against whichever adapter `config.yaml` names, and a remote module sends the same query over NATS. When the adapter is a server (Oxigraph, Apache Jena Fuseki, AWS Neptune), that server also has its own SPARQL endpoint, so any SPARQL client (Apache Jena tooling, Python `SPARQLWrapper`, custom scripts) can query it directly; the Docker Compose stack adds YasGUI, a SPARQL editor pointed at its Fuseki. Embedded and file-backed adapters have no endpoint of their own. [Services and adapters](/architecture/services-and-adapters#triple-store) lists the adapters and where each keeps its data.

Ontologies are authored and stored as OWL Turtle (`.ttl`) files. They can be exported, imported, merged with external ontologies, and versioned in Git. An ontology built for ABI is portable to any OWL-compatible reasoner or triple store.

ABI does not run an OWL reasoner of its own at query time: SPARQL runs against the triples the store holds. Because ontologies are plain OWL, you can apply any OWL-compatible reasoner, or a triple store configured with inference, to the same files and data.

---

## Model interoperability

Every agent accepts a `ChatModel` interface rather than a hardcoded provider. A `ChatModel` wraps a LangChain chat model, and the marketplace has provider modules for OpenRouter, OpenAI, Anthropic, Azure, Bedrock, Gemini, Mistral, Ollama and more. Which models exist is decided by the model registry and the modules you enable.

The MCP server exposes the API's agents as tools for any MCP-compatible AI client, such as Claude Desktop or Cursor, without integration code. It reads the API's OpenAPI document at startup and registers one tool per agent, so a new agent appears the next time the MCP server starts.

---

## Data interoperability

Every store behind an engine service is an open format or an open protocol, so data written through ABI stays readable without it. What you reach depends on the adapter `config.yaml` names; [Services and adapters](/architecture/services-and-adapters#services) gives the adapter and the backend of each service.

- **Objects.** With the `s3` or `r2` object storage adapter, files live in an S3-compatible bucket that any S3 tool (AWS CLI, boto3, DuckDB, Spark) can read and write; the Docker Compose stack runs MinIO for it. With `fs` they are plain files on disk.
- **SQL.** With the `postgresql` adapters, the documents of the Document service (agent memory, job runs) and the event log are PostgreSQL tables any SQL client or BI tool can read; with `sqlite` they are SQLite files. Nexus keeps its own application data (users, workspaces, conversations) in PostgreSQL.
- **Datasets.** The dataset service uses DuckLake: Parquet data files and a catalog in SQLite or PostgreSQL, readable by DuckDB.

The REST API (FastAPI) provides programmatic access to every agent, workflow and pipeline of the engine's modules. Its OpenAPI document is at `/openapi.json`, browsable at `/docs`. The agent endpoints take the shared `ABI_API_KEY` as a bearer token; the Nexus API signs users in and issues JWTs (`/api/auth/token`).

---

## Service interoperability

The kernel services (object storage, triple store, datasets, documents, secrets, key-value, events, vector store and the rest) are versioned protobuf contracts on the NATS broker (`abi.svc.<service>.v1.*`). The contracts live in `naas-abi-proto`, and `naas-abi-sdk` gives async clients for them. A module written against them runs in its own process, in any deployment, with no knowledge of the backends; any NATS client that implements a contract and presents a valid service token can call it. Another engine reaches them the same way, with the `nats_rpc` adapter. See [Real-time fabric](/architecture/real-time-fabric) and [Remote modules](/architecture/remote-modules).

---

## Code interoperability

Integrations, pipelines, workflows, and agents are plain Python. No proprietary DSL, no framework-specific decorators, no generated code that cannot be read directly.

`naas-abi-core` is a standard Python package installable via `pip` or `uv`. Any Python project can depend on it to use the Engine, service adapters, or ontology tooling independently of the full ABI stack.

Modules are Python packages. A module built for `naas-abi-marketplace` is a versioned, importable package with no ABI-specific publishing pipeline; it can be distributed on PyPI, installed from a private registry, or linked locally.

---

## Security interoperability

Nexus has its own user accounts (password and magic-link sign-in) and signs users in with JWTs through a standard OAuth2 password flow (`/api/auth/token`). It has no built-in SAML or OpenID Connect: put an identity-aware proxy in front of the API (Caddy, the bundled reverse proxy, can sit in the chain) without modifying application code.

Authorization is enforced at the API boundary through the roles of organizations and workspaces. No cloud IAM and no proprietary access control system.

Secrets are read through the [secret service](/architecture/services-and-adapters#secret), a list of adapters read in order, and `config.yaml` refers to them as `{{ secret.NAME }}`. The `dotenv` adapter reads a `.env` file and the process environment, so HashiCorp Vault, AWS Secrets Manager, or any provider that can inject environment variables or write the `.env` file at deploy time works without code changes.

In the Docker Compose stack, containers talk over the internal Docker network, and the NATS broker's client and monitoring ports are published on 127.0.0.1 only. TLS termination is handled by Caddy with your own certificates, or Let's Encrypt for a public domain. Traffic to the broker is not encrypted: see [Security model](/developers/architecture/security).

---

→ [Deployment models](/user-guide/deploy/deployment-models)
