Autonomous Repair Harness: Turning Runtime Failures into Safe, Reviewable System Improvements
Failure episodes, repair proposals, rollback envelopes, and approval boundaries for self-healing agentic systems
ARIA-RD-012026/5/3020分で読めます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.
A self-healing system may repair its organs. It may not rewrite its constitution without external authority.
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.
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know
関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription
関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems
関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates
関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine
関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか
関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks
関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline
関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations
関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?
関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance
関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation
関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS
関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ
関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems
関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計
関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons
関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS
関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions
関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
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.