The 0.2 ambiguity gate can stop code before it starts
Ouroboros begins with questions, not file edits. Its interview scores goal clarity, constraints, and success criteria, then blocks Seed creation while weighted ambiguity remains above 0.2. You can force the gate, but the default is the product's main opinion: unclear intent should be made explicit before a coding agent commits to architecture. The resulting Seed freezes acceptance criteria and becomes the contract used during execution and evaluation.
That distinction matters because Ouroboros is not the separate project that rewrites its own architecture. The README explicitly disclaims any relationship with that similarly named agent. This Ouroboros evolves a task specification and its recorded lineage. It can question a vague request, produce a Seed, execute through another coding runtime, evaluate the work, and feed unresolved questions into another generation. The hard cap is 30 generations, with convergence set at 0.95 ontology similarity.
Twenty-one specialist roles wrap existing coding runtimes
The README describes 21 specialist agents, with 9 highlighted roles covering interviews, specifications, evaluation, research, architecture, and lateral problem solving. Those roles do not replace the model or coding host. Ouroboros sits between your intent and runtimes such as Claude Code, Codex CLI, OpenCode, Gemini, Kiro, Copilot, and Hermes. Its MCP server exposes workflow commands, while the event store preserves execution state so a persistent loop can resume after a session or machine restart.
The useful part is the contract around the agent. Actions are tied to a Seed, written to a ledger, and evaluated in mechanical, semantic, and consensus stages. The command surface covers interviews, runs, evaluation, evolution, status, cancellation, recovery, and brownfield work. This is a lot of process for a small patch. For multi-session jobs where you need to know what the agent attempted and which acceptance criterion passed, that process is the point.
What happened when we ran it
Our sandbox installed 92 packages in 28 seconds, using 442 MB on disk. The build completed in 6 seconds. We tested commit 79a423e in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Pip-audit found 0 known vulnerabilities in the installed environment. The repository itself contained 1,817 files, about 793,776 source lines, and 45.4 MB before dependencies.
The test step failed with exit code 4 after 1 second. Pytest could not load tests/conftest.py because importing pytest_asyncio raised ModuleNotFoundError. The log does not say whether that package was omitted from a development group, missed by our install command, or expected through another path, so we will not assign a cause. The practical result is simple: the build passed, but the suite never collected tests in our fresh environment.
Python 3.12 support splits into several MCP profiles
Core and non-LiteLLM installs support Python 3.12 through 3.14, while profiles containing LiteLLM support Python 3.12 and 3.13. The README recommends ouroboros-ai[mcp,tui] for standalone use with an MCP 2-compatible runtime. Claude SDK profiles belong in isolated MCP 1.x environments, and the [all] extra excludes MCP 2. Those boundaries reduce dependency clashes, but they make the word "all" less intuitive than it sounds.
Host registration also has a firm isolation rule. A plain pip install can embed the MCP library, but setup needs uvx or pipx before it will modify a supported runtime's configuration. On Windows, the installer can obtain Git and uv, yet native support remains experimental and Codex CLI needs WSL 2. Release v0.54.4, published September 13, 2026, included several Windows evaluation and command-handling fixes, which shows both attention and a platform edge still receiving repairs.
Version 0.54.4 arrived two days before the last push
GitHub showed 5,940 stars, 603 forks, and 103 combined open issues and pull requests on September 16, 2026. The last push was September 15, two days after v0.54.4. Current work includes MCP connection cleanup, a local stdio doctor probe, interview ambiguity handling, and dashboard links between runs and their source interviews. This is active maintenance, and the issue queue is small enough to inspect before choosing a runtime.
The moving parts deserve that inspection. Open issue 2393 records a PowerShell 5.1 diagnostic around the Microsoft Store Python alias. Issue 2386 says some failure paths reached telemetry without a useful cause, while issue 2388 questions how blocked downstream criteria are attributed. Neither issue makes the core idea unsound. Both show why an execution system that promises observability should be judged by the accuracy of its own evidence, not only by how many workflow commands it exposes.
Choose the workflow only if you want the gate
Ouroboros adds 92 installed packages and 442 MB before your chosen model or coding host does any work. That cost makes sense when your recurring failure is a poorly specified task that survives several agent sessions before anyone notices. Spec Kit is the simpler alternative for teams that mainly want written specifications. Superpowers adds structured agent habits with less runtime machinery, while Aider goes directly at conversational repository editing.
The missing pytest_asyncio import keeps us from recommending commit 79a423e as a frictionless contributor setup, despite the successful 6-second build. The product idea is sharper than the setup result: force the request into a testable contract, preserve the trail, and let a separate coding agent execute it. Adopt Ouroboros when you want that friction on purpose. If the 0.2 gate feels like an obstacle rather than protection, choose the lighter tool now.