Reconc

Inspiration

Since March last year, I have spent most of my days building software with coding agents. I became obsessed with how far autonomous development could go, but I kept running into the same problem: an agent would confidently say a task was finished when the repository told a different story.

Sometimes the “implementation” was only a skeleton. Sometimes a test was never written, documentation was not updated, a protected file was changed, or an important workflow step was quietly skipped. Prompt rules helped, but they did not create a hard boundary. During long sessions, agents could still drift, forget context, reinterpret instructions, or declare victory too early.

As my projects became larger, these failures became more expensive. Eventually I was running long autonomous loops inside a private, large-scale agentic enterprise platform with millions of lines across the wider system. At that scale, manually checking every claim and every changed file was no longer realistic. I needed something that could preserve context, enforce repository-specific workflows, detect incomplete work, and decide whether an agent was actually allowed to continue or stop.

That need became Reconc.

What it does

Reconc is an offline, deterministic repository control and evidence layer for coding agents.

It compiles the rules already living in a repository into executable gates. It then checks what an agent read, changed, tested, claimed, and completed.

Reconc can block:

premature “done” claims
protected writes and deletions
changes outside the approved scope
missing or stale test evidence
implementation stubs and placeholder code
documentation drift
skipped workflow and task-lifecycle steps
autonomous loops that stop making progress

A block is not just an error. Reconc returns one concrete next action that tells the agent how to recover. Completion passes only when the current repository state, policy, evidence, and typed task state agree.

There is no second language model judging the first model. The decision is offline, deterministic, inspectable, and reproducible.

Reconc also includes a durable loop-control system for long autonomous runs, a task lifecycle that carries context across sessions, transactional bootstrap and removal, 18 stack-aware assurance packs, and native integrations for nine coding-agent runtimes plus Git.

The same policy can follow a project across Codex, Claude Code, GitHub Copilot, Cursor, OpenCode, Devin CLI, Antigravity CLI, Kilo Code, and Grok Build.

How we built it

Reconc began as repository-specific infrastructure inside my private platform. Its workflows, gates, and policies were originally designed around the real failures I encountered while running coding agents on a very large production codebase.

I gradually extracted those ideas into a repository-agnostic tool that other developers could install and adapt. Instead of shipping my private policies, Reconc provides a compiler, configurable rules, reusable templates, stack-aware packs, and a CLI for bootstrapping and operating the system inside any repository.

The implementation is primarily written in Go and ships as a single binary. It includes deterministic policy compilation, native assurance gates, typed task lifecycle management, evidence freshness, transactional bootstrap and removal, runtime-specific hooks, bounded loop control, no-progress protection, release provenance, checksums, and SBOMs.

Reconc existed before OpenAI Build Week as a working prototype. During the event, Codex with GPT-5.6 helped transform it into the polished v0.8.6 developer-tool release across 97 commits and 478 changed files.

Codex contributed substantially to architecture, implementation, debugging, adversarial review, testing, release engineering, documentation, and launch preparation. I made the product, scope, privacy, and publication decisions. Claude was used transparently for additional review and selected implementation support.

Challenges we ran into

The hardest challenge was distinguishing strict control from brittle automation.

A useful control layer must fail closed when evidence is missing, but it must not invent requirements that the repository never declared. It must catch real stubs without treating every TODO in test fixtures as production debt. It must bind test evidence to the current changed state rather than accepting an old successful run. It must protect user-owned files while still offering a convenient bootstrap experience.

Every supported agent runtime also exposes a different hook system, event format, and enforcement boundary. Reconc had to translate one repository policy into several runtime-specific integrations without pretending that every runtime provides identical guarantees.

Another challenge was productizing infrastructure that originally lived inside one enormous private repository. The public version needed to be genuinely portable, understandable within minutes, safe to install, and useful without exposing private code or company-specific workflows.

Accomplishments that we're proud of

Reconc is now a real, installable developer tool rather than a collection of prompt conventions.

It ships as one offline binary with signed, checksummed release artifacts. A developer can bootstrap a repository, compile its policies, install selected integrations, inspect exact decisions, control autonomous loops, and run a complete block-to-proof demo without an API key, daemon, Docker installation, or network dependency at runtime.

The 18 assurance packs cover common language and ecosystem surfaces including Go, Rust, TypeScript, JavaScript package managers, Python, Java, C#, C++, PHP, Elixir, Zig, Shell, PowerShell, Next.js, and Svelte. They only recommend gates supported by evidence already present in the repository. Reconc never invents a test or build command.

Most importantly, the public tool is still based on real production pressure. It is dogfooded inside the private platform that originally created the need for it.

What we learned

Prompt instructions and deterministic enforcement solve different problems.

Agents are extremely capable, but long autonomous runs create predictable repository-visible failure modes. The solution is not to ask another model whether the first model behaved correctly. The stronger approach is to define observable boundaries around scope, evidence, workflow, and completion.

We also learned that evidence must be fresh and bound to the current repository state. “The tests passed earlier” is not proof that the code currently being submitted is correct.

Finally, good enforcement needs good recovery. A system that only says “no” becomes friction. Reconc became much more useful when every block started producing one exact next action.

What's next for Reconc

The immediate goal is to get Reconc into real repositories outside my own environment and learn which policies, assurance packs, and workflows developers need most.

Next, I want to expand the portable proof surface for pull requests and CI, improve onboarding further, add more stack-aware packs, deepen cross-platform support, and make policy authoring easier without weakening deterministic guarantees.

The larger vision is controlled autonomous software development: agents that can work for long periods across large codebases while repository-owned policy, durable context, current evidence, and explicit completion gates keep the work on track.

AI agents can say they are done. Reconc makes them prove it.