HarnessMutation: Governed Agent Runtime Evolution

• HarnessMutation is a governed evolution mechanism for agent runtime configurations, enabling persistent, validated changes to operational capabilities.
• It reframes adaptation by treating generated code as persistent, executable operational cognition that is versioned and auditable.
• The framework enforces explicit validation, traceability, and rollback via a structured runtime graph and governance agents, ensuring bounded evolution.

Searching arXiv for the primary paper and closely related work on agent harnesses and governed runtime evolution. HarnessMutation is a mechanism for governed evolution of an agent runtime’s operational substrate. It is introduced within a framework for “governed runtime evolution in multi-agent systems through executable operational cognition,” where agent-generated artifacts are treated as persistent runtime capabilities rather than transient outputs (Garralda-Barrio, 26 May 2026). In this formulation, runtime adaptation is not modeled as unrestricted self-modification. Instead, it is a bounded and observable process over persistent operational memory, subject to explicit validation, traceability, evaluation, and rollback constraints. The concept is situated in a broader shift from viewing code as a disposable output artifact toward treating code as an executable operational substrate that can be created, executed, revised, persisted, and reused within long-running cognitive loops (Garralda-Barrio, 26 May 2026).

1. Formal definition and conceptual scope

HarnessMutation is defined formally as a governed transformation over a harness configuration: $\mu : h_i \rightarrow h'_i$ where a concrete harness instance is

$h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$

with $p_i$ denoting prompting policies, $t_i$ executable tools, $e_i$ evaluators, $m_i$ memory and contextual state, $g_i$ governance constraints, $o_i$ executable operational artifacts such as agent-initiated code, skills, and workflows, and $k_i$ structured operational knowledge represented as a runtime graph (Garralda-Barrio, 26 May 2026). The transformed configuration $h'_i$ is the result of applying the mutation.

A HarnessMutation can change prompts, tools, workflows, evaluators, routing policies, memory rules, skill implementations, benchmark definitions, or graph relations, but only under explicit governance: the change must be observable, versioned, validated, reversible, and recorded (Garralda-Barrio, 26 May 2026). This requirement distinguishes it from broader notions of self-modifying code. The harness itself is treated as an optimization object,

$h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$0

and, at iteration $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$1, candidate harnesses $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$2 are compared using

$h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$3

with

$h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$4

where $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$5 is task quality, $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$6 robustness, $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$7 validation consistency, $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$8 the reuse value of generated operational artifacts, and $h_i = (p_i, t_i, e_i, m_i, g_i, o_i, k_i)$9 operational cost (Garralda-Barrio, 26 May 2026). The explicit inclusion of $p_i$0 means that harnesses are evaluated not only by immediate performance but also by their capacity to generate useful future executable cognition.

The paper distinguishes between an artifact and a capability. An artifact is any generated operational entity, including a prompt, evaluator, workflow, routing policy, executable skill, or code component. A capability is an artifact that has passed validation and governance, been persisted, and been integrated for reuse in future runtime behavior (Garralda-Barrio, 26 May 2026). HarnessMutation therefore operates over capabilities and harness configurations, not over transient artifacts.

2. Executable operational cognition

The conceptual foundation of HarnessMutation is executable operational cognition. This denotes the persistent operational representation of executable artifacts that can influence future behavior, evaluation policies, orchestration, and coordination (Garralda-Barrio, 26 May 2026). Generated code artifacts become operational cognition once they are persisted and versioned, evaluated and governed, and reused in future runs. At that point they are no longer mere outputs or passive memory; they become runtime capabilities that shape subsequent agent behavior.

This reframes operational memory. Rather than treating memory as text or embeddings, the system’s operational memory is described as a library of executable capabilities plus graph-level knowledge of how those capabilities relate (Garralda-Barrio, 26 May 2026). Agents reason not only about external tasks but also about the harness itself: they can propose updates to workflows, validators, and policies, while specialized “evolution” or “governor” agents interpret traces, identify failure modes, and propose HarnessMutation operations (Garralda-Barrio, 26 May 2026).

