• 

• 

• 

• 

• 

Project Description

Inspiration

Coding agents crossed a line this past year: they became reliable enough to produce real work at a volume no human can fully read—or, honestly, wants to read.

That is obviously a good problem to have. Codex can build things in minutes that used to take days. But once agents start writing a meaningful percentage of a project, the bottleneck moves downstream. The hard part is no longer writing the code. It is keeping track of what already exists, what the project was supposed to do, what changed, and whether the latest “done” is actually done.

I kept running into the same failures across real projects: existing implementations recreated somewhere else, routes that were never connected, TODOs and mock data left behind, pieces of a specification skipped, and confident completion messages that still required me to review everything manually.

The bigger the project became, and the more of it AI generated, the harder this got. Every new session had to rediscover the repository. Every agent had a slightly different understanding of it. And most answers to “is this AI-written code actually good?” were still another model reading the first model’s work and offering an opinion.

I did not want another opinion. I wanted a shared reference for the developer and the agent, built from the repository itself, plus an independent check that did not accept a completion claim just because the agent sounded confident.

That became Strata19.

It only took more than 40 billion tokens across coding-agent workflows to finally push me into building it. No kidding.

What it does

Strata19 is a free, local project-intelligence and verification plugin for Codex.

It adds a project workspace directly beside the conversation. Codex can keep working normally, while both the developer and the agent have access to the same repository-derived reference: the code, dependencies, findings, documentation, draft specifications, execution state, and checkpoints.

The free plugin focuses on the repository you have today.

It builds a shared project reference

Strata19 indexes the repository locally and creates a connected view of what exists and how it relates. Instead of asking Codex to repeatedly search thousands of files and reconstruct the project from scratch, the agent can query that reference directly.

The developer sees the same reference in the Strata19 pane inside Codex. The conversation is where the agent works. The pane is where the project stays in view.

It turns code and documentation into readable project context

Strata19 can retrieve relevant documentation with the source attached—the file, section, and passage—rather than returning a summary with no way to verify where it came from.

It can also generate draft specification material from the existing code and repository documentation. Those drafts describe what the current system appears to do; they are not presented as confirmed human intent.

It surfaces concrete findings with evidence

The plugin detects unfinished and suspicious work such as placeholders, disconnected implementations, duplicate patterns, missing configuration, and other repository conditions covered by its local checks.

Findings include the file, line, and supporting evidence. Codex can explain a finding in normal language, but the underlying result does not depend on the model agreeing with it.

It checks “done” at the moment it matters

When Codex attempts to finish a task, Strata19 can run through Codex’s task-lifecycle hook and check the resulting repository state.

If new unfinished work remains, completion is blocked and Codex receives the exact evidence it needs to continue. After the repair, the check runs again. The task does not pass simply because the agent says it is complete.

The verifier is deterministic: the same repository state produces the same result every time.

It keeps human decisions attached to the work

A finding is not always automatically a bug. It may be new intent, or a deliberate decision.

Strata19 lets the developer classify that distinction and preserve it as part of the project record rather than losing it inside a chat transcript.

It uses GPT-5.6 where language helps—not where truth matters

GPT-5.6 helps with language-heavy work such as explaining findings and drafting readable specification text.

It does not decide whether the deterministic checks pass. The plugin includes a test proving that the verification result stays identical with the model enabled or disabled.

Deterministic where truth matters. AI where it helps.

How we built it

Codex was the primary planning and implementation environment for the plugin.

It helped break the product into the local repository index, MCP tools, Codex lifecycle hooks, deterministic detectors, the project workspace, checkpoints, specification context, and the completion gate.

The division of labor mirrored the product itself. One agent generated and changed the implementation. Another agent checked the claims against the actual running plugin and repository state rather than trusting the first agent’s summary.

That process caught real problems. One of the best examples was a bug where the plugin’s own logging was corrupting the protocol output being sent back to Codex. The code existed and looked reasonable, but the live behavior was wrong. It was found because the second agent tested the real path rather than accepting that the implementation “should” work.

The submitted plugin is a standalone local package built around:

• A Codex plugin and MCP server
• A local repository index and dependency reference
• Deterministic repository checks
• Codex task-lifecycle hooks
• A native project workspace inside Codex
• Checkpoints, findings, work items, and specification context
• GPT-5.6 assistance for explanation and drafting, isolated from the verdict

The same separation appears throughout the product: the model can help describe, organize, and repair; it does not get to redefine the evidence.

