Akinakes is not an orchestrator, a chatbot, or a document editor. It's an operational environment — a system of operations where people and AI agents coexist, collaborate, and jointly create, edit, and evolve structured knowledge, under human control, with every action traceable from request to agent chain to document change.
Concretely: people and agents can form flexible organizational structures — teams, bureaus, shared rooms — and work together on real tasks inside a controlled, observable environment, rather than firing off one-shot pipeline runs. This repository is a curated architecture excerpt from the private production codebase (491+ commits, 10 development phases, 641 automated tests, 48 registered agents at last count) — the orchestration engine and platform services, with the business-specific agent implementations, deployment configuration, and product integrations built on top of it left out. It's meant to be read as an architecture reference, not deployed as a turnkey product.
Familiar words, used deliberately differently from industry convention:
- Agent — not "LLM + tool loop." Any participant with a UID and a bus interface: human, model, bureau, or service. The bus treats all of them identically.
- Skill — not a tool call. An executable primitive with a declared input/output schema, required permissions, an autonomy level, and audit requirements. Deterministic logic lives here, kept separate from LLM reasoning.
- Bureau — a collective of people and agents sharing a chat and a set of documents. Indistinguishable from a single agent on the bus — a bureau can itself contain other bureaus.
- Bus — not a message queue. A transport + orchestration layer: publish, match by capability, route chains, and audit every event. The one piece of infrastructure every agent shares.
Everything is an agent, the way Unix says everything is a file: the bus sees no difference between a human, an LLM-backed agent, or a bureau of twenty people — same interface, same routing, same audit trail.
| Component | What it does |
|---|---|
agent_bus/ |
The message bus: agents publish messages, the bus matches them to capable agents by capability-based routing (not explicit addressing), and delivers them. Every message is persisted and queryable by chain ID. |
agent_lib/ |
The client SDK agents use to talk to the bus: AgentBusClient, the AgentLoop run loop, message/agent builders, skill loading and matching, and an LLM adapter layer (ships with a generic OpenAI-compatible adapter). |
platform/human_gate/ |
Parks execution chains pending human approval when a skill's declared autonomy level requires it, and resumes them once approved. |
platform/skill_registry/ |
The catalog of execution primitives agents can invoke — each with a declared input/output schema, required permissions, autonomy level, and audit requirements. |
platform/agent_registry/ |
Tracks which agents exist, their declared capabilities, and their current status. |
platform/agent_box/ |
Sandboxed lifecycle management for agent processes (start/stop/status), including Docker-backed isolation. |
platform/acl_service/ |
Access-control checks — which subject can do what to which resource — the basis for organizational structure (teams, bureaus, visibility scopes). |
platform/document_service/ |
The living-document layer: versioned, structured documents with sections, edits, bindings, and tags, linked back to the agents and decisions that produced them — where people and agents jointly evolve shared knowledge. |
platform/chat_gateway/ |
An example agent that bridges human chat messages onto the bus — a reference for how a real agent consumes agent_lib. |
tests/ |
A sample of the automated test suite (Phase 1: acceptance, integration, Human Gate, and Skill Registry tests) — a representative slice of the full 641-test suite the production system runs on every change. |
Every skill declares its own autonomy level; the system enforces it rather than trusting agents to self-police:
| Level | Behavior |
|---|---|
ManualOnly |
The AI suggests — nothing executes without a human doing it. |
SuggestOnly |
The AI proposes in chat; a human triggers execution. |
ApproveBeforeExecution |
The AI queues actions; a human approves each one before it runs. |
AutoWithinPolicy |
The AI acts on its own within defined constraints. |
FullAutoSandbox |
Fully autonomous execution, reserved for isolated sandbox environments. |
AI proposes. Human approves. The system enforces — not the agent's own judgment about when to ask.
See ARCHITECTURE.md for the deeper design writeup — the OS analogy, the bureau and competition model, the document/audit/ACL layers.
The private codebase includes concrete agent implementations built on top of this engine (writer
agents, planner agents, research agents, and more — see agent_lib's actions/ package for the
extension point they hook into), a specific LLM backend adapter, voice/STT/TTS integration,
several more platform services tied directly to the commercial products built on Akinakes, and
all deployment/ops tooling. Those are excluded here because they're either proprietary business
logic or contain infrastructure specifics that don't belong in a public reference.
Each service under agent_bus/ and platform/*/ is an independent FastAPI app with its own
requirements.txt and Dockerfile — install its dependencies and run it with uvicorn main:app.
Services that depend on agent_lib (platform/human_gate, platform/chat_gateway) need it on
PYTHONPATH. There's no single docker-compose here (the production one wires in the excluded
services too) — treat this as source to read, adapt, and wire up yourself rather than a
one-command deploy.
MIT — see LICENSE.