Recursive Self-Evolution for Autonomous AI Systems

A system that protects itself — and gets better at it, measurably. MAREF's recursive evolution engine tracks convergence with a Lyapunov-style heuristic over observed metric history.

What is recursive self-evolution for AI agents?

Recursive self-evolution is a closed-loop process where an AI system observes its own performance, identifies improvement opportunities, generates and validates changes, deploys them, and repeats. Unlike traditional MLOps (where humans initiate retraining), recursive evolution is autonomous — the system continuously adapts without requiring human intervention for each cycle.

MAREF implements this as the Self-* pipeline: Self-Observer → Self-Diagnostician → Self-Architect → Self-Executor → Self-Healer → Self-Optimizer. Each component has a distinct role, and the pipeline is governed by the same safety constraints that apply to all agent activity.

How does MAREF's evolution engine guarantee safety during self-modification?

Self-modification is inherently dangerous. MAREF addresses this with a multi-layer safety architecture:

  • Constitutional Red Lines — Immutable safety constraints that no evolution cycle can override. These are enforced at the meta-governance layer.
  • Rule Freeze Zone — Critical governance rules require HMAC-signed approval from a qualified human to change.
  • AST Sandbox — All generated code is parsed, validated, and sandbox-tested before deployment. Malformed or unsafe ASTs are rejected.
  • Atomic deployment + rollback — Changes are deployed atomically. If validation tests fail after deployment, the system automatically rolls back to the previous known-good state.
  • Saturation detection — The optimizer detects when improvements have plateaued and halts the evolution cycle, preventing overfitting or degradation.

What is Lyapunov-style convergence monitoring and why does it matter?

In control theory, Lyapunov stability is a mathematical framework for proving that a dynamic system converges toward a desired state. MAREF adapts the spirit of that idea as a runtime monitoring heuristic: it computes a stability exponent from the observed history of error metrics and watches whether those metrics trend downward over time.

This is runtime telemetry, not a formal proof. MAREF does not assert that error rates monotonically decrease — it instruments the metrics and lets the public benchmark suite reproduce the trend. That reproducibility is what makes the claim checkable rather than a marketing assertion, which matters for safety-critical agent deployments.

convergence monitoring: heuristic Lyapunov exponent over metric history (see tests/benchmark/)

How does red-blue adversarial evolution work?

Red-blue evolution pits adversarial attack agents (red) against defensive agents (blue) in structured rounds. Each round has five stages: reconnaissance, exploitation, escalation, persistence, and exfiltration. Red agents probe the defense at a configured level, blue agents learn from each attack and strengthen their defenses, and every round scores detection, mitigation, recovery, and adaptation.

Convergence is monitored rather than assumed: the engine tracks whether error metrics trend downward across rounds and reports the delta, which you can reproduce from the public benchmark suite.

Running a red-blue defense round
from maref.redblue import RedBlueEngine, PHASE1_ATTACKS
from maref.redblue import RedLevel, BlueLevel

engine = RedBlueEngine()
result = engine.run_round(
    round_id="learn-1",
    phase=1,
    attack=PHASE1_ATTACKS[0],
    red_level=RedLevel.R3,
    blue_level=BlueLevel.B2,
)

print(f"defense score: {result.total_score:.0f}/100")

What is the Self-* architecture?

The Self-* (Self-star) architecture is MAREF's implementation of recursive evolution, organized as eight autonomous components:

  • Self-Observer — Continuously monitors codebase changes, test success rates, and system metrics.
  • Self-Knowledge — Maintains structured knowledge of the codebase, test suite, and architecture.
  • Self-Diagnostician — Runs full-system health diagnostics and identifies improvement areas.
  • Self-Architect — Generates architecture proposals for identified improvements.
  • Self-Executor — Implements changes: generates code → AST validation → security check → atomic deploy → verify → rollback on failure.
  • Self-Healer — Detects and recovers from failures using partition recovery strategies.
  • Self-Optimizer — Runs mutation → sandbox → accept/revert optimization cycles with saturation detection.
  • Self-Version — Manages dependency version pinning and API compatibility matrices.

Each Self-* component runs within the governance layer's safety constraints — no component can modify constitutional rules, cross its declared trust boundary, or operate without audit logging.

Can recursive evolution be used without MAREF's governance layer?

Technically yes — the Self-* modules can be imported individually. However, running autonomous self-modification without MAREF's governance layer is strongly discouraged for production use. The governance layer provides the circuit breaker, drift detection, constitutional red lines, and audit trail that make self-evolution safe rather than reckless.

For a deeper look at the Self-* implementation, see the Evolution feature page. For governance fundamentals, see Agent Governance.

Evolution Engine Specifications

Type
Recursive Self-Evolution with Red-Blue adversarial training
Self-* components
8 (Observer, Knowledge, Diagnostician, Architect, Executor, Healer, Optimizer, Version)
Convergence monitoring
Lyapunov-style heuristic exponent over metric history
Adversarial model
Red-blue rounds, 5 stages, configurable red/blue levels
Defense scoring
Detection/mitigation/recovery/adaptation, 0-100
Safety constraints
Constitutional Red Lines, Rule Freeze Zone, AST Sandbox, Atomic rollback