Interview-Gated Agent OS: Enforcing Policy Boundaries in Autonomous Coding Loops

Eliminating Prompt Drift via Socratic Interview Gates

Most failures in AI coding systems stem from ambiguous human inputs rather than inadequate model capability. When agents receive under-specified prompts, they make unchecked assumptions that lead to mid-build architecture drift and tedious manual rework. Ouroboros addresses this structural weakness by positioning itself as a local-first Agent OS that converts non-deterministic requests into replayable, policy-bound execution contracts.

Instead of sending raw user prompts directly to an execution runtime, Ouroboros initiates an interview phase. This Socratic dialog uncovers hidden requirements and calculates an explicit ambiguity score (for example, reducing task ambiguity down to a final score of 0.15 in terminal and chat host sessions). Once ambiguity is resolved, the system crystallizes intent into an immutable Seed specification. This specification acts as an unalterable contract: the agent cannot alter its core instructions during execution, preventing goal drift over autonomous generations as documented in the Ouroboros README.

The Three-Layer Architecture: Kernel, Plugins, and Shell

As detailed in the Ouroboros README, the system architecture is partitioned into three distinct operational layers across dedicated repositories:

OS Kernel (Q00/ouroboros): The Agent OS core that owns the specification contract. It manages Seeds, the execution Ledger, safety boundaries, Model Context Protocol (MCP) server integration, and multi-runtime orchestration. Every action becomes a Seed-bound, ledger-recorded, replayable event regardless of which LLM executes it.
Application Layer (Ouro-labs/ouroboros-plugins): Provides a user-level plugin contract that composes core primitives into installable domain programs (such as PR operations, Jira synchronization, incident handling, and release management) with scoped permissions and provenance.
Shell Layer (Ouro-labs/ourocode): A native terminal client providing a unified TUI cockpit. It surfaces decision pickers, MCP status panes, and command discovery across Claude, Codex, and Gemini CLIs within a single session.

By isolating the execution kernel from domain workflows and terminal interaction, Ouroboros ensures that policy enforcement remains uniform across host harnesses.

Preventing Metric Gaming through Staged Evaluation Isolation

A core architectural principle of Ouroboros is holding a firm line between execution and grading: the grading command and expected test results are strictly excluded from the success contract delivered to the agent (Ouroboros README). This separation prevents autonomous agents from gaming evaluation metrics or rewriting test suites to force synthetic passes.

Execution and validation follow a 3-stage automated evaluation gate:

Interview and Crystallization: Socratic questioning resolves ambiguities and locks task intent into an immutable Seed specification.
Execution Phase: The agent executes code modifications within the safety boundaries established by the locked Seed.
Evaluation and Budgeted Evolution: An independent evaluation suite runs verification tests without exposing grading internals to the agent's prompt context. If verification fails, failure details enter a budgeted evolution cycle, where the agent iterates across generations until the evaluation contract is satisfied or the compute budget is exhausted.

Multi-Runtime Integration and Model Discovery

According to the Ouroboros repository metadata, Ouroboros provides runtime compatibility across 13 distinct agent hosts: Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Hermes, Gemini CLI, Kiro CLI, Pi CLI, Zcode, Goose, GJC, Antigravity CLI, and Grok Build CLI.

The system adapts dynamically to host capabilities:

GitHub Copilot CLI: Discovers available models live via the GitHub Copilot models API.
Kiro CLI: Queries the authenticated CLI dynamically using kiro-cli chat --listmodels -f json so account and enterprise allow-list updates are discovered without relying on hardcoded model tables.
DeepSeek Harness (dsh): Supported natively either by invoking DeepSeek models via --llm-backend dsh (OUROBOROS_LLM_BACKEND=dsh) to drive DeepSeek Harness's ACP server under the hood, or by installing the dsh-ouroboros plugin directly in chat sessions to run ooo interview and ooo auto natively.

Deployment Workflows and Setup Commands

Installing Ouroboros involves a single auto-detecting installer script as shown in the Ouroboros README:

curl -fsSL https://raw.githubusercontent.com/Q00/ouroboros/main/scripts/install.sh | OUROBOROS_INSTALL_REF=readme bash

Inside an active AI agent host environment, initial runtime setup and workflow invocation require two standard commands:

ooo setup
ooo interview "I want to build a task management CLI"

When running directly from a plain terminal without an agent host, Ouroboros can be initialized via:

ouroboros init start --orchestrator "I want to build a task management CLI tool"

For explicit runtime registration after installation, developers can specify target runtimes directly:

ouroboros setup --runtime <opencode|kiro|copilot|gemini|pi|zcode|goose|gjc|antigravity|grok>

Distinguishing Architectural Boundaries and Operational Constraints

The Ouroboros README clarifies two important project constraints:

No Cryptocurrency Association: Ouroboros is strictly an open-source developer tool and is not affiliated with any cryptocurrency, token, memecoin, or trading community.
Disambiguation: Ouroboros is distinct from Anton Razzhigaev's self-modifying autonomous memory agent at github.com/razzant/ouroboros. While that project rewrites its own code architecture dynamically, Q00/ouroboros enforces stability by locking immutable specifications prior to execution.