PaperlayerView exact revision on arXiv

Source-linked AI summary

RegenHarness: A Robot Agent Harness with Evidence-Gated Recursive Self-Improvement

Kailin Wang, Haoxiang Jie, Yaoyuan Yan, Zhiyou Heng, Zhaosong Li

arXiv:2609.27612v1cs.RO

TL;DR

Long-horizon robots must coordinate heterogeneous skills while distinguishing a model’s proposal or a controller’s termination from verified completion. RegenHarness uses evidence-gated execution and a cross-mission configuration-revision protocol; its deployment cases document integrated physical workflows and history-dependent completion.

  • Problem

    Long-horizon robot agents must choose capabilities, ground and observe their execution, verify intended effects, and recover when stages fail.

    Source: §1 · pp. 1–2

  • Method

    RegenHarness binds heterogeneous skill invocations to explicit contracts and uses independent verification to gate committed progress and cross-mission harness revisions.

    Source: §1 · p. 2

  • Results

    The warehouse deployment documents linked evidence for a voice-triggered inspection workflow, while the circuit case demonstrates history-dependent completion rather than endpoint proximity alone.

    Source: §6.2 · p. 11, §8 · p. 16

  • Takeaways & Limitations

    The cases demonstrate integrated perception, physical execution, communication, and history-dependent completion in real-world robot tasks.

    Source: §8 · p. 16

    The harness is intended to contain specified runtime failures, not to prove correctness against compromised sensors, malicious hardware, or arbitrary verifier defects.

    Source: §3 · p. 3

Abstract

from arXiv · show

Long-horizon robot execution requires a clear distinction between a model's proposal, a controller's termination, and verified task completion. We present RegenHarness, an evidence-gated robot-agent harness connecting task planning to heterogeneous robot skills. Its execution architecture couples a model loop for context-conditioned proposals with an agent loop for dispatch, observation, verification, commitment, and bounded recovery. Four role-isolated contexts separate planning, supervision, verification, and recovery inputs. Versioned memory distinguishes observed facts from accepted task progress, while an identity- and version-bound commit gate controls updates to trusted task state. The runtime combines duplicate-dispatch control, resource leases, and recovery budgets under explicit backend contracts, and checks the original user goal before reporting completion. To our knowledge, we are the first to introduce an evidence-gated recursive self-improvement (RSI) protocol for embodied robotic agents. Across missions, execution records motivate candidate changes to context rules, task templates, routing, and recovery policies; fixed regression checks and release authorization govern their acceptance; versioned rollout and rollback preserve configuration traceability. This RSI protocol revises the harness configuration without online model-weight updates or permission to weaken the commit gate. A real quadruped deployment documents voice-triggered warehouse navigation, panoramic inspection, visual analysis, message delivery, return, and spoken reporting through linked audio, images, trajectories, and receipts. A separate circuit demonstrates why completion depends on execution history rather than endpoint proximity alone. Together, the cases demonstrate integrated perception, physical execution, communication, and history-dependent completion in real-world robot tasks.

1 Introduction

RegenHarness frames long-horizon robotics as a problem of coordinating heterogeneous capabilities while distinguishing proposals and controller termination from verified task progress. It combines evidence-gated execution, role-isolated contexts, auditable state, and bounded recovery, and introduces a cross-mission RSI protocol for revising harness configuration under fixed checks.

1 Introduction

  • As task length grows, the harness must detect failed transitions, preserve useful intermediate state, choose fallbacks, and prevent false completion from corrupting downstream decisions.The paper distinguishes its runtime contract—authority over task state, evidence flow, and reconstruction of progress—from execution loops or verification alone.Source: §1 · p. 2
  • Only independently verified outcomes may advance committed task state, separating model proposals and controller termination from accepted progress.The paper motivates this distinction because a waypoint can mark only one stage of a larger request, not its completion.Source: §1 · p. 2
  • Four bounded context views serve planning, skills, verification, and recovery; the verifier does not inherit the planner’s completion claim.Source: §1 · p. 2
  • Capability cards, idempotent dispatch, leases, timeouts, cancellation, and typed, budgeted recovery coordinate heterogeneous backends without granting them global-success authority.Source: §1 · p. 2
  • Version-bound observations, invocations, evidence, verdicts, commits, and recovery costs support deterministic inspection and restart-oriented recovery.Source: §1 · p. 2
  • RegenHarness introduces cross-mission RSI for embodied robots, revising harness configuration from execution records under fixed checks, mission-boundary release, and versioned rollback.The protocol does not change active missions or weaken verification and safety gates.Source: §1 · p. 2