The harness $p_i$1 is thus the object of optimization, and the evolution of $p_i$2 via mutations $p_i$3 is itself a cognitive process. The runtime graph also supports planning over skills and capabilities through a composition operator

$p_i$4

which takes a subset of skills $p_i$5 and synthesizes a composed capability $p_i$6, guided by dependency and validation relations in the graph (Garralda-Barrio, 26 May 2026). HarnessMutation is the mechanism through which this substrate changes while remaining governed, observable, and reversible.

A plausible implication is that the framework attempts to make adaptation endogenous to the runtime while keeping the adaptive process legible to governance and audit mechanisms. The paper states this directly in architectural terms but does not present an empirical measure of cognitive benefit (Garralda-Barrio, 26 May 2026).

3. Architecture and lifecycle

The proposed architecture is harness-oriented and multi-layered. It consists of specialized governance agents, a governed runtime kernel, a knowledge-grounded runtime graph, and an execution and artifact substrate (Garralda-Barrio, 26 May 2026). Specialized governance agents carry roles such as generation, validation, review, and reflection. The governed runtime kernel serves as the central control plane for lifecycle state, validation gates and risk checks, mutation boundaries and rollback, and audit trail and governance policies. The knowledge-grounded runtime graph is the structured memory layer, with nodes including capabilities, workflows, evaluators, policies, benchmarks, mutations, traces, and agents, and edges encoding dependency, provenance, validation, supersession, mutation lineage, and failure relations. The execution and artifact substrate provides tools, sandboxes, persistent files, state stores, and the generated artifacts themselves (Garralda-Barrio, 26 May 2026).

HarnessMutation sits in the kernel and graph layers. A mutation proposal is treated as a first-class object whose input and output harness states, lineage, evaluation evidence, and rollback conditions are captured in the graph and registries (Garralda-Barrio, 26 May 2026).

The artifact lifecycle proceeds through a task loop, execute–revise, persist–evaluate, executable operational cognition, governed evolution, and future runtime behavior (Garralda-Barrio, 26 May 2026). During the task loop, an agent generates scripts, tests, workflows, skills, or policies. These artifacts are executed in a sandbox and iteratively refined. Promising artifacts are then persisted and evaluated beyond the single task through benchmarks, regression tests, and robustness checks. Once validated, they become persistent capabilities that shape future behavior. Governed evolution then applies bounded changes to harness components or capabilities, promotes, demotes, or deprecates capabilities, and records lineage, dependencies, validation, and mutation histories in the runtime graph. Future execution uses trusted and canonical capabilities, while feedback from use feeds into later evaluation and possible future mutations (Garralda-Barrio, 26 May 2026).

The change step is central. HarnessMutation is the explicit mechanism through which a runtime component is altered under a change contract and evaluated before it affects the canonical operational substrate (Garralda-Barrio, 26 May 2026).

4. Governance model and bounded evolution

Governance is defined through lifecycle control, review procedures, risk limits, and rollback support. Capabilities move through a fixed lifecycle: $p_i$7 (Garralda-Barrio, 26 May 2026). Experimental capabilities are newly generated and used cautiously. Validated capabilities have passed designed tests and benchmarks. Trusted capabilities are used as reliable components across tasks. Canonical capabilities are the preferred implementations within their functional class. Deprecated capabilities are retained for provenance but not used in new runs (Garralda-Barrio, 26 May 2026).

The governance loop begins when an agent or subagent generates a skill, workflow, evaluator, or policy. The candidate is evaluated on traces, tests, and benchmarks, and compared with alternatives. Governance review then checks evidence strength, risk gates such as safety, cost, and robustness, and approval constraints, whether human or automated. If the proposal proceeds, a HarnessMutation is staged by specifying which components of $p_i$8 change, the expected improvement, the invariants expected to hold, the evaluation capable of falsifying the change, and rollback conditions. If approved, the mutation is applied to produce $p_i$9, and lifecycle states are updated accordingly. If rejected, the proposal is retained as negative evidence. Every stage is recorded in the runtime graph and registries, and subsequent operational feedback may trigger further mutations or deprecation (Garralda-Barrio, 26 May 2026).