Challenges we ran into

The project was large enough to reproduce the problem we were trying to solve

The most obvious challenge was completion.

Strata19 came out of a much larger platform, and the codebase had accumulated the exact problems the plugin is meant to catch: unfinished paths, partially connected components, stale assumptions, and features that existed in code without being fully wired into the product.

It was frustrating, but also useful. The more pain the project caused under the deadline, the clearer the reason for the product became.

Telling “built” from “wired”

A recurring failure mode was code that existed but was not actually used.

A function could be present. A tool could be registered. A pane could compile. None of that proved that the complete path worked inside Codex.

A large amount of the work was verifying that features were connected to the real host and that data reached the place the user would actually see it.

Keeping the verifier honest under deadline pressure

The temptation during a hackathon is to weaken a check until the demo turns green.

We refused to do that.

When the plugin could not measure something reliably, we narrowed the claim, marked it as unmeasured, or removed it from the demo. A green result is only valuable when the check behind it still means something.

Separating the free plugin from the larger platform

The broader Strata19 platform has guided discovery, authoritative specifications, persistent project memory, spec-to-code synchronization, and multi-agent coordination.

The hackathon submission is the free local plugin. Keeping the submission focused on what judges can actually install and run—without hiding the larger direction—was one of the hardest product-positioning decisions.

Accomplishments that we’re proud of

• Strata19 runs as a real project workspace directly inside Codex, not as a separate dashboard the developer has to keep switching to.
• The developer and Codex can use the same repository-derived reference instead of maintaining separate understandings of the project.
• The completion gate checks the repository when the agent attempts to finish and can block a false “done” with file-and-line evidence.
• The core checks are deterministic and reproducible rather than another model reviewing a model.
• GPT-5.6 improves explanations and drafting without controlling the verdict.
• The plugin can be demonstrated on an unfamiliar production repository rather than a project created specifically to make the demo succeed.
• We ran Strata19 against its own source and kept a real unfinished finding in the demo. A tool that cannot find its own broken code has no business judging anyone else’s.
• The submitted version runs locally, requires no account, and is available as a free plugin.

What we learned

The biggest lesson is that this problem gets more important as coding agents improve.

A weak agent does not generate enough useful software for project coherence to become the primary bottleneck. A strong agent does.

As agents produce more code, faster, the developer needs a better way to understand the system without reading every generated line. The agent also needs a reference that survives beyond one prompt and does not have to be reconstructed in every session.

We also learned that the developer-facing reference is just as important as the agent tools.

The right-side Strata19 workspace turned out to be one of the strongest parts of the product. It gives the developer a place to see the same findings, evidence, specifications, checkpoints, and project state the agent is using. The chat is temporary and task-focused. The project reference remains.

Finally, deterministic verification and LLM generation are complementary, not rivals.

Codex is the implementation engine. GPT-5.6 is useful where language and judgment help. The graph, index, and checks provide the stable facts neither model should be allowed to rewrite.

A smarter model does not make that separation less useful. It makes it more useful because the model can now produce far more work that needs to remain understandable and verifiable.

What’s next for Strata19

The free plugin is the repository-intelligence foundation.

It reconstructs a useful project reference from the code and documentation that already exist. It helps the developer and Codex understand the repository, preserve findings and decisions, and check the result before a task is allowed to end.

The broader Strata19 platform expands what that reference knows.

Guided discovery and authoritative specifications

Instead of beginning with an existing repository, the platform guides the user through defining what should be built: the users, workflows, requirements, constraints, decisions, and acceptance criteria.

Those become the authoritative intent side of the project graph.

Continuous specification-to-code synchronization

The platform connects specifications, decisions, code, tests, changes, and implementation work.

When intent changes, the graph can identify what code and tests are affected. When the code changes, it can identify where the implementation no longer matches the intended system.

The free plugin understands the repository you have. The full platform is designed to understand the project you intended to build—and keep the two connected over time.

Multi-agent coordination

As teams run more agents across more workstreams, the graph becomes the shared control plane:

• What each agent is working on
• Which parts of the project overlap
• Which findings and decisions matter to the task
• What is waiting for approval
• What changed while another agent was working
• Whether completed work can safely compose with other changes

The long-term goal is not to slow agents down or constrain how they write code.

It is to let them move quickly without allowing the project’s meaning, structure, and history to disappear underneath the amount of software they can generate.

Built With

• codex
• kotlin
• pgvector
• postgresql
• typescript