2 Problem Formulation

The formulation models a long-horizon goal as dependency-constrained stages executed by heterogeneous providers, with explicit completion, safety, resource, and recovery constraints. It distinguishes observed facts from verified committed progress and aims to maximize verified completion while limiting runtime failures.

2 Problem Formulation

  • A task contract represents the goal with an acyclic subgoal graph, original completion conditions, safety and resource constraints, and recovery budgets.Each node specifies target effects, eligible capability classes, dependencies, and evidence requirements.Source: §2 · p. 3
  • Only a satisfied verdict with matching task, node, invocation, and state-version identities may advance committed facts; observations may remain unverified.Observed facts retain known provenance and freshness, while committed facts are admitted through verification; commitment is not a motion command or a guarantee of infallible sensing.Source: §2 · p. 3
  • The objective is verified task completion while minimizing false completion, unsafe actions, unrecoverable loops, resource conflicts, and irreproducible decisions under a fixed capability pool.Source: §2 · p. 3

3 Design Principles and Threat Model

RegenHarness confines runtime failure handling to explicit authority boundaries, fail-closed evidence checks, and bounded autonomous loops. Its threat model covers execution and coordination failures, not compromised sensors, malicious hardware, or arbitrary verifier defects.

3 Design Principles and Threat Model

  • The harness targets erroneous completion claims, stale or misbound evidence, repeated requests, concurrent resource use, and interrupted execution, not compromised sensors, malicious hardware, or arbitrary verifier defects.The listed failure classes define the intended containment scope.Source: §3 · p. 3
  • Planning, prediction, and execution cannot independently verify, commit, or override safety; later components cannot relax a safety veto.A planner may propose a skill, while a skill or world model may report or predict effects, but neither alone certifies physical goal achievement.Source: §3 · p. 3
  • Physical-skill termination is not proof of its intended effect, so missing evidence fails closed and retries, view changes, policy switches, and replanning consume explicit budgets.Ambiguity may trigger active re-perception rather than task-state advancement; budgets make escalation or safe stopping inspectable.Source: §3 · pp. 3–4

4 RegenHarness Architecture

RegenHarness separates context-conditioned proposals from the guarded task-level process that executes, verifies, and commits work. Typed task contracts describe testable effects and conditions, while the original user goal remains the completion criterion.

4 RegenHarness Architecture

  • The architecture’s versioned memory supplies four role-isolated contexts, while only the identity- and version-bound commit gate accepts task progress.The figure distinguishes execution and context paths, accepted-progress paths, and bounded-recovery paths.Source: Figure 1 · p. 4

4.1 Model and Agent Loops

  • The model loop revises role-conditioned proposals as context and feedback change, while the agent loop selects, executes, verifies, and commits physical work.The loops need not use separate models or fixed frequencies; only the guarded agent loop accepts task progress.Source: §4.1 · pp. 4–5

4.2 Typed Effects and Task Contracts

  • Effects may be symbolic, metric, relational, visual, or temporal, and typed preconditions and postconditions make them testable rather than equating task success with controller status.For an inspect-and-return request, completion also requires evidence from observation and reporting nodes.Source: §4.2 · p. 5
  • A task contract retains the original goal and organizes execution as a dependency graph whose nodes specify subgoals, success conditions, capabilities, parameters, resources, evidence, timeouts, and recovery limits.The graph records required effects, while routing chooses an available backend to attempt them.Source: §4.2 · p. 5

4.3 Capability Cards and Routing

Capability cards and routing select among heterogeneous providers without granting them task-state authority. Role-isolated contexts bound what planning, execution, verification, and recovery can use from shared versioned state.

