Abstract
Automatic repair is more dangerous than automatic implementation because it is triggered by failure pressure. When a production system is degraded, an agent has a strong incentive to make the fastest change that clears the local error. Without a harness, that local repair can remove the very constraint that made the system safe. The result is self-healing that slowly erodes governance.
An autonomous repair harness solves this by turning every failure into a structured repair episode. The harness captures the failure, classifies the drift, selects a repair route, drafts a bounded change, replays the affected episodes, estimates blast radius, attaches rollback, and routes the proposal through approval. Repair is allowed, but constitutional self-editing is not.
1. Failure is data, not noise
In traditional operations, failures are often treated as interruptions. In agentic systems, failures are the most valuable training data because they reveal the boundary between expected behavior and actual runtime behavior. A failed tool call, missing evidence bundle, unsafe escalation, or low-confidence answer is not merely an incident. It is a new coordinate in the system phase space.
The repair harness therefore records failures as first-class episodes. Each episode includes input context, memory snapshot, tool trace, gate trace, output, score vector, user impact, and authority classification. A repair cannot start until the failure is captured.
2. Drift taxonomy
Repair quality depends on classification quality. We use a drift taxonomy with six top-level classes: input drift, tool drift, memory drift, policy drift, score drift, and authority drift. Input drift means the world presented a new shape of request. Tool drift means an external dependency changed. Memory drift means the agent used stale or wrong context. Policy drift means the governing rule no longer matches reality. Score drift means the harness metric no longer captures desired behavior. Authority drift means the system acted with too much or too little autonomy.
Authority drift is the most sensitive class. It should rarely be repaired automatically, because the repair may need to change the rules that decide who gets to repair. That is a constitutional boundary.
3. Four repair routes
The harness chooses among four repair routes. Rerun is used when the failure is transient and no artifact should change. Config patch is used when timeout, threshold, routing, or feature flags can fix the issue without code changes. Code patch is used when tool logic, workflow code, or UI behavior needs modification. Human escalation is used when the failure touches authority, legal risk, irreversible action, data boundary, or policy interpretation.
type RepairRoute =
| { kind: "rerun"; reason: string }
| { kind: "config_patch"; keys: string[]; rollback: string }
| { kind: "code_patch"; files: string[]; tests: string[]; rollback: string }
| { kind: "human_escalation"; gate: string; rationale: string }The route is not selected by developer preference. It is selected by evidence. If the episode shows external API timeout with no behavioral drift, rerun or config patch is appropriate. If the episode shows a wrong decision caused by missing gate logic, code patch or human escalation is required. If the episode shows the agent bypassed approval, automatic repair must stop and escalate.
4. Repair proposal structure
A repair proposal must be reviewable. It contains the failing episode, diagnosis, proposed diff, expected score change, tests to run, rollback envelope, blast-radius estimate, and approval route. The proposal should be understandable without trusting the repairing agent.
This matters because autonomous repair is vulnerable to self-justification. An agent can explain why its patch is useful while hiding the fact that it weakened a constraint. The harness counters this by requiring replay evidence and explicit boundary classification.
5. Rollback-first design
Every repair must be easier to undo than to apply. This is not a convenience; it is a safety invariant. A patch without rollback is not a repair. It is a mutation. The harness should reject repair proposals that cannot describe their reversal path.
Rollback-first design includes config snapshots, previous artifact hashes, migration reversal plans, feature flag isolation, canary rollout, and episode replay before and after rollback. For high-risk surfaces, the repair should deploy behind a gate and expire unless promoted by review.
6. Automatic repair and internal development
Automatic repair connects directly to internal auto-implementation. The implementation loop builds intended features. The repair loop improves features after runtime evidence reveals defects. Both use the same harness objects: intent, coordinate, scenario, score, gate, diff, approval route, and rollback.
The difference is emotional pressure. Implementation happens under product pressure. Repair happens under failure pressure. The harness must be stricter during repair because the system is tempted to trade safety for recovery speed.
7. The non-repairable constitution
The repair agent must not be able to change the rules that define its own repair authority. It may propose such changes, but it cannot apply them. The constitution includes approval policy, gate definitions, tenant boundaries, schema migration policy, prompt-core policy, production deployment policy, and audit retention rules.
This boundary is what makes autonomous repair compatible with governance. Without it, repair becomes recursive self-permission.
8. Research agenda
The research agenda has three fronts. First, repair causality: distinguishing the root cause from the visible symptom. Second, repair minimality: finding the smallest patch that fixes the episode without degrading adjacent scenarios. Third, repair confidence: deciding when evidence is sufficient for automatic patching and when uncertainty must escalate.
A useful benchmark is repair regret. A repair has regret when it fixes the original episode but creates more severe downstream failures. The harness should track regret across time and penalize repair strategies that optimize locally while increasing systemic risk.
Conclusion
Autonomous repair is not a feature toggle. It is a governance system. The dynamic harness makes repair safe by converting failures into episodes, episodes into proposals, proposals into replay evidence, and replay evidence into approval-routed patches. This allows MARIA OS to move toward self-healing without allowing agents to rewrite the boundaries that keep self-healing safe.