Nexus
The Agent Operating System for software development.
Nexus lets you create agents as runtime-defined objects in a UI: you create an agent, attach skills, choose memory scopes, set permissions, and then schedule it on Kubernetes — without changing code. An agent is a database document plus runtime config, not a compiled Rust type.
This site is the canonical documentation: architecture, core concepts, per-repository reference, the API surface, integrations, and the operations guide.
The one design principle
Agents are data. Skills are data. Memory is data. Execution is isolated. Nexus Core is the only authority. Plane is only a projection.
Everything else follows from this. The Kubernetes pod that runs an agent does not need to know about agent types — it receives a config payload and becomes whatever that payload describes. The same container image runs a planner, an implementer, a reviewer, or a tester depending on the run config.
Read in this order
| Section | What you'll find |
|---|---|
| Architecture | The one-screen system diagram, the five substrates, deployment shape |
| Concepts | Agents, skills, memory scopes, blueprints, permissions, lifecycle |
| Data model | MongoDB collections and document shapes |
| Runtime flows | Task lifecycle, agent run, board sync |
| Repositories | Every Git project and the libraries each one uses |
| Technical overview | Per-component deep dives (Core, worker, runner, telegram, UI, crates) |
| API reference | The REST surface served by Nexus Core |
| Integrations | Plane board sync, Telegram command gateway |
| Operations | Deploy on Kubernetes, GitOps, observability |
| Security & permissions | Tool permissions, agent tokens, isolation boundaries |
| Roadmap | What to build first, in order |
| Glossary | Specialized terms — agents, skills, memory, runtime |
| FAQ | Common questions about the model |
The 30-second pitch
- Agents are created in the UI, not hardcoded. Name, model, skills, memory policy, tools, permissions, and Kubernetes resources are all fields on a document.
- Skills are reusable, versioned, testable instructions assigned to agents — procedural memory you can edit and publish.
- Memory is scoped and reviewable (
global,project,agent_private,task,user_profile) so agents don't pollute a single global blob. - Execution is isolated: each run is a Kubernetes Job built from a config payload, reporting events back to Nexus.
- Boards are projections: Nexus owns its own board, then syncs to Plane (Jira later). Hermes-style durable collaboration, but distributed and external-board compatible.
What's running where
The platform is implemented across a small set of repositories:
- nexus-platform — a Rust workspace
containing Nexus Core (axum API + orchestration engine), the worker, the
generic agent runner, the Telegram gateway, the React admin UI, and the
shared crates (
nexus-domain,nexus-db,nexus-events,nexus-board,nexus-k8s,nexus-skills,nexus-memory,nexus-llm, and more). - nexus-agent-images — the Docker images agent runs execute inside (base, rust, node, python, devops, solana).
- nexus-gitops — Helm charts, Argo CD apps, Flux manifests, per-environment values, RBAC, and cluster config.
- nexus-examples — sample projects and agents to exercise Nexus safely.
- nexus-docs — this site.
Going deeper
- For platform engineers: start at Architecture and Repositories.
- For operators running Nexus: the operator guide and Operations.
- For people authoring agents and skills: the agent author guide and Concepts.