4.3 Capability Cards and Routing

  • Capability cards describe provider versions, supported embodiments, schemas, preconditions, side effects, latency, resources, cancellation, risk, failures, and evidence; deterministic filters precede configurable ranking.The scorer can rank eligible providers by predicted success, risk, uncertainty, latency, cost, and verified operational history, but it is not itself execution authority.Source: §4.3 · pp. 5–6
  • World-model predictions may assist routing or local planning but cannot establish post-execution success, and the runtime does not require a particular world model.Geometry-based planners, navigation skills, or conventional controllers can operate without learned prediction.Source: §4.3 · p. 6

4.4 Role-Isolated Contexts

  • The compiler creates bounded role views from one versioned state, selecting by role, scope, confidence, freshness, provenance, and item budget while rejecting expired or superseded records.C1 plans from goals and committed progress; C2 receives a subgoal and skill contract; C3 evaluates postconditions without planner-originated conclusions; C4 supports recovery and escalation.Source: §4.4 · p. 6
  • Separating contexts limits accidental leakage and correlated self-confirmation by treating context engineering as an information-access policy rather than undifferentiated prompt history.A planner-generated grasp claim may inform execution but cannot serve as evidence of grasp success for the verifier.Source: §4.4 · p. 6

4.5 Supervised Skill Lifecycle

The supervised skill lifecycle controls dispatch, resource use, and asynchronous execution, while evidence verification and guarded commitment distinguish terminal status from accepted progress. Original-goal verification remains a separate prerequisite to reporting success.

4.5 Supervised Skill Lifecycle

  • The supervisor validates requests, records dispatch intent, acquires robot and workspace leases, and binds idempotency keys before dispatching skills with structured lifecycle states.Repeated requests return an existing execution record rather than starting another physical action; leases are time-bounded coordination reservations.Source: §4.5 · p. 6
  • Persisted handles support reattachment for providers that implement it, while replaying a pending start requires provider-side deduplication to avoid repeated physical execution across a crash boundary.Long-running skills also have explicit deadlines.Source: §4.5 · p. 6
  • The reference supervisor treats cancel() return as completion and releases a resource lease, assuming synchronous cancellation; asynchronous providers require a stopping acknowledgment before reassignment.Physical reassignment requires a confirmed stopped or safe-hold state.Source: §4.5 · p. 6

4.6 Evidence, Verification, and Commit

  • A terminal execution retains an evidence packet with task and execution identity, dispatch state version, before-and-after observations, state estimates, and provider-proposed facts.Evidence references preserve source, timestamp, confidence, and file reference or checksum; packets remain stored even when verification rejects them.Source: §4.6 · p. 7
  • Independent postcondition checks and identity-, version-, and condition-bound commit guards authorize atomic node updates; all committed nodes still require a separate original-goal check before success reporting.The backend’s done signal may be evidence but is never sole authority, and an earlier result for a different target or obsolete state version cannot certify the current task.Source: §4.6 · p. 7

4.7 Budgeted Recovery

Budgeted recovery constrains retries and escalation using failure records and explicit limits. Trusted memory preserves evidence and task history while projecting accepted progress from ordered events.

4.7 Budgeted Recovery

  • Recovery routes structured verification failures through an escalation ladder and records prior attempts, evidence, excluded providers, and remaining budget before retrying.Repeating the same failed action without new evidence can be prohibited deterministically.Source: §4.7 · p. 7
  • Recovery budgets count authorized skill-level recovery actions, and exhausting task-contract limits requires escalation or termination rather than another automatic attempt.Retries repeat a bounded invocation, provider switches choose another implementation, and replanning revises the task or route proposal; controller cycles alone are not C4 events.Source: §4.7 · p. 7

4.8 Trusted Memory and Event Sourcing

  • The memory fabric separates working, spatial, episodic, operational, and semantic records, with provenance, confidence, validity intervals, and verification state for long-term records.Updates append records linked by supersedes or conflict relations instead of silently overwriting history.Source: §4.8 · p. 8
  • The trusted task store reconstructs current progress from ordered observation, commit, recovery-budget, and goal-verification events.Memory is stored task and evidence records, not a learned world model; versioning marks the record current for a decision without changing model weights.Source: §4.8 · p. 8
  • Exact replay of model decisions additionally requires original contexts, candidate sets, configuration, outputs, and randomness, whose complete capture remains an integration requirement.Execution snapshots and evidence records retain request, provider handle, state version, sources, and verdicts.Source: §4.8 · p. 8

