Ouroboros
The Ouroboros server provides a comprehensive MCP interface for the Ouroboros Agent OS, enabling specification-first AI coding workflows that span from vague ideas to verified codebases through an iterative, evolutionary process.
Requirements & Specification Clarity: Conduct Socratic interviews to expose assumptions, generate immutable seed specifications (blocking until ambiguity is resolved), and handle brownfield repository contexts.
Execution & Automation: Run full auto pipelines (interview → seed → execute), execute seeds with model-tier routing and configurable efficiency, and manage background jobs with status polling, waiting, and cancellation.
Evaluation & Quality Assurance: Perform 3-stage evaluations (mechanical, semantic, multi-model consensus), general QA verdicts, and drift measurement to track alignment with the original seed.
Evolution & Convergence: Engage persistent evolutionary loops (Ralph) to converge ontologies and codebases, run single evolution steps, and rewind lineages for alternative paths.
Observability & Control: Monitor session and project status, view live acceptance-criteria trees and dashboards, query event history, and cancel executions or jobs mid-flight.
Intervention & Unstuck Mechanisms: Generate lateral thinking approaches via five personas, send audited session signals, and record conductor decisions for provenance.
Brownfield & PM Workflows: Scan and manage existing codebases, conduct product manager interviews, and generate PRDs.
Enables Ouroboros workflow commands and tools within GitHub Copilot CLI sessions.
Enables Ouroboros workflow commands and tools within Hermes CLI sessions.
Turn a vague idea into a verified, working codebase -- across Claude Code, Codex CLI, OpenCode, Hermes, Gemini, Kiro, Copilot, Pi, Zcode, Goose, GJC, Antigravity, and Grok.
Ouroboros is an Agent OS for AI coding: a local-first runtime layer that turns non-deterministic agent work into a replayable, observable, policy-bound execution contract. It replaces ad-hoc prompting with a structured specification-first workflow: interview, crystallize, execute, evaluate, evolve.
The Ouroboros Agent OS Stack
Like any OS, Ouroboros is split into a stable OS layer of primitives, an application layer of domain workflows, and a shell that humans actually sit in front of. Three repos, one stack:
Layer | Repo | Role | What it gives you |
Shell (terminal client) | Native terminal UI for running | TUI, wonderTool decision pickers, MCP pane state, command discovery | |
Apps (domain workflows) | UserLevel plugin contract — composes core primitives into installable domain programs (PR ops, Jira sync, incidents, releases) | Plugin manifest, scoped permissions, audit/provenance, reference plugins | |
OS (this repo) | Agent OS core — Seed, Ledger, Runtime, MCP, safety boundaries |
|
How they connect:
ourocode ──► ooo / ouroboros-plugins ──► ouroboros core (Seed · Ledger · MCP · Runtime)
shell user-level apps kernelThe kernel (
ouroboros) owns the contract: every action becomes a Seed-bound, ledger-recorded, replayable event — regardless of which LLM executes it.Plugins (
ouroboros-plugins) declare scoped capabilities against that contract, so domain workflows (review a PR, triage a Linear ticket, run a release) stay auditable and policy-bound instead of being one-off prompts.Ourocode is the terminal shell: it surfaces MCP state, interview questions, and wonderTool decisions as first-class TUI elements, so you can drive the OS without leaving the keyboard or switching between CLIs.
Use ouroboros alone with any supported CLI, layer plugins on for domain
workflows, or install ourocode when you want a unified terminal cockpit.
Disclaimer. The Ouroboros project and community are not affiliated with any cryptocurrency, token, memecoin, or trading community — including, but not limited to, any "ouroboros" tickers on pump.fun or other launchpads. This is an open-source developer tool. We do not issue, endorse, or hold any coins. Any token claiming association with this project is unauthorized.
Related MCP server: Shared Workspace MCP
Why Ouroboros?
Most AI coding fails at the input, not the output. The bottleneck is not AI capability -- it is human clarity.
Problem | What Happens | Ouroboros Fix |
Vague prompts | AI guesses, you rework | Socratic interview exposes hidden assumptions |
No spec | Architecture drifts mid-build | Immutable seed spec locks intent before code |
Manual QA | "Looks good" is not verification | 3-stage automated evaluation gate |
Quick Start
Install — one command, everything auto-detected:
curl -fsSL https://raw.githubusercontent.com/Q00/ouroboros/main/scripts/install.sh | bashFirst use — open your AI coding agent and type:
> oooIf a one-time setup is needed, Ouroboros asks before it makes changes. After
setup, Codex follows its currently selected model and Claude Code starts with
its recommended model settings. Choose Directly configure models only when
you want to pin a stage to a specific model; it opens the local settings screen
in your browser. You can return to those settings any time with ooo config.
Build — then go:
> ooo interview "I want to build a task management CLI"Or from a plain terminal, without an agent host:
$ ouroboros init start --orchestrator "I want to build a task management CLI tool"Works with Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Hermes, Gemini, Kiro CLI, Pi CLI, Zcode, Goose, GJC, Antigravity CLI, and Grok Build CLI. The installer detects available runtimes and registers the MCP server where the host supports it. For explicit selection, run
ouroboros setup --runtime <opencode|kiro|copilot|gemini|pi|zcode|goose|gjc|antigravity|grok>after installation. The Copilot CLI runtime live-discovers its model catalog via the GitHub Copilot models API and lets you pick a default during setup.
Needs codex on your PATH and uvx on the host (the plugin's MCP descriptor
launches the server with it). Install uv with pipx install uv,
pip install --user uv, or brew install uv.
codex plugin marketplace add Q00/ouroboros
codex plugin add ouroboros@ouroborosStart a new Codex session, then enter ooo. On first use, Ouroboros offers to
prepare the runtime before it changes anything. Once ready, it follows Codex's
current default model; choose Directly configure models only when you want
to pin a specific model for a pipeline stage.
pipx install 'ouroboros-ai[mcp]' # or: uv tool install 'ouroboros-ai[mcp]'
ouroboros setup --runtime kiro # detects Kiro CLI, registers MCP server, and
# writes OUROBOROS_RUNTIME=kiro into
# ~/.kiro/settings/mcp.json (the trusted,
# setup-managed location -- a project .env
# is untrusted input and this key is ignored there)Then use ooo commands inside a Kiro CLI session.
gh auth login # one-time GitHub auth (used for live model discovery)
pipx install 'ouroboros-ai[mcp]' # or: uv tool install 'ouroboros-ai[mcp]'
ouroboros setup --runtime copilot # discovers models live, picks a default,
# registers MCP server in ~/.copilot/mcp-config.jsonRestart your Copilot CLI session, then use ooo commands inside it. Model-ID mapping is narrower than it looks: the static map covers claude-opus-4-6 and claude-sonnet-4-5, any ID already containing a . passes through unchanged, and the hyphen-to-dot fallback rewrites every hyphen, so the current default claude-opus-4-8 becomes claude.opus.4.8 and misses. Leave role models unset so setup writes a discovered ID, or set a Copilot-valid dotted ID explicitly. See #1995 and the Copilot runtime guide.
See the GitHub Copilot CLI runtime guide for full details.
Claude Code plugin only (no Python package or global Python to install; the
host needs uv, which provides both uvx for the MCP server and the skills'
Python >= 3.12 fallback):
claude plugin marketplace add Q00/ouroboros && claude plugin install ouroboros@ouroborosThen run ooo setup inside a Claude Code session.
pip / uv / pipx:
pip install ouroboros-ai # base
pip install 'ouroboros-ai[claude]' # + default Claude Agent SDK profile (MCP 1.x)
pip install 'ouroboros-ai[claude-cli]' # + dependency-free Claude CLI worker profile
pip install 'ouroboros-ai[claude-sdk]' # + explicit alias for the Claude SDK profile
pip install 'ouroboros-ai[litellm]' # + LiteLLM multi-provider; Python 3.12-3.13
pip install 'ouroboros-ai[mcp]' # + MCP server/client support
pip install 'ouroboros-ai[tui]' # + Textual terminal UI
pip install 'ouroboros-ai[all]' # MCP 1.x app bundle; excludes the MCP 2 server
ouroboros setup # configure runtimeCore and non-LiteLLM installs support Python 3.12-3.14. LiteLLM-bearing installs ([litellm], [all], and source --extra all) support Python 3.12-3.13; use Python 3.13 for current examples. See Platform Support.
[claude] preserves the in-process Agent SDK and its MCP 1.x dependency graph;
[claude-sdk] is its explicit alias. The MCP 2 server runs from a separate
[mcp] environment and selects the [claude-cli] subprocess worker when
Claude is the host. Never install [mcp,claude], [mcp,claude-sdk], or
[all,mcp] in one interpreter. See the package compatibility and migration matrix.
pip install 'ouroboros-ai[mcp]' is valid for embedding the MCP client/server library in an already isolated Python environment, but host registration requires uvx --isolated --python '>=3.12' or pipx. Use pipx install 'ouroboros-ai[mcp]' or uv tool install 'ouroboros-ai[mcp]' before ouroboros setup --runtime <kiro|copilot|hermes>; setup exits without changing runtime configuration when neither isolated launcher is available.
Legacy compatibility: ouroboros-ai[dashboard] is still accepted as a compatibility alias/no-op; it does not install dashboard runtime payload. ouroboros-ai[all] includes that no-op alias only for compatibility.
See runtime guides: Claude Code · Codex CLI · Hermes · OpenCode · Kiro CLI · Gemini CLI · GitHub Copilot CLI · Zcode · Pi JSON mode · Goose · GJC · Antigravity CLI · Grok Build CLI
ouroboros uninstallRemoves all configuration, MCP registration, and data. See UNINSTALL.md for details.
Python >= 3.12 required. LiteLLM-bearing profiles support Python 3.12-3.13. See Platform Support and pyproject.toml.
Installing as an MCP server: use 0.51.1 or later. Earlier versions can fail at startup with
Failed to reconnect to plugin:ouroboros:ouroboros: -32000when an existing environment shadows the[mcp]profile (#2012). This matters if you install through a downstream package rather than PyPI, since those can lag.
What You Get
After one loop of the Ouroboros cycle, a vague idea becomes a verified codebase:
Step | Before | After |
Interview | "Build me a task CLI" | 12 hidden assumptions exposed, ambiguity scored to 0.19 |
Seed | No spec | Immutable specification with acceptance criteria, ontology, constraints |
Evaluate | Manual review | 3-stage gate: Mechanical (free) -> Semantic -> Multi-Model Consensus |
interview -> Socratic questioning exposed 12 hidden assumptions
seed -> Crystallized answers into an immutable spec (Ambiguity: 0.15)
run -> Executed via Double Diamond decomposition
evaluate -> 3-stage verification: Mechanical -> Semantic -> ConsensusUse
ooo <cmd>inside your AI coding agent session, orouroboros init start,ouroboros run seed.yaml, etc. from the terminal.
The serpent completed one loop. Each loop, it knows more than the last.
How It Compares
AI coding tools are powerful -- but they solve the wrong problem when the input is unclear.
Vanilla AI Coding | Ouroboros | |
Vague prompt | AI guesses intent, builds on assumptions | Socratic interview forces clarity before code |
Spec validation | No spec -- architecture drifts mid-build | Immutable seed spec locks intent; Ambiguity gate (<= 0.2) blocks premature code |
Evaluation | "Looks good" / manual QA | 3-stage automated gate: Mechanical -> Semantic -> Multi-Model Consensus |
Rework rate | High -- wrong assumptions surface late | Low -- assumptions surface in the interview, not in the PR review |
The Loop
The ouroboros -- a serpent devouring its own tail -- is not decoration. It IS the architecture:
Interview -> Seed -> Execute -> Evaluate
^ |
+---- Evolutionary Loop ----+Each cycle does not repeat -- it evolves. The output of evaluation feeds back as input for the next generation, until the system truly knows what it is building.
Phase | What Happens |
Interview | Socratic questioning exposes hidden assumptions |
Seed | Answers crystallize into an immutable specification |
Execute | Double Diamond: Discover -> Define -> Design -> Deliver |
Evaluate | 3-stage gate: Mechanical ($0) -> Semantic -> Multi-Model Consensus |
Evolve | Wonder ("What do we still not know?") -> Reflect -> next generation |
"This is where the Ouroboros eats its tail: the output of evaluation becomes the input for the next generation's seed specification." --
reflect.py
Convergence is reached when ontology similarity >= 0.95 -- when the system has questioned itself into clarity.
Ralph: The Loop That Never Stops
ooo ralph runs the evolutionary loop persistently -- across session boundaries -- until convergence is reached. Each step is stateless: the EventStore reconstructs the full lineage, so even if your machine restarts, the serpent picks up where it left off.
Ralph Cycle 1: evolve_step(lineage, seed) -> Gen 1 -> action=CONTINUE
Ralph Cycle 2: evolve_step(lineage) -> Gen 2 -> action=CONTINUE
Ralph Cycle 3: evolve_step(lineage) -> Gen 3 -> action=CONVERGED
+-- Ralph stops.
The ontology has stabilized.Commands
Inside AI coding agent sessions, use ooo <cmd> skills. From the terminal, use the ouroboros CLI.
Skill ( | CLI equivalent | What It Does |
|
| Register runtime and configure project (one-time) |
|
| Socratic questioning -- expose hidden assumptions |
|
| Goal → A-grade Seed → execution handoff with bounded loops |
| (generated by interview) | Crystallize into immutable spec |
|
| Execute via Double Diamond decomposition |
| (via MCP) | 3-stage verification gate |
| (via MCP) | Evolutionary loop until ontology converges |
| (via MCP) | 5 lateral thinking personas when you are stuck |
|
| Session tracking + (MCP-only) drift detection |
|
| List in-flight sessions and re-attach commands |
|
| Cancel stuck or orphaned executions |
| (via MCP) | Persistent loop until verified |
| (interactive) | Interactive hands-on learning |
|
| Full reference |
| (via MCP) | PM-focused interview + PRD generation |
| (via skill) | General-purpose QA verdict for any artifact |
|
| Check for updates + upgrade to latest |
| (via skill) | Scan and manage brownfield repo/worktree defaults |
| (skill/runtime surface; uses | Publish a Seed as GitHub Epic/Task issues for team workflows |
Not all skills have direct CLI equivalents. Some (
evaluate,evolve,unstuck,ralph,publish) are available through agent skills, runtime rules, or MCP tools rather than a directouroboros <subcommand>shell command./resumeis reserved for Claude Code's built-in session picker; useooo resume-sessionfor Ouroboros in-flight sessions. Claude Code also reserves/run,/status,/help, and/config. The safe direct skill forms are/ouroboros:ouroboros-run,/ouroboros:ouroboros-status,/ouroboros:ouroboros-help, and/ouroboros:ouroboros-config; the familiarooo run,ooo status,ooo help, andooo configphrases remain supported.
See the CLI reference for full details.
The Nine Minds
Nine agents, each a different mode of thinking. Loaded on-demand, never preloaded:
Agent | Role | Core Question |
Socratic Interviewer | Questions-only. Never builds. | "What are you assuming?" |
Ontologist | Finds essence, not symptoms | "What IS this, really?" |
Seed Architect | Crystallizes specs from dialogue | "Is this complete and unambiguous?" |
Evaluator | 3-stage verification | "Did we build the right thing?" |
Contrarian | Challenges every assumption | "What if the opposite were true?" |
Hacker | Finds unconventional paths | "What constraints are actually real?" |
Simplifier | Removes complexity | "What's the simplest thing that could work?" |
Researcher | Stops coding, starts investigating | "What evidence do we actually have?" |
Architect | Identifies structural causes | "If we started over, would we build it this way?" |
Under the Hood
src/ouroboros/
+-- bigbang/ Interview, ambiguity scoring, brownfield explorer
+-- routing/ PAL Router -- 3-tier cost optimization (1x / 10x / 30x)
+-- execution/ Double Diamond, hierarchical AC decomposition
+-- evaluation/ Mechanical -> Semantic -> Multi-Model Consensus
+-- evolution/ Wonder / Reflect cycle, convergence detection
+-- resilience/ 4-pattern stagnation detection, 5 lateral personas
+-- observability/ 3-component drift measurement, auto-retrospective
+-- persistence/ Event sourcing (SQLAlchemy + aiosqlite), checkpoints
+-- orchestrator/ Runtime abstraction layer (Claude Code, Codex CLI, OpenCode, Hermes, Gemini, Kiro, Copilot, Pi)
+-- core/ Types, errors, seed, ontology, security
+-- providers/ LiteLLM adapter (100+ models)
+-- mcp/ MCP client/server integration
+-- plugin/ Plugin system (skill/agent auto-discovery)
+-- tui/ Terminal UI dashboard
+-- cli/ Typer-based CLIKey internals:
PAL Router -- Frugal (1x) -> Standard (10x) -> Frontier (30x) with auto-escalation on failure, auto-downgrade on success
Drift -- Goal (50%) + Constraint (30%) + Ontology (20%) weighted measurement, threshold <= 0.3
Brownfield -- Auto-detects config files across multiple language ecosystems
Evolution -- Up to 30 generations, convergence at ontology similarity >= 0.95
Stagnation -- Detects spinning, oscillation, no-drift, and diminishing returns patterns
Agent OS runtime -- Replayable execution contract across capability discovery, policy, directives, event journal, and agent processes
Runtime backends -- Pluggable abstraction layer (
orchestrator.runtime_backendconfig) with first-class support for Claude Code, Codex CLI, OpenCode, Hermes, Gemini, Goose, Kiro, Copilot, and Pi; same workflow spec, different execution engines
See Architecture for the full design document.
From Wonder to Ontology
Wonder -> "How should I live?" -> "What IS 'live'?" -> Ontology -- Socrates
Every great question leads to a deeper question -- and that deeper question is always ontological: not "how do I do this?" but "what IS this, really?"
Wonder Ontology
"What do I want?" -> "What IS the thing I want?"
"Build a task CLI" -> "What IS a task? What IS priority?"
"Fix the auth bug" -> "Is this the root cause, or a symptom?"This is not abstraction for its own sake. When you answer "What IS a task?" -- deletable or archivable? solo or team? -- you eliminate an entire class of rework. The ontological question is the most practical question.
Ouroboros embeds this into its architecture through the Double Diamond:
* Wonder * Design
/ (diverge) / (diverge)
/ explore / create
/ /
* ------------ * ------------ *
\ \
\ define \ deliver
\ (converge) \ (converge)
* Ontology * EvaluationThe first diamond is Socratic: diverge into questions, converge into ontological clarity. The second diamond is pragmatic: diverge into design options, converge into verified delivery. Each diamond requires the one before it -- you cannot design what you have not understood.
The Interview does not end when you feel ready -- it ends when the math says you are ready. Ouroboros quantifies ambiguity as the inverse of weighted clarity:
Ambiguity = 1 - Sum(clarity_i * weight_i)Each dimension is scored 0.0-1.0 by the LLM (temperature 0.1 for reproducibility), then weighted:
Dimension | Greenfield | Brownfield |
Goal Clarity -- Is the goal specific? | 40% | 35% |
Constraint Clarity -- Are limitations defined? | 30% | 25% |
Success Criteria -- Are outcomes measurable? | 30% | 25% |
Context Clarity -- Is the existing codebase understood? | -- | 15% |
Threshold: Ambiguity <= 0.2 -- only then can a Seed be generated.
Example (Greenfield):
Goal: 0.9 * 0.4 = 0.36
Constraint: 0.8 * 0.3 = 0.24
Success: 0.7 * 0.3 = 0.21
------
Clarity = 0.81
Ambiguity = 1 - 0.81 = 0.19 <= 0.2 -> Ready for SeedWhy 0.2? Because at 80% weighted clarity, the remaining unknowns are small enough that code-level decisions can resolve them. Above that threshold, you are still guessing at architecture.
The evolutionary loop does not run forever. It stops when consecutive generations produce ontologically identical schemas. Similarity is measured as a weighted comparison of schema fields:
Similarity = 0.5 * name_overlap + 0.3 * type_match + 0.2 * exact_matchComponent | Weight | What It Measures |
Name overlap | 50% | Do the same field names exist in both generations? |
Type match | 30% | Do shared fields have the same types? |
Exact match | 20% | Are name, type, AND description all identical? |
Threshold: Similarity >= 0.95 -- the loop converges and stops evolving.
But raw similarity is not the only signal. The system also detects pathological patterns:
Signal | Condition | What It Means |
Stagnation | Similarity >= 0.95 for 3 consecutive generations | Ontology has stabilized |
Oscillation | Gen N ~ Gen N-2 (period-2 cycle) | Stuck bouncing between two designs |
Repetitive feedback | >= 70% question overlap across 3 generations | Wonder is asking the same things |
Hard cap | 30 generations reached | Safety valve |
Gen 1: {Task, Priority, Status}
Gen 2: {Task, Priority, Status, DueDate} -> similarity 0.78 -> CONTINUE
Gen 3: {Task, Priority, Status, DueDate} -> similarity 1.00 -> CONVERGEDTwo mathematical gates, one philosophy: do not build until you are clear (Ambiguity <= 0.2), do not stop evolving until you are stable (Similarity >= 0.95).
Contributing
git clone https://github.com/Q00/ouroboros
cd ouroboros
uv sync --python 3.13 --all-groups
uv run --python 3.13 --no-sync pytestIssues · Discussions · Contributing Guide
Sponsors
Ouroboros is MIT-licensed and built in the open. If it saves you rework — or you want the loop to keep evolving — consider sponsoring. Sponsorship directly funds maintenance, new runtime integrations, and sponsor-only deep-dive content.
Every sponsor keeps the serpent evolving. Thank you.
Activity
These numbers are generated from GitHub data and refreshed automatically; caching may delay updates.
Maintenance
Related MCP Servers
- AlicenseAqualityAmaintenanceProvides agent coordination for Claude Code through a shared blackboard, decision tracking with rationale, and local semantic search over git-trackable JSONL files. It enables users to assemble tailored context packages and manage a lightweight knowledge graph for complex development tasks.132617MIT
- Alicense-qualityBmaintenanceLocal-first memory, pipelines, learning, feedback, and safe code tools for AI coding agents.MIT
- Alicense-qualityAmaintenanceLocal-first AI agent for approval-gated automation and verifiable LLM workflows.1MIT
- Alicense-qualityAmaintenanceRun dynamic, multi-agent workflow scripts — agent(), parallel(), pipeline() — over real coding agents (Claude Code and OpenAI Codex), with deterministic journaling, resume, token budgets, and git-worktree isolation.2Apache 2.0
Related MCP Connectors
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
User-owned memory for AI agents, Copilot, Claude, IDEs, CLIs, and chat apps over remote MCP.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Q00/ouroboros'
If you have feedback or need assistance with the MCP directory API, please join our Discord server