OuroborosAI
Stories creating code creating stories
Code Agents Collapse as the System Grows. That's because code is logic, but software is a story - intentions, processes, goals.
Project Ouroboros encodes narrative into code, to create code that LLMs deeply understand.
§ PROPOSAL
// Story-Driven-Development
// SDD paradigm
// Narrative → Code → Narrative
Fragility Of Agents
Agent-based development has gone mainstream. It promises cheap software development. But software companies keep running into the same walls:
- The project grows, the agent collapses. The next update will expand its context window, but the project will grow faster, and the agent will get lost again.
- Agents fail to identify bugs that stem from the intersection of processes and arcs.
— note —"Let's try a different approach" is the agent's polite way of saying it's lost.
Building software with agents that don't collapse under large, multi-context projects is one of the industry's central challenges today.
§ I - PROBLEM STATEMENT
// Agent collapse at scale
// Context overflow pattern
// Complexity ceiling
//
// Observed in production
// across all major LLMs
But Why?
A large project is built from code - simple logical steps. But out of those small building blocks, a story emerges: intention, purpose, processes. What separates a junior developer from a senior one is understanding that broader context.
— note —Agents are still juniors.
They don't know the big story. As a substitute, they fill their context window with endless lines of code.
Solutions like code graphs or code embeddings only partially succeed at this. They try to capture the logic of the code; they represent structure - but not goals and processes. Not the story.
What if an agent could navigate through the story, not just through the code? Ask: "What arc is affecting the current bug?"
With a map like that, the agent gets promoted from junior to senior.
§ II - ROOT CAUSE
// Narrative layer missing
// Logic ≠ Story
// Junior vs. Senior gap
//
// Code is structure.
// Story is intent.
The Key
Ouroboros consists of two parts:
- IThe hierarchical map - tells the story of each part of the codebase in short sentences
- IIThe arcs - describe the processes and dynamics running through the code
Together, the map and arcs create a summary of the codebase. With it, agents can search through the intentions of the software. This search engine enables a new mode of agent programming: SDD (Story-Driven-Development)
— note —This search engine enables a new mode of agent programming: SDD (Story-Driven-Development)
The Story-Spec map is an alternative to reading all the code. It reduces by an order of magnitude the context window an agent needs to understand a large codebase.
§ III - ARCHITECTURE
// Component I: Map
// Component II: Arcs
//
// Map + Arcs = Story-Spec
// Hierarchical tree
// + process graph
How It Works
- IOuroboros agents walk through the code and generate a story map: what each service / library / file / class / function means - a sentence or two for each. The map is hierarchical: an agent can locate a relevant "story" and then "open" only the relevant branch of the tree.
- IIThe second layer - no less important - is arcs. For example, the arc a product order travels from the moment the user completes a purchase to the confirmation email landing in their inbox: which classes, methods, hooks, or events are involved in that process.
- IIIWrapped around this map is a search engine. For example, if a subscription process fails, the agent can ask: "Which branches of the story tree relate to subscription?" "Which arcs are involved in the process?" - and quickly isolate the relevant parts of the code.
§ V - MECHANISM
// I. Walk → Story map
// II. Arc extraction
// III. Search engine
//
// O(log n) context
// instead of O(n)
POC
- Building an agent pipeline that generates a map for an existing, real-world repo
- A benchmark showing, for agents like Claude Code or Codex:
- IHow much do debugging ability, spec gap detection, and correct code generation improve on complex tasks that require cross-system understanding? In how many cases where a regular agent gets stuck, does an Ouroboros agent find the problem?
- IIDoes token usage drop significantly? By what percentage?
§ VI - VALIDATION
// Real-world repo target
// Benchmark design
//
// Hypothesis A: accuracy↑
// Hypothesis B: tokens↓
Why We Need the Grant
Will this work? LLMs don't always behave the way intuition suggests. To test the effectiveness of the semantic map, there's a size barrier: it has to be tested on a real, large codebase.
Mapping a real codebase of ~50,000 lines and 400 files, extracting arcs, and running a comparative benchmark costs around $50 under ideal conditions. In practice, iterating on prompts and testing across multiple codebases multiplies consumption by 8–10x.
$500 in cloud credits would allow running a reliable POC, with enough safety margin for pivots.
Based on the proof of concept, Ouroboros will build a tool that promotes code agents from junior to senior.
§ VII - RESOURCES
// ~50K lines
// ~400 files
// $50 base cost
// × 8-10 iterations
//
// Request: $500 credits
The Developer
Yitzhak Karov, a developer for roughly 20 years, specializing in organizational knowledge systems. Walking the edge between code, content, and strategy, the elusive problem of organizational DNA taught me that code alone is not the center of gravity - the story behind it is. That insight is at the heart of the Ouroboros project.