4.9 Evidence-Gated Recursive Self-Improvement

RegenHarness uses a cross-mission RSI loop to revise harness configuration under evidence-based release checks. Approved versions roll out at mission boundaries, while lower safety layers retain authority over restrictions and motor-control safeguards.

4.9 Evidence-Gated Recursive Self-Improvement

  • RSI evaluates harness-configuration changes across missions, distinct from model-loop proposal revisions and agent-loop verification of physical progress.Changes cover context-selection rules, task templates, routing preferences, and bounded recovery policies.Source: §4.9 · p. 8
  • Revision candidates carry manifests linking affected components and motivating traces to intended effects and rollback versions, using stable skill and evidence interfaces.Mission records include evidence links, failures, and recovery costs.Source: §4.9 · p. 8
  • Acceptance requires preserved safety and evidence contracts, no regression on designated checks, improvement on a predeclared target metric, and release authorization.The updater cannot weaken its acceptance predicate, commit gate, or lower-level safety interlocks.Source: §4.9 · p. 8
  • Approved revisions become available only at mission boundaries, active missions stay pinned to their original configuration, and failed releases return to the last accepted version.Online model-weight updates are outside the protocol.Source: §4.9 · p. 8

4.10 Safety and Resource Authority

  • The harness adds task-level preflight, leases, freshness checks, cancellation, and human-approval policies, while hardware safety limits and interlocks remain beneath model authority.Planners and plugins may add restrictions but cannot remove lower-layer restrictions; missing safety-critical state fails the action closed.Source: §4.10 · pp. 8–9

5 Implementation

The reference runtime implements a persistent state machine with adapters for robot, model, and simulator backends. The described deployment is single-host, and the provider interface also accommodates several other backend types.

5 Implementation

  • The Python reference runtime uses typed immutable contracts, SQLite-backed stores, and a state machine spanning planning, dispatch, verification, commitment, recovery, and original-goal verification.Persisted requests, execution handles, leases, and evidence support restart-oriented recovery under stated deduplication and cancellation assumptions.Source: §5 · p. 9
  • Adapters connect ROS 2, vendor SDKs, model services, and simulators, while the provider interface accommodates VLA, manipulation, TAMP, and world-model-assisted backends.The described quadruped warehouse workflow is built on the HROS field application [24].Source: §5 · p. 9
  • The reference deployment is single-host; multi-robot use requires transactional external leases and explicit clock and event-ordering contracts.Semantic-correctness measurement also requires independent adjudication when sensor or model errors are shared.Source: §5 · p. 9

6 Experimental Evaluation

The evaluation documents real quadruped tasks spanning warehouse inspection, exploration, navigation, and camera capture, and specifies protocols for assessing harness execution and RSI updates.

6.1 Experimental Setup and Robot Platform

  • The quadruped evaluation covers voice-to-action inspection, VLM-guided exploration, semantic place binding, and navigation completion in an office and entrance environment.Mission identifiers connect commands, sensor observations, action results, and communication receipts.Source: §6.1 · p. 9

6.2 Voice-Triggered Warehouse Inspection

  • The warehouse mission links voice input, navigation, panoramic inspection, visual analysis, acknowledged message delivery, return, and spoken reporting in one 259.94 s execution.The full voice turn, including input acquisition and overhead, takes 271.22 s; mission identifiers, timestamps, and checksums link the stages.Source: §6.2 · pp. 9–11

6.3 Exploration with VLM + omni planner

  • The exploration workflow assigns semantic goal selection to the VLM, local motion generation to the omni planner, and map updates to SLAM under harness supervision.The field result renders a saved point cloud with the recorded SLAM trajectory aligned by recorded transforms.Source: Figure 3 · p. 11, §6.3 · p. 12

