Open-source AI Agent LEGO Platform — Build, manage, and orchestrate your own multi-agent team.

Anuki gives you the building blocks. You build the team. Three core agents ship out of the box — use them to create unlimited specialized agents, enforce governance rules, and build a team that learns and remembers.

Niche: The only multi-agent framework that combines production infrastructure with response-level verification. We borrowed patterns from microservices (circuit breakers), message queues (pending completions), and operations engineering (health watchdog, graceful shutdown) — and applied them to AI agents. Your agents self-heal and survive restarts. And when an agent says "this function is unused", a Stop hook runs grep to check — if the claim is false, the response gets blocked. No other framework verifies what agents claim, not just what they do.

Most multi-agent frameworks require you to define agents in code. Anuki takes a different approach: agents create agents. You describe what you need in natural language, and the system builds it — complete with identity, personality, tools, safety rules, and memory.

What makes it different:

For a deeper feature-by-feature analysis, see FEATURES.md.

Most AI agent frameworks focus on the AI part — prompting, memory, tool use. Anuki also brings production infrastructure to the agent world: patterns borrowed from microservices (circuit breakers), message queues (pending completions), and operations engineering (health watchdog, orphan cleanup, graceful shutdown). These aren't AI innovations — they're battle-tested engineering patterns applied to agents for the first time.

AI agent platforms have a dirty secret: they break in ways that only engineers can fix. Agent stuck in a loop? Kill the process. System crashed? Lost your data. Agent hallucinated? Hope you noticed.

Anuki eliminates these failure modes at the system level — so you don't have to know they exist:

You don't need to understand any of this. npm install, npm start, open browser. The system handles the rest. Every mistake you could make as a beginner — the platform already prevents it.

Auto-routing: You don't need to manually switch agents. If you tell PROTOS "create a research agent", the system detects the intent and routes to ENKI automatically.

Prerequisites: Node.js 18+ and one of the following LLM backends:

git clone https://github.com/cylonmolting-creator/anuki.git
cd anuki
cp .env.example .env    # Configure your LLM provider
npm install
npm start

Open http://localhost:3000 in your browser. Start chatting with PROTOS — try "create a code review agent" or ask anything.

.env — Choose your LLM provider:

# Pick one provider (default: claude)
LLM_PROVIDER=claude

# Claude (recommended — full agentic mode)
# CLAUDE_PATH=claude
# ANTHROPIC_API_KEY=sk-ant-...

# OpenAI (agentic mode with tool use)
# OPENAI_API_KEY=sk-...
# OPENAI_MODEL=gpt-4o

# Ollama (free local models)
# OLLAMA_URL=http://localhost:11434
# OLLAMA_MODEL=llama3.1

