Abstract
The first generation of AI harnesses asks whether an output passed. The second generation asks whether an agent respected a policy gate. MARIA OS needs a third generation: MARIA Self-Healing Runtime, a self-evolving harness runtime that turns failure into safe, reviewable, memory-backed system improvement.
This shift matters because agentic systems do not fail only at final output. They fail while routing, retrieving, calling tools, spending tokens, escalating authority, writing artifacts, and interacting with external systems. A passive observer can detect these failures. A policy gate can stop them. But the operating system still needs a loop that can diagnose the failure, plan a bounded repair, draft the patch, replay the relevant evidence, and remember the prevention rule for next time.
0. The principle
The essential claim is not that the system can repair itself. The essential claim is that the system can repair itself safely. Safety is not added at the end of the repair loop. It is the structure of the loop: Failure Analyzer, Meta-Harness, Envelope, Memory Store, Human Approval Gate, and Loop Control.
This section belongs at the top because it is the fastest way to understand the system. The remaining sections are implementation details for that one idea. The runtime may diagnose, patch, replay, and learn, but it must never hide uncertainty, bypass review, weaken its own gates, or treat speed as more important than responsibility.
Externally, this capability should be named MARIA Self-Healing Runtime. The term is concrete enough for infrastructure buyers to understand, specific enough to belong to MARIA OS, and broad enough to include CI/CD repair, E2E repair, prompt/RAG repair, agent workflow repair, and preventive harness coverage.
1. From open-loop gates to closed-loop repair
A policy harness is an open-loop safety mechanism. It observes behavior and blocks execution when a rule is violated. This is necessary, but it is not sufficient for agent infrastructure. If every violation stops and waits for a human, the organization gains safety but loses compounding improvement. If every violation triggers an automatic patch, the organization gains speed but risks recursive self-permission.
MARIA Self-Healing Runtime is the middle path. It is a closed loop with explicit stability margins: observe, diagnose, plan, repair, replay, approve, deploy, monitor, and learn. The loop is allowed to improve the system, but it is not allowed to rewrite the authority contract that governs its own improvement.
type SelfEvolvingHarnessLoop = {
observe: "runtime_episode"
diagnose: "failure_analyzer"
plan: "patch_planner"
repair: "autonomous_fixer_agent"
replay: ["scoped_harness", "cross_cutting_harness"]
approve: "human_approval_gate"
learn: "memory_store"
forbidden: ["self_authority_expansion", "required_gate_weakening"]
}The control-theory analogy is direct. A static gate is comparable to a hard threshold. MARIA Self-Healing Runtime is closer to a controller: it reads the state vector, applies a constrained correction, reads the state again, and refuses to continue if the correction begins to oscillate.
2. Failure Analyzer as the ceiling
The Failure Analyzer sets the upper bound for the entire loop. If it misclassifies a database schema drift as a UI defect, the Patch Planner will target the wrong files. If it treats an authority violation as a prompt-quality issue, the Fixer Agent may accidentally weaken governance. Classification quality is therefore not a supporting detail. It is the first safety surface.
The analyzer should use three layers. The first layer is deterministic: log signatures, HTTP status, schema diffs, type errors, route names, changed files, permission policies, and CI job names. The second layer is an LLM reasoning panel for semantic cases such as requirement contradiction, prompt ambiguity, responsibility boundary mismatch, or business-process drift. The third layer is memory-backed: similar historical failure episodes, repair PRs, review decisions, rollback outcomes, and recurrence patterns.
Low-confidence classification should not proceed to automatic repair. It should produce an escalation package: evidence, candidate classifications, confidence, likely owners, and the smallest next diagnostic command. Early versions of the system should escalate often. The metric to optimize is not zero escalation. It is decreasing escalation with decreasing misclassification.
The KPI set should be explicit from the beginning: misclassification rate, human escalation rate, recurrence rate for identical failures, autonomous repair success rate, and mean time to recovery. These metrics matter because the runtime is trying to become safer as well as faster.
3. Scoped harness before cross-cutting harness
Repair must run in two layers. The scoped harness checks the affected area first: a booking harness for booking, a prompt harness for prompt changes, a CI harness for CI failure, a contract harness for SOW changes. This local replay proves that the patch actually addresses the visible defect.
Only after the scoped harness passes should the cross-cutting harness run. The cross-cutting harness checks regression safety across API contracts, permissions, logs, security, cost, latency, user flows, documents, and adjacent agent workflows. This order is not cosmetic. Running the global harness first creates noisy failures and hides causality. Running only the local harness creates local repairs that break the system around them.
The merge predicate should therefore include both levels.
4. Meta-harness: harnesses need coverage too
A cross-cutting harness can still be incomplete. A new API route may be added without API contract coverage. A new prompt may be deployed without prompt-policy evaluation. A new GitHub Actions job may exist outside the CI Repair Harness. A new external side effect may bypass preflight policy. The system therefore needs a meta-harness: a harness for harness coverage.
The meta-harness watches repository structure, runtime surfaces, tools, prompts, routes, schemas, workflows, and documents. Its question is simple: when the system gains a new surface, which harness is responsible for it? If the answer is missing, the meta-harness opens a coverage gap rather than pretending the system is safe.
This is the recursive step that turns harness infrastructure into a self-evolving system. The harness watches the product. The meta-harness watches the harness. The Memory Store watches repeated coverage gaps and proposes new harness templates.
5. Memory Store as prevention asset
The Memory Store should not be designed as a log warehouse. It should be designed as a recurrence-prevention asset. A useful memory record stores the failure description, cause classification, evidence, patch diff, patch rationale, rerun result, side effects, human review comments, human reviewer rationale, prevention rule, next detection pattern, and related harnesses.
The independent field for human reviewer rationale is important. Review comments capture what the reviewer said. Rationale captures why the reviewer judged the patch safe, unsafe, incomplete, or approval-worthy. That structured rationale lets the Memory Analyzer learn patterns in human judgment rather than only patterns in machine failure.
This keeps the Memory Store aligned with MARIA OS philosophy. The system may improve from failure, but the most valuable learning signal is often the human reasoning that decides where responsibility should return.
6. Responsibility envelope for Autonomous Fixer Agents
Autonomous repair requires a special responsibility envelope. The Fixer Agent may create scoped patches, update tests, draft prompt changes, adjust non-production configuration, write documentation patches, and open repair PRs. It may rerun scoped and cross-cutting harnesses. It may submit a learning candidate to the Memory Store.
It may not change production databases directly. It may not send emails, issue invoices, modify contracts, grant permissions, weaken required checks, merge its own PR, deploy to production, or expand its own authority. It may propose such changes, but application requires a human approval gate.
The most important boundary is constitutional. A self-healing system may repair code, prompts, workflows, and documents. It may not silently rewrite the rules that decide what it is allowed to repair.
7. Loop control and stability margins
Self-healing can become unstable when it keeps patching the symptom that its previous patch created. The harness runtime needs loop controls from the beginning: maximum repair attempts, repeated-failure caps, rollback-first patches, cost ceilings, escalation on authority drift, and quarantine for flaky or high-risk loops.
A practical starting policy is conservative. Three repair attempts per incident. Two attempts for the same failure signature. No automatic merge for high-risk changes. Human approval for production DB, billing, outbound communication, permissions, contract, and constitutional policy. Sandbox confirmation for external side effects. Automatic stop on cost spike or confidence collapse.
These limits are not bureaucracy. They are stability margins. They keep a repair loop from turning into a control oscillation.
8. Phasing the implementation
The implementation path should not jump from CI repair to all-of-MARIA self-evolution. The final phrase is too large for one phase. A better roadmap splits the system into milestones.
- Phase 1: Cloud Build and GitHub Actions failures to diagnosis and scoped repair PR.
- Phase 2: E2E failures to UI, API, and DB root-cause mapping.
- Phase 3: LLM, RAG, and prompt quality harnesses with bounded improvements.
- Phase 4: Agent workflow failures, routing repair, and human escalation repair.
- Phase 5: Harness Coverage Meta-Harness.
- Phase 6: dependency inference between scoped harnesses.
- Phase 7: Failure Memory Store for recurrence prevention.
- Phase 8: Preventive Harness that detects risky changes before failure.
- Phase 9: MARIA Self-Healing Runtime completion statement and external release.
Phase 9 is deliberately framed as a statement of completion rather than another open-ended implementation phase. By the time preventive harnessing works, the technical pieces are mostly present. Phase 9 is the point where MARIA OS names the integrated capability, publishes the operating model, and exposes the measurement standard.
This roadmap makes self-evolution executable. Each phase produces a measurable capability rather than a vague promise of autonomy.
9. Why this changes the category
Agent governance is about making autonomy accountable. Self-healing agent infrastructure is about making accountable autonomy improve itself under constraints. The difference is decisive. The first category manages agents. The second category operates the nervous system that keeps agentic organizations alive under disturbance.
MARIA OS is positioned to make this shift because it already treats responsibility gates, evidence trails, runtime episodes, and approval boundaries as first-class architecture. MARIA Self-Healing Runtime connects those objects into a repair loop. It turns FDE knowledge into Memory Store assets. It turns CI failures into scoped repair proposals. It turns prompt failures into replayable episodes. It turns organizational drift into owner-routed interventions.
If MARIA OS publishes MTTR, HITL convergence, failure recurrence, misclassification rate, and coverage gap detection as first-class product metrics, it can define the measurement standard for AI infrastructure resilience rather than merely participating in it.
Conclusion
A harness that only tests is useful. A harness that gates is safer. A harness that diagnoses, repairs, replays, learns, and preserves its own responsibility envelope becomes infrastructure. That is the strategic move: from agent governance OS to self-healing agent infrastructure.
The hard part is not generating patches. The hard part is making repair bounded, reviewable, replayable, and unable to grant itself more power. That is why MARIA Self-Healing Runtime is not an automation feature. It is the runtime governance layer for agentic systems that must keep improving without losing accountability.