Why State Boundaries and Failure Loops Are Crucial for Agent Reliability After Harness

Recent Agent Harness Engineering surveys present a seven‑layer model—Execution, Tooling, Context, Lifecycle, Observability, Verification, Governance—that treats the surrounding execution environment as an independent system layer. While the component list is useful, true reliability emerges only when these layers form a runtime loop that keeps state clear, evidence traceable, and failures recoverable.

State Boundaries and Failure Loops

When agents run long tasks, the problem shifts from "does the model answer correctly?" to "can the system manage state, block erroneous commits, and understand failure trajectories?" The author emphasizes that many failures arise because candidate actions, validated actions, and committed states are not distinguished, leading to external damage.

Google DeepMind’s AutoHarness paper illustrates this: illegal actions in a game are blocked only if an external mechanism validates them before execution. In production systems, a model’s suggestion to delete records is merely a candidate; only after permission checks, dry‑run verification, and audit does it become a committed change.

Candidate Output : model proposes an idea or action; requires prompt, context, and task goal.

Validated Action : external rules confirm feasibility; requires validator, permission, tests, dry‑run.

Executed Action : tool produces side effects; requires sandbox, audit, logging, cost tracking.

Committed State : external system is permanently changed; requires checkpoint, rollback, human confirmation, evidence archiving.

Runtime Contract

Before an agent starts, the runtime contract must define:

Goal of the task

Stopping condition

Source of inputs

Who consumes the outputs

Systems that can read the results

Actions that are allowed to write

Which actions need human confirmation

Evidence left by the previous round

This contract mirrors the TERMINATION template used in earlier Cowork discussions and clarifies task boundaries without stifling creativity.

Submission Gate

Agent outputs must pass through different gates based on their state:

Draft – freely editable.

Candidate conclusion – requires source and validation.

Tool action – may have side effects; needs permission.

Committed state – must have audit and rollback mechanisms.

Long‑term memory – influences future tasks; must be used conservatively.

Failure Feedback Loop

When an agent errs, the error should be written back to the appropriate artifact:

Project spec ( AGENTS.md) for missing requirements.

Skill or runbook for unstable steps.

Hook or stop‑check for missed tests.

Permission or PreToolUse for dangerous commands.

Test, lint, or review checklist for unclear evaluation criteria.

Human‑run process if the workflow itself is too loose.

Each recurring error should be classified as a prompt issue, state issue, permission issue, validation issue, or process issue, guiding where the fix belongs.

Three Divergences in Harness Discussions

1. Model vs. Harness Size : Stronger models may absorb thin harnesses, but external state and responsibility boundaries remain essential.

2. Tool‑Specific Differences : The same model behaves differently across CLIs, frameworks, or runtimes; therefore, runtime contracts should avoid being tied to a single tool.

3. Specification Gaps : Many agent failures stem from under‑specified tasks; harnesses can surface missing specs but cannot invent them.

Practical First Steps

Start with low‑risk, well‑defined processes and iterate:

Weekly fixed‑site competitor scans.

First‑round PR read‑only reviews.

Document source archiving.

Pre‑release smoke checklist.

Public account material ledger.

Run a few cycles where the agent only reads and organizes data, leaving evidence of failures for human review. Once inputs, outputs, failure handling, and permissions stabilize, introduce automation and scheduling.

Conclusion

Harness Engineering clarifies that agent reliability now hinges on managing the execution environment, tools, context, lifecycle, observability, verification, and governance as a cohesive engineering object. State boundaries, evidence trails, and failure‑recovery loops are the core mechanisms that keep agents trustworthy as they integrate into real‑world development, operations, and business workflows.