The runtime graph is formalized as

$t_i$0

with entity set $t_i$1 and typed edges

$t_i$2

where

$t_i$3

(Garralda-Barrio, 26 May 2026). Each node $t_i$4 has metadata

$t_i$5

where $t_i$6 is content or specification, $t_i$7 a quality score, $t_i$8 temporal and lifecycle metadata, and $t_i$9 lineage information (Garralda-Barrio, 26 May 2026). The quality score is given by

$e_i$0

with $e_i$1 performance, $e_i$2 robustness, $e_i$3 stability, $e_i$4 reuse utility, and $e_i$5 operational risk (Garralda-Barrio, 26 May 2026).

The paper characterizes this as bounded evolution. The bounds are fourfold: scope bound through a bounded change contract and explicit invariants; validation bound through predefined evaluation gates and recorded rejection of failed proposals; lifecycle bound through controlled eligibility for promotion and the prohibition on silent changes to canonical components; risk bound through the risk term $e_i$6 and governance constraints; and rollback capability through mandatory reversion conditions for post-deployment failures (Garralda-Barrio, 26 May 2026). The paper notes that it does not give a formal algorithm for enforcement; instead, the operational boundaries are defined by the architectural design and by emphasis on change contracts, rollback, and lifecycle transitions (Garralda-Barrio, 26 May 2026).

5. Implementation substrate and protocol realization

The prototype architecture is implemented on top of LangGraph and DeepAgents, which provide durable execution, tool orchestration, checkpointing and persistent stores, subagent delegation, and middleware policies including limits, retries, summarization, and a code interpreter (Garralda-Barrio, 26 May 2026). The paper’s contribution is a governed runtime layer above these services.

In the reference implementation, described as governed_agent_runtime_v10.py, the system includes a create_deep_agent runtime defining the baseline harness, a Governed Runtime Kernel, agent-facing Governance Tools, Specialized Subagents, Persistent Backends, a Runtime Artifacts Store, and Registries and Audit State (Garralda-Barrio, 26 May 2026). The specialized subagents include roles such as “evolution,” “validator,” “governor,” “worker,” and “reflection.” Persistent backends include /memory, /skills, /harness, /evals, and /telemetry. Typed records include TraceEvent, GeneratedSkillSpec, HarnessMutation, CapabilityReview, and HarnessState (Garralda-Barrio, 26 May 2026).

The paper does not provide explicit pseudocode, but it outlines a protocol. Observation and problem identification occur through telemetry and failure analysis. An evolution worker agent generates a mutation proposal, including new code or configuration for the targeted component and a change contract describing scope, invariants, and intended improvement. Preliminary evaluation compares the candidate against held-out benchmarks or regression tests. Governance review checks evaluation results, risk implications, and policy compliance. If approved, a HarnessMutation object is recorded with source and target harness state identifiers, a change description, linked evaluation evidence, and rollback conditions. The mutation is then applied, lifecycle states are updated, and nodes and edges are inserted into graph and registries for the new capability, mutation lineage, associated evaluations, and failure modes. Operational rollout follows, with telemetry gathered through TraceEvents, and rollback triggered if failures violate the change contract (Garralda-Barrio, 26 May 2026).

This protocol is presented as applicable both to small local edits, such as a skill update, and to broader harness modifications. The article’s implementation claims remain architectural and infrastructural rather than performance-oriented: the paper explicitly states that it does not report quantitative experiments (Garralda-Barrio, 26 May 2026).

6. Illustrative use cases and relation to prior approaches

An illustrative example in the paper concerns a normalization script in a long-running software assistant that frequently encounters inconsistent input schemas. During one task, the agent generates a temporary normalization script to regularize payloads. Under the proposed framework, the script executes locally, is detected as repeatedly useful, is persisted as a candidate capability, and is evaluated on diverse inputs, robustness tests, and edge cases. After passing tests, it becomes an experimental and then validated or trusted capability. When a better version is proposed, a HarnessMutation is staged to replace or wrap it; the new script is tested, and, if it improves performance while preserving invariants, it supersedes the old one. The runtime graph then records which evaluator approved it, which workflows use it, which mutations produced the current version, and under what conditions it fails (Garralda-Barrio, 26 May 2026).

