Inspiration

AI coding agents are getting good enough to work on different parts of a codebase at the same time, but that creates a new class of failures.

One agent can read a file, start generating code from it, and publish its output after another agent has already changed that dependency. There may be no merge conflict and every file can look valid on its own, but the system is now inconsistent.

I built Ravel because I wanted the kind of causal debugging and observability we use for distributed systems, but for concurrent AI coding agents.

What it does

Ravel is a concurrency debugger for AI coding agents.

Ravel tracks the exact versions of files each agent observes and connects generated outputs back to those inputs. When an agent tries to publish code based on a dependency that changed while it was working, Ravel can detect the stale dependency and trace how that output affects downstream work.

Developers can inspect the dependency graph, view the exact race that occurred, replay it from recorded events, use Gemini to understand why the change matters semantically, and repair affected outputs by rerunning their producing tasks against fresh inputs.

Ravel also supports a Guard mode that can reject stale publications before they enter the shared codebase.

How I built it

Ravel's core runtime is written in Go. It mediates repository reads and writes, records immutable file versions and observations, validates dependencies at publication time, builds the provenance graph, and stores the execution history in SQLite with content-addressed file blobs.

The agent layer is written in Python. Gemini agents interact with the repository through Ravel's tools rather than accessing shared files directly, which lets Ravel know exactly which versions they received. Python also handles scheduling, semantic analysis, and repair orchestration.

The debugger is built with React and TypeScript, with a live timeline, dependency graph, version history, incident inspection, replay, and repair controls.

I integrated SpacetimeDB as a live projection layer for pushing committed debugger state to connected clients, and Fetch.ai / Agentverse through a conversational Ravel Inspector that can query runs, hazards, blast radii, and replays.

Challenges I ran into

The hardest part was defining what it actually means for an AI-generated output to be stale.

Checking whether a file changed is not enough. Ravel needs to know the exact version an agent saw when it produced a candidate, preserve that provenance even if the agent later rereads the file, and compare it against the repository state when the candidate is finally published.

Repair introduced another subtle problem. Sometimes rerunning a task produces identical bytes even though the new execution used clean dependencies. I had to separate content identity from execution provenance so Ravel could create a fresh version with clean lineage even when the resulting file contents were unchanged.

Accomplishments that I'm proud of

I'm proud that Ravel does more than visualize agent activity. It records enough causal information to explain how a concurrency failure actually happened.

A stale output can be connected to the exact version it consumed, the update that invalidated it, and every downstream artifact derived from it. The same recorded execution can then be replayed without rerunning the model.

I also built both Observe and Guard modes, along with a repair system that reruns affected producing tasks in dependency order while preserving the original incident in history.

What I learned

Building Ravel made me realize how quickly multi-agent coding starts to look like a distributed systems problem.

Once agents operate concurrently, the difficult problems are no longer only about model quality. They involve stale reads, ordering, provenance, retries, partial failure, state propagation, and determining which outputs can still be trusted.

I also learned that observability alone is not enough. Once the system understands causality, the same information can be used to prevent invalid writes and selectively repair affected work.

What's next for Ravel

The biggest next step is integrating Ravel at the publication boundary of existing coding-agent frameworks so agents can gain these guarantees without being written specifically for Ravel.

I also want to expand the repair system, add stronger correctness checks after regeneration, and evaluate Ravel on external multi-agent coding benchmarks.

Long term, I see Ravel becoming a concurrency and provenance layer for teams of autonomous coding agents: tracking what each agent knew, preventing stale work from silently landing, and making failures reproducible when they do occur.