Grace: infrastructure for AI software reliability

The problem I kept seeing

At Beyond The Brackets, more and more of the projects we took over had been written largely with AI tools. They worked, real users depended on them, and nobody could say with confidence what was inside. The original builder had moved on, and the same bugs kept coming back after every fix.

Reading that code by hand, project after project, doesn’t scale. I wanted a system that does the first pass of a senior engineer’s review: map the codebase, find what’s dangerous, and keep watching after the fix.

What Grace covers

• Cartography. A map of what the codebase actually contains and how its parts depend on each other.
• Safety net. Guards that catch regressions before they reach users.
• Stabilization. Finding and fixing what breaks or puts data at risk, starting with the most severe.
• Memory. The project’s decisions and context, kept so the next person or agent doesn’t start from zero.
• Maintenance. Ongoing checks so the app stays healthy as it keeps changing.

Every check is judged against three principles.

How it works

The core engine is written in Python. On top of it, an agent orchestrator runs specialized agent roles in the right order: when a feature has to be built or a problem fixed, each role does its part and hands off to the next. Developers can follow those runs, and fix an issue themselves, from the Grace interface.

Grace also ships as an MCP integration and a public Claude Code plugin, so it lives where developers already work, in Claude Code and Cursor. In that mode the intelligence runs on the customer’s own model, and Grace brings the structure: what to check, in what order, and against which rules.

The product is organized the way teams are: an account creates an organization, an organization holds several apps, and each app has its issues, reports, reviews, runs, and memory.

What the repository remembers

A codebase forgets. The reason a table was denormalized, the integration that cannot be retried safely, the fix that looked wrong but was not: all of it lives in someone’s head until that person leaves. Grace keeps a memory layer per repository that accumulates those decisions and that context over time, so the next person, or the next agent, does not start from zero and does not undo a choice without knowing why it was made.

That memory is what makes the later runs better than the first one. An audit with no history can only read the code in front of it. An audit that knows what this team already decided can tell a deliberate exception apart from a mistake.

Judging the agents’ own output

An agent that reports fifty issues is useless if fifteen of them are wrong. So Grace tracks the quality of its own output: which findings a developer confirms, which ones they reject, and which come back as false positives. Those counts set the acceptance bar, deciding what is worth surfacing and what stays quiet. It is the difference between a tool a team trusts and one they stop reading.

Where it came from

Grace started as an internal multi-agent pipeline we ran on AWS EC2, driven from a Telegram interface, with a tiered stack of models. We used it on our own project takeovers. When it proved useful there, I turned it into a product.