Question Everything, Create your own AI System
ABI (Agentic Brain Infrastructure) is the open-source AI Operating System that grounds LLMs in your organization's ontology to create tools that extend human capabilities. An open and accessible alternative to Palantir.
Most AI platforms lock you in: proprietary data models, opaque pipelines, no exit. When the vendor changes pricing or discontinues a model, you have no contingency.
ABI is built for continuity and ownership. Every layer is swappable: LLM providers, infrastructure services, data adapters. Agents reason over context sources you control (knowledge graph, vector store, file system), so your data and logic stay yours regardless of what any upstream vendor does.
It also covers the full stack from ingestion to UI, so you are not stitching together five different tools. The knowledge graph is built on ISO/IEC 21838-2 Basic Formal Ontology (BFO), the open top-level ontology standard used in biotech, defense, and enterprise. BFO-grounded data makes compliance with ISO/IEC 42001:2023 AI Management Systems and the EU AI Act (Regulation 2024/1689) significantly easier, since traceability and auditability are built into the data model from the start.
- Python 3.12+, Git, uv (
curl -LsSf https://astral.sh/uv/install.sh | sh) - Docker Desktop (8GB+ RAM for full stack)
- LLM API keys: any OpenAI-compatible provider (OpenAI, OpenRouter, or equivalent)
uv tool install naas-abi-cli --force --upgrade
abi new project my_ai # replace "my_ai" with your project name
cd my_ai
abi startThe main interface. Chat with Abi, switch agents, manage your workspace, and access your knowledge graph. Open http://localhost:3042 and log in with admin@example.com / Admin1234!.
Every agent is exposed as a REST endpoint. Useful for integrating ABI into your own tools, triggering agents from scripts, or building on top of the platform. Explore the full reference at http://localhost:9879/docs.
Run abi chat to talk to Abi directly from your terminal. No browser needed.
abi start # Start the full stack and open the browser
abi stop # Stop all running services
abi chat # Chat with Abi in the terminal
abi logs # Tail logs from a service (e.g. abi logs abi)
abi stack status # Check health of all running containers
abi config validate # Check your config.yaml for errors
abi new module # Scaffold a new module
abi new agent # Scaffold a new agent
abi new workflow # Scaffold a new workflowEverything in ABI is organized around modules. A module models a domain, connects to its data sources, and exposes intelligent capabilities on top. You enable one with a single line in config.yaml.
A module bundles:
- Agents: LLM-powered agents that reason over the knowledge graph and dispatch to the right domain capability
- Applications: web UI, REST API, and CLI surfaces that expose module capabilities to end users and operators
- Integrations: connectors to external APIs (GitHub, Salesforce, LinkedIn, Notion, ...) that pull data into the module
- Ontologies: OWL/Turtle files that define the domain as typed entities and relationships in a knowledge graph
- Orchestrations: Dagster-based schedules, jobs, and event sensors that automate module execution
- Pipelines: operations that read and write RDF triples to the knowledge graph (add, merge, insert)
- Workflows: structured callable tools exposed to agents and users that query or act on the knowledge graph
Each infrastructure concern is abstracted as a port with a swappable adapter. Change the adapter in config.yaml, no module code changes needed. The community edition ships every service as a Docker container. Enterprise deployments swap each adapter for a managed cloud service or run the whole stack on Kubernetes.
- Triple store (knowledge graph): Community: Apache Fuseki / Enterprise: Amazon Neptune, Stardog, Ontotext GraphDB
- Vector store (semantic search): Community: Qdrant / Enterprise: Pinecone, Weaviate, pgvector, Azure AI Search
- Relational store (agent memory): Community: PostgreSQL / Enterprise: Amazon RDS, Azure Database, Cloud SQL
- Object storage (files and artifacts): Community: MinIO / Enterprise: Amazon S3, Azure Blob Storage, Google Cloud Storage
- Message bus (async task routing): Community: RabbitMQ / Enterprise: Amazon MQ, Azure Service Bus, Google Pub/Sub
- Cache (sessions and hot data): Community: Redis / Enterprise: Amazon ElastiCache, Azure Cache for Redis, Memorystore
- Orchestration (schedules and sensors): Community: Dagster / Enterprise: Dagster Cloud, Airflow on MWAA, Cloud Composer
The Context Engine wires all these services at startup and routes every request to the right agent. Abi acts as the supervisor: it reads the intent behind each request and dispatches to the right domain agent or answers directly from the knowledge graph, vector store, or file system.
Start with the marketplace modules to get running immediately, then use abi new module to model your own domain. Full architecture reference: The ABI Stack.
Your project (created with abi new project my_ai):
my_ai/
├── src/
│ └── my_ai/ # Your module (agents, integrations, ontologies, ...)
├── config.yaml # Base module and service configuration
├── config.local.yaml # Local overrides (ports, credentials, enabled modules)
├── config.remote.yaml # Remote/production overrides
├── docker-compose.yml # Local stack definition (generated)
├── pyproject.toml # Python project, naas-abi-* installed as dependencies
└── .env # Secrets and environment variables
This repo (for contributors):
abi/
├── libs/
│ ├── naas-abi-core/ # Infrastructure adapters (storage, vector DB, message bus, SPARQL)
│ ├── naas-abi/ # Core agents, ontologies, and the Nexus app (API + web UI)
│ ├── naas-abi-cli/ # The abi CLI
│ └── naas-abi-marketplace/ # Domain modules and third-party integrations
├── docs/site/ # Docusaurus documentation site
├── docker/ # Caddy, Dagster, Postgres, and service configs
├── scripts/ # Utility scripts (sync, export, datastore, docs generation)
├── config.local.yaml # Module and service configuration (local)
├── config.yaml # Module and service configuration (base)
└── docker-compose.yml # Local stack definition
abi dev is a no-docker dev runtime for hacking on the project itself. It spawns API, Dagster, Nexus web, and a bundled Oxigraph SPARQL server as native processes, sharing one terminal. Parallel branches (git worktrees) get their own deterministic ports automatically — no collisions, no docker compose shuffling.
git clone https://github.com/jupyter-naas/abi.git
cd abi
# uv + Python toolchain (skip if you already have uv globally)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Node toolchain for the Nexus web app
brew install pnpm # or: npm install -g pnpm
# Install all libs in editable mode
uv sync
# Install the CLI from this repo (editable, picks up your changes)
uv tool install --editable libs/naas-abi-cli --force --upgradeabi dev upYou'll see a status table pinned at the bottom of the terminal with live health for each service:
oxigraph http://127.0.0.1:7878 ● ready
api http://127.0.0.1:9879 ● ready
dagster http://127.0.0.1:11000 ● ready
nexus-web http://127.0.0.1:12000 ● ready
Login: admin@example.com / admin
The default admin credentials (admin@example.com / admin) are written to .env on first boot and picked up by the Nexus seed.
While abi dev up is running:
| Key | Action |
|---|---|
1 / 2 / 3 / 4 |
Filter logs to one service (other services still log to files) |
0 |
Back to interleaved output |
o / a / d / n |
Open Oxigraph / API / Dagster / Nexus web in the browser |
r |
Restart the whole stack in place (no need to quit) |
q / Ctrl+C |
Graceful stop (SIGTERM, 10s grace, then SIGKILL) |
Q |
Force kill (SIGKILL immediately) |
You can also detach with abi dev up -d and use abi dev logs <service> -f, abi dev status, abi dev down.
When the local DB or triple store gets into a weird state:
abi dev down
abi dev nuke # wipes storage/, .dagster/, .abi/dev/logs/, with prompt
abi dev nuke -y --start # nuke + immediate restart, no prompt
abi dev nuke --reset-env # also strip the seeded admin credentials from .envabi dev nuke keeps .env and node_modules by default, and keeps the port allocation stable across nukes.
Each git worktree gets a deterministic per-path port offset, so you can run abi dev up in three branches at the same time without port conflicts:
git worktree add ../abi-feat-x feature-x
cd ../abi-feat-x && abi dev up # different ports automaticallyIf the deterministic port is busy (stale process, three-way collision), the CLI walks the service's 900-port window to find the next free one and persists it in .abi/dev/instance.json.
abi dev up swaps the heavy-weight services for file-based equivalents so it works without Docker:
| Service | Production | Dev (abi dev up) |
|---|---|---|
| Nexus DB | PostgreSQL | SQLite (WAL) |
| Triple store | Apache Jena Fuseki | Bundled Oxigraph HTTP server (pyoxigraph) |
| Vector store | Qdrant server | SQLite + sqlite-vec extension |
| Key-value | Redis | SQLite (WAL) |
| Message bus | RabbitMQ | SQLite (WAL) |
| Object storage | MinIO / S3 | Local filesystem (storage/datastore/) |
| SMTP | Filesystem (storage/email/*.eml) |
All adapters are interface-compatible — config.yaml selects which one. For changes touching schema, concurrency, or filter semantics, also run abi start (the full docker stack) before opening a PR.
Live, written to disk regardless of foreground/background mode:
.abi/dev/logs/api.log
.abi/dev/logs/dagster.log
.abi/dev/logs/nexus-web.log
.abi/dev/logs/oxigraph.log
abi dev logs <service> -f follows one of them.
Copy your .env and config files to the target server, then run:
docker compose -f docker-compose.yml up -dAll services (PostgreSQL, Fuseki, Qdrant, MinIO, RabbitMQ, Redis, Dagster) start as containers. For production workloads, swap the Docker adapters for managed cloud services as described in How It Works.
Need a hosted, managed deployment? Get started on naas.ai or reach out to the team directly.
Collaborative effort between:
- NaasAI - Applied AI Research Lab
- OpenTeams - Open SaaS Infrastructure
- University at Buffalo - Research University
- NCOR - National Center for Ontological Research
- Forvis Mazars - Global Audit & Consulting
We welcome contributions. Open an issue or pull request to get started.
MIT License - see LICENSE
For enterprise support or managed hosting, visit naas.ai.
⭐ If ABI is useful to you, star the repo to help others find it.