--- sidebar_position: 3 slug: /architecture/overview slide: /diagrams/abi-stack-technical.svg slide_alt: Zones from the top, inside a deployment band. Surfaces (Nexus web, REST API, MCP server, abi CLI). Engine (agents, model registry, kernel services). Real-time fabric on NATS and JetStream (service calls, the bus, module jobs, discovery). Modules beside identity and secrets. Stores behind services, each with its shipped backends. Email and code workspaces. question: How is a running ABI system put together? --- # Overview ABI is an engine that loads modules. An agent is a model, a system prompt, and tools; the rest of a module gives agents tools or data. The engine reaches every backend through a service, so the same module runs on local files on a laptop and on shared servers in production: only `config.yaml` changes. The diagram reads from the top: people and programs come in through the surfaces, the engine runs agents and services, the real-time fabric connects processes, and the stores sit behind services. ## Surfaces Surfaces call the engine. They are not the engine. - **Nexus web**: the collaboration surface where people and agents work together (Next.js). - **REST API**: FastAPI on port 9879. Agents, workflows, pipelines and tools that expose an endpoint are mounted there, and Nexus adds its own routes to the same process. - **MCP server**: exposes the API's agents as MCP tools. - **abi CLI**: `abi chat` in a terminal, `abi dev up` to run a project, `abi deploy` to ship it. ## Engine - **Agents**: a model, a system prompt and tools. Workflows, pipelines and integrations become tools. - **Model registry**: the chat and embedding models of the provider modules that are enabled. `services.model_registry` sets the defaults that agents without an explicit model use. - **Kernel services**: the ports everything else calls, from the triple store and object storage to the bus, secrets and email. Each takes its adapter from `config.yaml`: one per service, except the cache (one per tier) and secrets (a list read in order). [Services and adapters](/architecture/services-and-adapters) lists every adapter the engine ships, what each preset runs, and how to plug in your own. The [Architecture builder](/architecture/builder) draws the architecture and writes the `services:` block for any combination of them. ## Real-time fabric With a `nats:` block in `config.yaml` (the default for `abi new project`), processes talk over [NATS](/architecture/real-time-fabric): - **Service calls**: each kernel service answers requests on `abi.svc..v1.*`. Remote modules and `nats_rpc` clients reach the serving engine this way. - **Bus**: the `bus` service runs on JetStream. - **Module jobs**: schedules and event triggers on JetStream, with no central scheduler. - **Discovery**: remote modules register in the engine's module registry and hold a lease. Without `nats:` everything stays in one process: the bus takes one of its adapters for projects without NATS (legacy), and module jobs do not run. ## Modules - **Engine modules** run in the engine process and are listed under `modules:` in `config.yaml`. - **[Remote modules](/architecture/remote-modules)** run in their own process with `naas-abi-sdk` and reach the engine only through NATS. ## What a module contains Agents and tools are the key components. Most of the rest give an agent tools or data. | Piece | Job | |---|---| | **Agents** | Model + system prompt + tools, from `agents/`. See [Agents](/user-guide/build/agents/creating-an-agent). | | **Apps** | Extra UI on a module. See [Apps](/user-guide/build/applications/nexus). | | **Assets** | Files a module ships, such as an agent's avatar. The API serves `assets/public/`. See [Assets](/capabilities/build/assets/overview). | | **Integrations** | One API or system. See [Integrations](/user-guide/build/agents/creating-an-integration). | | **Models** | Model definitions in `models/`, registered in the model registry. Provider modules ship them. | | **Ontologies** | BFO / CCO / domain RDF. See [Ontologies](/user-guide/build/knowledge-graph/creating-an-ontology). | | **Pipelines** | External data into triples, from `pipelines/`. See [Pipelines](/user-guide/build/knowledge-graph/creating-a-pipeline). | | **Skills** | Not module code: reusable prompts saved in a Nexus workspace and run in the chat with `/`. See [Skills](/capabilities/build/skills/overview). | | **Tools** | What the agent calls, from `tools/`. | | **Workflows** | Intent to execution, from `workflows/`. See [Workflows](/user-guide/build/agents/creating-a-workflow). | ## Stores behind services Data lives where the service's adapter puts it. The `abi dev` preset (`config.yaml`) names Oxigraph (triple store), SQLite + sqlite-vec (vector store), SQLite (document), DuckLake (dataset), Filesystem (object storage), Python (key-value), dotenv (secret). The Docker Compose preset (`config.local.yaml`) names Apache Jena (triple store), Qdrant (vector store), PostgreSQL (document), DuckLake (dataset), S3 (object storage), Redis (key-value), dotenv (secret), Filesystem (email). Services a template leaves out run the engine's default. [Data plane](/architecture/data-plane) goes through each kind of data and its backends. ## Identity and secrets - **Secret service**: resolves the `{{ secret.NAME }}` references in `config.yaml` from a list of adapters (a `.env` file first, by default). - **Sign-in**: Nexus accounts sign in with a password or a magic link. ## Deployment The same project runs as processes on your machine (`abi dev up`), in Docker Compose (`abi start`, with Caddy terminating TLS), or on Dokploy (`abi deploy dokploy`). The configuration file changes with the target (`config.yaml`, `config.local.yaml`, `config.remote.yaml`, or the `config.dokploy.yaml` that `abi deploy dokploy` writes); the code does not. ## Two operators Same source. Community: you operate it. Enterprise: we operate it with you. Details: [Community](https://naas.ai/community), [Enterprise](https://naas.ai/enterprise), [air-gapped](/user-guide/deploy/air-gapped).