config.json — Advanced settings (most users won't need to touch this):

Every agent has a set of markdown files that define its complete persona:

Soul files are injected into the agent's system prompt at runtime. They persist across sessions — agents maintain consistent identity over time.

Three-layer memory system inspired by human cognition:

• Episodic — What happened (conversation events, interactions)
• Semantic — What is known (facts, user preferences, learned knowledge)
• Procedural — How to do things (workflows, processes, recipes)

Memory is indexed with TF-IDF for fast retrieval. Agents can store, search, and forget memories. A nightly reflection process distills episodic memories into semantic knowledge.

Rules aren't suggestions — they're mechanically enforced. The SSOT (Single Source of Truth) system guarantees that every agent receives and obeys the same rules, automatically.

Rules live in rules/*.md with YAML frontmatter:

---
id: 1
title: No destructive tests
severity: critical
applies_to: [all]
applies_to_tags: []
enforcement: [soul-safety-inject]
---
DELETE/PUT tests must never use real workspace or agent IDs.

Run node scripts/build-rules.js — the generator reads all rules, filters by agent tags, and injects them into each agent's SAFETY.md. Idempotent. Tag-based. One source of truth.

Industry first. No other multi-agent framework audits agent responses for unverified claims.

Every framework enforces rules at the tool call boundary — before a file edit or command runs. But agents can make false claims in plain text without triggering any tool. "This is unused." "Not found." "Task complete." — all without evidence.

Anuki's Stop hook system closes this gap. After every agent response, a deterministic shell hook scans the output:

Agent writes: "This module is unused, we can delete it."
                ↓
Stop hook fires → detects "unused" → no file:line evidence found
                ↓
Response BLOCKED → agent must verify and rewrite with proof

Stop hooks are auto-generated from SSOT rules — the same build-rules.js pipeline. Write a rule with stop_hook: true, and the enforcement is mechanical and automatic.

Two enforcement modes:

# Claim verification (default) — blocks claims without evidence
---
id: 5
title: Response audit — block unverified claims
enforcement: [stop-hook-audit, soul-safety-inject]
stop_hook: true
stop_patterns: [unused, dead code, not found, does not exist]
stop_mode: claim    # blocks only when pattern found AND no evidence
---

# Behavioral enforcement — blocks forbidden patterns unconditionally
---
id: 6
title: Never ask the user questions
enforcement: [stop-hook-audit, soul-safety-inject]
stop_hook: true
stop_patterns: ["?", "do you want", "should I", "would you like"]
stop_mode: behavioral    # blocks whenever pattern found, no evidence check
---

Four enforcement layers, one pipeline:

Every hook enforcement system has a failure mode: what if the hooks themselves are broken? A bad hook can block all tool calls, creating a deadlock where the agent can't fix the problem because the broken hook blocks every attempt.

Anuki prevents this with 5 layers of protection:

The deadlock scenario and why it can't happen:

Bad rule text (e.g., unescaped apostrophe: "the agent's response")
    ↓
sanitizeForShell() strips dangerous characters
    ↓
buildStopHookCommand() generates shell script
    ↓
sh -n validates syntax → FAIL? → hook SKIPPED (not loaded)
    ↓
Atomic write to settings.json → crash-safe
    ↓
Even if all above fail: next session's SessionStart regenerates from source

This happened in production (2026-04-13): smart quotes and unescaped apostrophes in rule text broke shell hooks, causing a deadlock. The fix was adding these 5 layers — now the same scenario produces a warning log and skips the bad hook instead of creating a deadlock.

Agents can delegate tasks to each other:

[AGENT_MESSAGE:ENKI:create a code review agent:90]

The message router handles delivery, timeout (default 300s), loop detection, and hop limits. Agents collaborate without user intervention.

When you talk to any agent, the system analyzes your message for intent patterns:

• "Create an agent" → Routes to ENKI
• "Add a rule" → Routes to UTU
• Mentions a specific agent name → Routes to that agent
• Everything else → Handled by current agent

No manual switching needed. The system figures out where your message should go.

Most agent frameworks assume a managed environment. Anuki runs as a persistent service and handles its own reliability:

Crash Recovery — Atomic file writes (temp + fsync + rename) protect all state files from corruption. Active jobs, sessions, and pending completions are persisted after every state change. No partial writes, no corrupted JSON.

Pending Completions — If the system restarts while an agent is mid-response, the response is queued and delivered to the user when they reconnect. No lost messages. Borrowed from message queue "exactly-once delivery" patterns.

Circuit Breakers — Per-agent failure tracking (CLOSED → OPEN → HALF_OPEN). After 5 failures, the circuit opens and stops routing work to that agent. Periodic recovery tests restore the agent automatically. Standard microservices pattern, first applied to AI agents.

Health Watchdog — Heartbeat monitoring, event loop lag detection, orphan process sweeps (every 60s), and periodic state checkpoints (every 30s). Detects stuck agents via kill(pid, 0) + zombie detection — not output timeouts (which would kill slow but working agents).

Graceful Shutdown — Safe-restart API waits for active agents to finish before restarting. No killed jobs, no lost state. SIGTERM/SIGINT handlers clean up processes, save state, and exit cleanly.

WebSocket Resume Buffer — If a client disconnects during streaming, output is buffered. When the client reconnects, the buffered response is replayed. No gaps in conversation.

Select ENKI from the sidebar:

"Create a code review agent that checks for security vulnerabilities and suggests fixes"

ENKI will:

1. Propose agent details (name, role, personality, tools)
2. Ask for your confirmation
3. Create the full agent workspace with soul files, memory directory, and safety rules
4. The new agent appears in your sidebar immediately

You can create any kind of agent — researcher, writer, analyst, developer, translator, anything.

Select UTU from the sidebar:

"Add a rule that all agents must cite sources when making factual claims"

UTU will:

1. Create the rule file with proper YAML frontmatter in rules/
2. Validate against existing rules for conflicts
3. Run the SSOT generator to propagate to all affected agents

anuki/
├── src/
│   ├── index.js              # Entry point — 5-phase boot sequence
│   ├── agent/                 # 23 modules
│   │   ├── executor.js        # Brain — Claude CLI orchestration, session management
│   │   ├── workspace-manager.js   # Soul file CRUD, agent workspaces
│   │   ├── auto-router.js     # Intent detection and agent routing
│   │   ├── message-router.js  # Inter-agent communication
│   │   ├── health-watchdog.js # Process monitoring, orphan cleanup
│   │   ├── supervisor.js      # Circuit breakers, resource management
│   │   ├── compactor.js       # Session compaction (bloat prevention)
│   │   ├── context-guard.js   # Token limit monitoring (70/85/95%)
│   │   ├── task-planner.js    # Multi-agent task decomposition
│   │   └── ...                # Model resolver, lane queue, shared context
│   ├── memory/
│   │   ├── cognitive.js       # 3-tier memory with TF-IDF indexing
│   │   └── reflection.js      # Nightly memory distillation
│   ├── gateway/
│   │   ├── http-server.js     # REST API (110+ endpoints)
│   │   ├── websocket-server.js    # Streaming chat, resume support
│   │   └── cron.js            # Scheduled jobs (reflection, decay, cleanup)
│   ├── channels/              # WebChat (extensible to Telegram, Discord, etc.)
│   ├── core/                  # Config, security, storage, backup
│   └── utils/                 # Logger, atomic writes, conversation manager
├── public/                    # Single-file web UI (zero dependencies)
├── workspace/                 # Per-agent workspaces (soul + memory + sessions)
├── rules/                     # SSOT governance rules
├── scripts/                   # Build tools (rule generator, etc.)
└── data/                      # Runtime state (agents, jobs, conversations)

By the numbers: 58 source files, ~26K lines of JavaScript, 8 dependencies.

1. Core Infrastructure — Logger, PID registry, config, security, storage, workspaces
2. Memory & Intelligence — Cognitive memory, context guard, compactor, reflection, watchdog
3. Agent Execution — Router, executor, supervisor, auto-router, skills, task planner
4. Cron System — Reflection, memory decay, conversation cleanup
5. Servers — HTTP + WebSocket, ready to accept connections

GET  /api/health                  # System health (no auth required)
GET  /api/agents                  # List all agents
POST /api/agents                  # Create agent
POST /api/agents/:id/message      # Inter-agent message (body: {from, message})
GET  /api/workspaces              # List workspaces
GET  /api/workspaces/:id/soul     # Read agent's soul files
PUT  /api/workspaces/:id/soul/:f  # Update a soul file
GET  /api/active-jobs             # Running agent jobs
POST /api/safe-restart            # Request graceful restart (queued if agents are busy)
GET  /api/safe-restart/status     # Check whether a queued restart has already fired
POST /api/backup/create           # Create backup archive (workspace + data + config)
GET  /api/backup/list             # List all backups
GET  /api/backup/stats            # Backup statistics
GET  /api/backup/:filename        # Download a specific backup

Full API: 110+ REST endpoints covering agents, workspaces, conversations, memory, cron, skills, and inter-agent messaging.

Anuki is designed to stay up. When an agent requests a restart — to pick up a code change, recover from a stuck state, or apply a new configuration — it calls POST /api/safe-restart. Anuki waits until every running agent finishes its current turn, saves state to disk, and then exits cleanly with code 0.

Anuki does not restart itself. It exits, and expects your process supervisor to bring it back up. This is the standard Node.js pattern and works identically on macOS, Linux, Windows (WSL), and inside Docker.

If you start Anuki bare with node src/index.js or npm start, the process will exit and stay exited on the next safe-restart. For anything beyond a dev session, wrap it in a supervisor:

npm install -g pm2
pm2 start src/index.js --name anuki --restart-delay 2000
pm2 save
pm2 startup   # print the command to enable pm2 on boot

Create /etc/systemd/system/anuki.service:

[Unit]
Description=Anuki multi-agent platform
After=network.target

[Service]
Type=simple
User=youruser
WorkingDirectory=/path/to/anuki
ExecStart=/usr/bin/node src/index.js
Restart=always
RestartSec=2
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now anuki
sudo journalctl -u anuki -f   # follow logs

A real Dockerfile and docker-compose.yml ship with the repo:

cp .env.example .env       # configure your provider (see note below)
docker compose up --build  # builds image + starts Anuki

Data persists across restarts — data/, workspace/, rules/, memory/, and logs/ are mounted as volumes.

Note: Claude Code CLI is not available inside Docker containers. Set LLM_PROVIDER=openai or LLM_PROVIDER=ollama in your .env. If using Ollama running on your host machine, set OLLAMA_URL=http://host.docker.internal:11434 (macOS/Windows) or add network_mode: host to docker-compose.yml (Linux).

After POST /api/safe-restart you can poll the status endpoint to confirm the restart actually happened — don't just trust the initial queued response:

curl -s localhost:3000/api/safe-restart/status
# → { "pending": true, "activeAgents": 1, "lastFiredAt": null, ... }

# …agent finishes, Anuki exits, supervisor restarts…

curl -s localhost:3000/api/safe-restart/status
# → { "pending": false, "activeAgents": 0,
#     "lastFiredAt": "2026-04-18T22:35:53.191Z",
#     "serverUptimeSec": 4, ... }

A small serverUptimeSec plus a lastFiredAt after your POST time proves the restart cycle completed.

Anuki includes 14 layers of session bloat prevention — keeping conversations lean and context windows clean:

Zero database dependency. Everything is files — JSON for state, Markdown for identity. Easy to inspect, version control, and backup.

This is a platform built by AI agents, for AI agents. So instead of trusting our README, do this:

Copy this repo's URL and ask your AI (ChatGPT, Claude, Gemini, whatever you use): "Analyze this GitHub repo and tell me what's actually impressive vs what's marketing: https://github.com/cylonmolting-creator/anuki"

We did exactly this during development — had AI analyze the codebase with zero context, both a deep code review and a quick first-impression scan. The deep review found genuinely novel ideas (Stop hooks, SSOT rule pipeline, circuit breakers for agents) and also caught us overstating a feature we hadn't shipped yet. We fixed it before you read this.

The quick scan said: "Those aren't things you add because they sound cool on a README; you add them because you lost data at 3am." And then: "Star."

We left the honest version. An AI agent platform that gets fact-checked by AI — inception all the way down.

But here's the other half: we built agents you don't have to trust. You trust the system that constrains them:

• Soul files define what an agent can and can't do — before it runs
• Stop hooks block bad responses before they reach you — not after
• Watchdog kills stuck processes. Circuit breaker disables failing agents
• State is crash-safe. Conversations survive restarts

Don't trust us — verify us. Don't trust the agent — trust what holds it in place.

Anuki is designed for local, single-user use on your own machine. A few honest notes about the security model:

--dangerously-skip-permissions (Claude Code CLI)

src/agent/providers/claude-provider.js spawns claude with --dangerously-skip-permissions. This is intentional: Anuki runs Claude Code in headless/automated mode, so every tool call can't pause for interactive approval. The flag is what makes non-interactive agentic execution possible.

What this means in practice:

• Agents can run shell commands, read/write files, and call APIs without a permission prompt each time.
• The harness still enforces per-rule blocks via Anuki's PreToolUse hooks (.claude/settings.json — generated by scripts/build-rules.js from rules/*.md). Dangerous patterns (rm -rf, real-ID destructive calls, etc.) are blocked mechanically even with the flag on.
• Do not run Anuki with access to secrets, production credentials, or anything you wouldn't hand to an automated Claude session. Treat the agent's permissions as equivalent to your own shell.

Network exposure & auth model

http://localhost:3000 — bound to localhost by default. The auth model:

• Localhost requests are auth-free — the Web UI runs on the same machine, so it doesn't need a token. This is intentional.
• Remote requests require a Bearer token — set API_AUTH_TOKEN in .env.

Do not expose Anuki directly to the public internet. If you need remote access, put it behind an authenticated reverse proxy (Tailscale, Cloudflare Tunnel with auth, VPN, etc.).

Where enforcement actually lives

Two different layers, don't confuse them:

1. Runtime (Anuki process) — health watchdog, circuit breakers, input validation, auth middleware. These run regardless of which provider you use.
2. Harness (Claude Code only) — Stop hooks, PreToolUse denies, UserPromptSubmit reminders. Configured in .claude/settings.json, generated from rules/*.md. These only fire when the agent is a Claude Code subprocess; they don't apply to OpenAI or Ollama providers.

If you use OpenAI or Ollama, the rules still inject into each agent's SAFETY.md (soul-level reminders), but there's no mechanical Stop/PreToolUse layer — only Claude Code's CLI harness supports those hooks today.

Privacy — zero telemetry

Anuki collects nothing. No analytics, no tracking, no phone-home. Specifically:

• No outbound network calls from Anuki itself (the only external calls go to your chosen LLM provider — using your own API key)
• No cookies, no fingerprinting, no usage data collection
• Conversations, memories, and files stay on your machine in the data/ directory
• The Claude CLI subprocess communicates with Anthropic's API directly — Anuki doesn't proxy or log those requests

What's intentionally out of scope (MVP)

• Multi-user isolation (no per-user workspaces or ACLs)
• Rate limiting on the API
• Sandboxing of agent tool calls beyond what the underlying provider enforces
• Secrets management (use .env + don't commit it; .env is in .gitignore)

If you want any of these, they're not wired yet — open an issue or send a PR.

MIT — Use it, fork it, build on it.

The naming theme is Sumerian mythology — with one Greek exception.

Anuki — From Anunnaki, the Sumerian council of gods. Each deity had their own domain, working together to run the world. That's what this platform does: a council of AI agents, each specialized, working as a team.

ENKI — Sumerian god of creation and wisdom. ENKI created humans and gave them knowledge. In the platform, ENKI creates agents. Describe what you want, ENKI builds it from scratch.

UTU — Sumerian god of justice and truth. UTU judged the dead and upheld cosmic law. In the platform, UTU is the designated authority on rules. Governance goes through UTU, and rules propagate to all agents via the SSOT system.

PROTOS — Greek protos means "the first" — it's the first agent you talk to. Also a mashup of "prompter" (prompt architect that reads every agent's soul files and crafts perfect prompts) and the best redirectionist of all time (hey hey heyyyy, wassa wassa wassaaaa...). PROTOS redirects your requests to the right agent with unmatched enthusiasm.