The paper generalizes this pattern to regression tests created during debugging that later become part of the evaluation suite, workflows initially created for a single task that later become canonical orchestration templates, and evaluators or benchmarks evolved to better measure desired behavior (Garralda-Barrio, 26 May 2026). In all cases, evolution is represented as HarnessMutation plus lifecycle transitions rather than as silent change.

In relation to prior approaches, the paper contrasts HarnessMutation with unrestricted self-modifying code, standard tool-learning or function-call adaptation, typical long-term memory systems, and governance and safety frameworks focused only on call-time policy checks (Garralda-Barrio, 26 May 2026). Traditional self-modifying systems may alter their own code without clear boundaries, lineage, or rollback. Tool-learning systems often produce tools that are ephemeral or stored without strong lifecycle semantics. Typical long-term memory stores text, embeddings, or summaries rather than executable capabilities with provenance and evaluation history. Existing governance frameworks may enforce permissions or filters at runtime without governing how workflows, evaluators, and policies themselves evolve (Garralda-Barrio, 26 May 2026).

The conceptual advances identified in the paper are the formalization of harness configurations $e_i$7 as optimization objects with an explicit runtime evolution operator $e_i$8; the introduction of a lifecycle model tied to capability transitions; the framing of persistent executable artifacts as operational cognition; and the use of a knowledge-grounded runtime graph in which lineage, dependency, supersession, and failure relations are first-class (Garralda-Barrio, 26 May 2026).

A plausible implication is that the framework is best understood less as a single algorithm than as a governance pattern for adaptive agent infrastructure. The paper’s own description supports this reading by repeatedly emphasizing lifecycle, observability, and auditability over autonomous optimization claims (Garralda-Barrio, 26 May 2026).

7. Limitations, risks, and significance

The paper explicitly describes itself as an architectural vision rather than an empirical performance claim and states that no large-scale benchmark demonstrates that governed evolution outperforms simpler systems (Garralda-Barrio, 26 May 2026). This is an important interpretive constraint. The contribution is a formal and architectural foundation, not a quantified empirical validation.

The identified risks include evaluation misalignment, mutation regressions, graph inconsistency and drift, capability bloat and staleness, and distributed consistency challenges (Garralda-Barrio, 26 May 2026). Weak or incomplete benchmarks may promote artifacts that overfit tests while regressing on real tasks. Mutations may improve average performance while harming rare but critical cases. Runtime graph errors may distort composition or trust decisions. Capability libraries may become redundant, stale, or unsafe without effective pruning and deprecation. In multi-service or multi-team settings, synchronization of lifecycle states, mutations, and rollback becomes difficult (Garralda-Barrio, 26 May 2026).

Future work is proposed in regression-aware mutation policies and trust regions for changes, better artifact-level trust scoring and risk estimation through refinement of $e_i$9 and $m_i$0, robust benchmarks and evaluation pipelines including benchmark synthesis, graph consistency and validation methods, cost-aware runtime optimization when exploring harness variants, and distributed capability synchronization and governance (Garralda-Barrio, 26 May 2026).

The broader significance of HarnessMutation lies in its attempt to provide a formal vocabulary and governance structure for systems in which agent-generated code and workflows persist into future operation. It defines a governed operator

$m_i$1

that acts on prompts, workflows, evaluators, skills, policies, retrieval and memory strategies, and the runtime graph, with each mutation explicit, bounded, evaluated, governed, reversible, and observable (Garralda-Barrio, 26 May 2026). The central claim is not that autonomous runtime evolution should be unconstrained, but that continuous adaptation becomes operationally viable only when evolution remains explicit, auditable, and constrained (Garralda-Barrio, 26 May 2026).