The Static-Agent Problem

Deployed agentic systems do not learn from the interactions they handle. When a failure recurs, it persists until a human-driven update ships a fix. That cycle can be slow, and the gap between failure and resolution is a direct operator cost [1].

A class of self-evolving agent systems has emerged to address this, but all existing approaches confine evolution to text-mutable artifacts: skill files, prompt configurations, memory schemas, and workflow graphs. The agent harness itself remains untouched. Because routing logic, hook ordering, state invariants, and dispatch mechanisms live in source code rather than in any text artifact, an entire category of structural failure is physically unreachable from the text layer [1]. Operators running systems with persistent structural bugs have had no automated path to resolution short of manual engineering work.

What MOSS Is

MOSS is a system that performs self-rewriting at the source level on production agentic substrates. Its core design premise is that source-level adaptation is a more general medium than text-layer evolution: it is Turing-complete, a strict superset of every text-mutable scope, takes effect deterministically rather than through base-model compliance, and does not erode under long-context drift [1].

For operators, the practical implication is that MOSS can reach failure classes that prompt-tuning or memory-schema updates cannot. Structural problems in routing, dispatch, or hook ordering become addressable without waiting for a human engineer to identify and patch them.

How the Pipeline Works

Each MOSS evolution cycle is anchored to an automatically curated batch of production-failure evidence. Rather than acting on raw logs or individual error signals, the system assembles a representative set of failures before any code modification begins. This curation step is designed to prevent rewrites from targeting noise or one-off anomalies [1].

Code modification itself is delegated to a pluggable external coding-agent CLI. MOSS does not perform the rewriting directly; instead, it retains control over stage ordering and verdicts while handing the actual code-generation task to an external tool. This separation means operators can substitute different coding agents as the ecosystem evolves without altering the core MOSS pipeline [1].

The pipeline is deterministic and multi-stage. Stage ordering is enforced by MOSS, ensuring that evidence curation precedes code generation and that code generation precedes validation. No stage can be skipped or reordered by the coding agent [1].

Verification and Deployment Safety

Before any candidate rewrite reaches production, MOSS validates it by replaying the curated failure batch against the candidate image inside ephemeral trial workers. These short-lived environments isolate the candidate from the live system, so a flawed rewrite cannot affect production traffic during evaluation [1].

Promotion to production requires passing that replay validation and clearing a user-consent gate. The actual deployment mechanism is an in-place container swap, which replaces the running container with the validated candidate image. Health-probe-gated rollback is built into the promotion path: if post-swap health probes fail, the system can revert without manual intervention [1].

For operators evaluating adoption, this architecture means the blast radius of a bad rewrite is bounded. The consent gate also preserves human oversight at the promotion decision point, which matters for teams operating under change-management policies.

Benchmark Results

The researchers evaluated MOSS on OpenClaw, a benchmark for agentic task performance. In a single evolution cycle and without human intervention, MOSS lifted the four-task mean grader score from 0.25 to 0.61 [1]. That improvement, from roughly one-quarter to more than three-fifths of the maximum grader score across four tasks, occurred through one automated rewrite-and-deploy cycle.

No additional benchmark results beyond the OpenClaw evaluation are reported in the available source material.

Scope and Limitations

MOSS addresses the structural failure classes that text-layer approaches cannot reach: problems embedded in routing code, hook ordering, state invariants, and dispatch logic [1]. For operators whose recurring failures trace to these layers, MOSS represents a qualitatively different intervention surface compared to prompt or memory updates.

The paper does not detail constraints on the size or complexity of codebases MOSS can operate on, nor does it specify which external coding-agent CLIs have been tested as the pluggable component. The consent-gated promotion model preserves human oversight but also means fully unattended operation requires a deliberate decision to configure that gate permissively. Open questions around multi-cycle stability, interaction effects between successive rewrites, and behavior under adversarial failure signals are not addressed in the available source material [1].

FAQ

Q. Does MOSS replace existing prompt-tuning or memory-update workflows? MOSS operates at the source level and is described as a strict superset of text-mutable evolution scopes [1]. It addresses failure classes that text-layer approaches cannot reach, but the paper does not position it as a drop-in replacement for prompt or memory workflows in cases where those are sufficient.

Q. What coding agent is used for the actual rewriting step? The coding-agent CLI is described as pluggable and external. MOSS delegates code modification to this component while retaining stage ordering and verdicts, but the paper does not name a specific default CLI or list tested options [1].

Q. What happens if a candidate rewrite fails validation in the trial workers? Candidates are verified by replaying the curated failure batch in ephemeral trial workers before promotion. The paper describes health-probe-gated rollback at the container-swap stage, but does not detail the handling path when a candidate fails the trial-worker replay step specifically [1].

Q. How many evolution cycles does MOSS require to reach the reported benchmark improvement? The OpenClaw result, a mean grader score increase from 0.25 to 0.61, was achieved in a single evolution cycle [1]. Multi-cycle behavior is not characterized in the available source material.

Q. Is human approval required for every deployment? Promotion is described as user-consent-gated, meaning a human approval step is part of the container-swap path [1]. Teams seeking fully automated operation would need to configure that gate accordingly, though the paper does not specify the mechanics of doing so.

Key takeaways

  • MOSS performs self-rewriting at the source level, reaching structural failure classes in routing, dispatch, and hook ordering that text-layer evolution approaches cannot address [1].
  • Each rewrite cycle is anchored to a curated batch of production-failure evidence and proceeds through a deterministic, multi-stage pipeline with stage ordering enforced by MOSS [1].
  • Candidate rewrites are validated in ephemeral trial workers by replaying the failure batch before any promotion to production [1].
  • Deployment uses an in-place container swap with a user-consent gate and health-probe-gated rollback, bounding the blast radius of a failed rewrite [1].
  • On the OpenClaw benchmark, MOSS raised a four-task mean grader score from 0.25 to 0.61 in a single automated cycle without human intervention [1].