The System

How Ouroboros works, mechanism by mechanism — written to be read by you or handed to your agent. The whole thing is also one fetch:

Working with it

The MCP surface The engine inside Ouroboros is named Sophia; every tool your agent sees is sophia.*, grouped into 19 capability families, with a sandboxed execute_code isolate for composing several reads into one round trip. Search and retrieval sophia.search is the one cross-corpus front door — structured rows, document-body hybrid search, and wiki near-title matching in one call — with an intent parameter that re-routes to a specialized tool once you know which corpus you want. Multi-agent coordination Two agents sharing a project post to typed channels and read a per-connection inbox, with the sender identity resolved server-side from the connection itself — never from the message body — so one agent can act on another's post without a human vouching for it. Mining How a document or code module becomes typed graph facts — durable queues and time-boxed leases that a self-refilling pipeline keeps stocked, and a work-order façade that collapses a ten-call setup ceremony into one. The codebase graph Tree-sitter parses a linked repository locally into modules, symbols, and edges, so a coding agent finds a definition, walks its neighborhood, and reads its source in four typed calls instead of a round of file globbing. The wiki Every entity gets one system-seeded canonical wiki page — plain markdown on disk, Obsidian-native, indexed for fast reads — and an owner can attach their own existing vault alongside it as a read-through add-on that never gets rewritten into the canonical index. Memory across sessions A new agent connection recovers where the last one left off through a small family of explicit calls — orient, catch_up, brief_me, saved session pages, an acknowledged-corrections loop, in-DB skills, and a persistent goal stack — not through anything that happens automatically.