6.4 Site Map and Semantic Anchors

  • The site map binds office storage to endpoint B and departure/return to endpoint A, adding configured mission semantics to recorded geometry.The field map shows the full saved site extent and enlarged task area.Source: §6.4 · p. 12, Figure 4 · p. 12

6.5 Navigation Results

  • Both warehouse round-trip segments reach their endpoints and stop publishing velocity commands; the return trace includes limited progress during logged collision-candidate rejection and replanning.Arrival and last-pose distances are distinct endpoint measurements taken at different sampling times, not path-tracking error or external ground-truth accuracy.Source: §6.5 · p. 13, Table 2 · p. 13, Figure 5 · p. 13

6.6 Closed-Route Completion Case

  • The circuit starts approximately 0.23 m from its goal, then traverses as far as 6.20 m away and returns, demonstrating completion cannot rely on endpoint proximity alone.The planner reports 99.6% reference progress and 0.068 m remaining at its completion event; the supervisor records departure and return.Source: §6.6 · p. 14

6.7 Supplementary Text-Driven Camera Task

  • A separate text-driven camera task records a Qwen-Plus plan to capture, persist evidence, and describe an image, with all nodes succeeding without motion commands.The nodes share the image checksum.Source: §6.7 · p. 14

6.8 Harness and RSI Evaluation Protocol

  • The evaluation protocol separates execution checks from RSI checks, including evidence validity, completion decisions, candidate regressions, release decisions, and rollback.Controlled comparisons hold navigation provider and routes fixed; RSI comparisons hold model and skill provider fixed and use a held-out task set.Source: §6.8 · pp. 14–15

7 Related Work

Related work addresses embodied runtimes, guarded skill execution, planning, recovery, and harness revision. RegenHarness emphasizes cross-provider execution contracts governing evidence, task-state commitment, and recovery authority.

Agent loops and harnesses

  • RegenHarness separates runtime execution from cross-mission harness revision, binding candidate revisions to robot execution evidence, fixed checks, versioned release, and rollback.Self-Harness retains harness edits after regression tests [26].Source: §7 · p. 15

Guarded execution

  • EmbodiedSkills [23] and CommitFlow [27] address guarded execution, so verification-gated progression itself is not presented as RegenHarness’s new principle.RegenHarness emphasizes C1–C4 access boundaries, identity- and version-bound commit authority, duplicate-dispatch control, resource ownership, and durable recovery accounting.Source: §7 · p. 15

Language-guided robot planning

  • Language-guided planners address skill selection, feedback, or action construction, while RegenHarness supervises provider execution and evidence acceptance.A planner’s valid proposal is not itself proof that the physical transition occurred.Source: §7 · p. 15

Failure diagnosis and recovery

  • Diagnosis and recovery methods complement RegenHarness’s C4 contract, which governs authorized recovery, budget consumption, and evidence required for subsequent acceptance.The deployment cases concern navigation and inspection, while LIBERO-RECOVER [14] benchmarks manipulation recovery.Source: §7 · pp. 15–16

Robot middleware and task execution

  • Robot middleware and low-level safety mechanisms complement RegenHarness, which governs evidence provenance, task-state acceptance, and recovery budgets above provider interfaces.ROS 2 [17], behavior trees, TAMP [7], and Physical AI harness work [13] address other layers.Source: §7 · p. 16

8 Conclusion

RegenHarness organizes long-horizon robot execution around explicit authority and evidence-bound state transitions. Its deployment cases illustrate integrated physical workflows and history-dependent completion, while its RSI loop governs harness revisions through checks, versioned release, and rollback.

8 Conclusion

  • Role-isolated contexts, supervised skill lifecycles, guarded commitment, and bounded recovery connect model proposals to accepted task progress under verifier and backend contracts.Source: §8 · p. 16
  • The warehouse mission demonstrates an integrated physical workflow, while the circuit exposes history-dependent completion.Source: §8 · p. 16
  • The RSI loop applies evidence-before-acceptance to harness revisions through regression checks, versioned release, and rollback.Source: §8 · p. 16

Related papers

Loading 2609.27612v1…