The claim and the question it raises
A watchdog that only files issues still leaves the work to a person. Closing the loop means a system that detects a failure, reproduces it, writes a change, and proposes it — and every serious buyer hears that and asks the same thing.
Could a machine-written change reach my production system without a human in the path?
The only satisfying answer is no, and the only durable way to deliver that answer is to make it structural. "A human reviews everything" is a statement about process, and process erodes under deadline. What does not erode is a codebase in which the operation you are worried about does not exist.
Gate 01 — it never touches the running agent
The fixer clones the agent's repository at its deployed tag into a scratch directory. It does not read from, write to, or rebuild the running container.
This is worth stating precisely because the intuitive design is the dangerous one. A repair process that operates on the live deployment — even read-only, even carefully — creates a path between an automated system and production that has to be defended forever. A process that only ever operates on a clone at a known tag has no such path to defend.
The practical consequence for an operator: while a fix is being attempted, the fleet keeps running on the last known-good version. The repair happens beside the system, not inside it.
Gate 02 — everything executes in a throwaway sandbox with networking disabled
The reproduction, the full test suite, and a differential replay against recorded runs all execute in disposable containers with networking disabled.
Disabling the network is doing more work here than sandboxing alone. A container that can reach the internet can reach your systems, whatever its intent — and the code being executed was written by a model in response to a failure it diagnosed itself. The guarantee that nothing the fixer runs can reach your systems holds because nothing it runs can reach anything.
The differential replay is the substantive test: the candidate change is run against recorded historical runs to check that it fixes the reported failure without changing behaviour on inputs that were previously handled correctly. A fix that repairs one class and silently breaks another is the normal failure mode of automated repair.
Gate 03 — the output ceiling is a draft pull request
There is no merge path anywhere in the fix code.
That absence is the load-bearing part of this gate, and it is worth auditing for rather than trusting. The most an autonomous attempt can produce is a draft pull request on the development repository, carrying the failing reproduction, the diff, and the eval results.
A draft pull request is a proposal. It is a unit of work a reviewer can read, reject, or amend, and it arrives with the evidence needed to evaluate it. It is not a deployment, and it cannot become one without a person.
If you are evaluating a self-healing system, this is the specific thing to ask for: not whether a human approves changes, but whether the code that writes them contains any way to merge them.
Gate 04 — three separate people, three separate steps
A person labels the finding as approved for a fix attempt. Without that label the attempt never starts, so an autonomous repair cycle cannot even begin on a failure nobody has triaged.
A person reviews and merges the pull request.
A person cuts the release that actually deploys it.
No single approval carries a machine-written change into production. This gate is the one that matters most, because it is the only one that does not depend on the other three being bug-free. If gates one through three all failed simultaneously, the change would still be sitting in a repository waiting for a release nobody had cut.
The same boundary applies to learning
A system that improves from feedback raises a quieter version of the same question: if it is learning, what exactly is changing, and can you get it back?
Corrections flow into versioned prompts and closed vocabularies. They never flow into model weights. Every change is eval-gated and runs in shadow mode before promotion.
The reason to draw the line there is recoverability. A change to a versioned prompt is reviewable, attributable to a specific correction, and revertible with a git revert. A change to weights is none of those things — you cannot read it, cannot explain which correction caused it, and cannot cleanly undo it. For an enterprise system whose outputs have to be defensible a year later, that difference is the whole argument.
These notes describe how Keelo builds. They are written from production systems running in customer environments, and they identify no customer, no vendor, and no deployment. Where a note gives a number, that number is either arithmetic you can reproduce or a threshold Keelo enforces — never a measured customer outcome.