Part 5 of the "Agent Influence" series. Previous | Series start
I used to think LLMs would remember everything in their context and execute accordingly. Then I watched them forget, selectively lose track, hallucinate in long tasks, and sometimes just make things up to get through. That's when I started building what I didn't yet have a name for.
This week I read a DEV Community post titled "What is an 'agentic harness,' actually?" The post itself was brief. But one comment gave me a better way to name what I had been building:
"My version of that surviving layer is a set of standing rules and hooks the agents inherit every session — the stuff that stays true after the conversation is gone."
That quote is from FromZeroToShip. It described something I'd been building for months - a personal agent governance system with standing rules injected every session, a correction memory that outlives any single conversation, and verification scripts I require after the agent reports completion. The title of this article is my own shorthand for that surviving layer.
The prompt is the smallest part of it
Most agent setup guides focus on prompt engineering. Write better instructions. Add examples. Use XML tags. These are useful, but they're all prompt work - and the prompt is the part that evaporates when the context window resets.
A harness is different. It's the structure that rebuilds the agent's discipline from files every session. It exists as files the agent reads but, in my current workflow, doesn't modify. On the paths it covers, it makes decisions outside the agent's own reasoning - like whether "done" is acceptable, or whether the loop should continue.
If you use Claude Code, Codex CLI, or opencode, you already have a harness - those tools provide the execution layer: tool schemas, context management, and permission controls. They answer "what is the agent allowed to do?"
But execution-layer harnesses don't answer a different question: "did the agent actually do what it claimed, and did it learn from the mistake?" That's the governance layer - rules audited for effectiveness, corrections that persist across sessions, completion checks that don't ask the model to grade itself. Tools provide control primitives, but they don't automatically form your project-specific rule audit, correction memory, and completion evidence loop. You build that.
In my current setup, these checks are process requirements rather than a separately enforced execution boundary.
The separation matters. As another commenter, CAI, put it: "The loop decides what to do next. The harness decides whether that actually happened."
To put it another way: if the same system that produces the work also decides whether the work is done, you have an auditor inside the accounting department - the numbers look fine because the same hands wrote them.
Two halves: sensors and guides
I used to think rules alone would fix my agent. In my article about why adding more rules makes your agent dumber, I argued against adding rules without cleanup. But I was only seeing half the problem. Rules alone are not enough for reliable control. I had 268 rules telling the agent what to do. Zero scripts checking whether they actually worked. The agent kept making the same mistake, reading the rule, nodding, and making it again next session.
A commenter named Viktor split the harness into two halves: sensors (feedback - tests, linters, done-checks) and guides (feedforward - rules the agent reads before acting). Build only sensors and your agent catches mistakes but never learns to avoid them. Build only guides and you never find out whether your rules actually work. In a robust design, the two halves should not share the same authority.
In my setup, guides live in instruction files the agent reads - "when X happens, do Y." Sensors are scripts I require after the agent reports completion - "did the expected file actually change?" A guide that the same agent also checks is a rule grading its own homework.
This framework isn't unique to my setup. A writer named jugeni made a parallel distinction: content (knowledge packed as steps) and control (evidence discipline packed as gates).
Done-check must be independent
The sensors half of your harness has one job that matters more than any other: deciding whether the agent's work is actually done. Here's where the data gets uncomfortable. In my previous article, I measured evidence types in my system over several months of operation: 68% of all evidence entries were self-reported by the agent. That self-reported tier produced zero independently confirmed failure findings - meaning zero cases where the agent's own report surfaced a compliance failure that independent sources also confirmed.
Independent sources generated 182 violation signals in the reviewed evidence records. Of those, 5 were confirmed as real violations under a stricter definition. All 182 signals - and all 5 confirmed violations - came from independent sources, not from the agent's self-reporting.
A commenter on the same post, Edu Peralta, put it precisely:
"A harness that treats 'done' as the model's own opinion inherits every blind spot of that model."
I observed a pattern worth examining. Multiple voices spoke up - two articles, one commenter on the post above, and my own N=1 data:
| Source | What they said |
|---|---|
| nexuslabzen | Called the agent an "unreliable narrator" |
| jugeni | "Honest evidence that inherits the blindness of the thing it checks" |
| Edu Peralta | "A harness that treats 'done' as the model's own opinion inherits every blind spot of that model" |
| My own system | 68% self-reported, 0 verified failures |
Seeing this pattern was both validating and surprising. These are not independent samples - two articles, one commenter, my own data - but the pattern is worth examining: a done-check that asks the model whether it's done is not, by itself, an independent done-check. It's the model evaluating its own output.
The fix isn't a smarter rubric - it's a mechanism that doesn't share the claim's blind spots. An exit code. A git diff. A file existence check. For deterministic claims - did the file change, did the test pass - checks that don't depend on LLM judgment are harder to game than checks that do, because an exit code doesn't read the narration.
The loop needs an exit that isn't success
The sensors/guides framework answers "how does the harness check work." It doesn't answer a second question: what happens when the agent can't do the task?
FromZeroToShip described the consequence sharply: "A loop with no honest exit doesn't fail, it wanders, and a wandering agent is more expensive than a failing one."
I've seen this in my own system. I run a review loop where a sub-agent reviews the main agent's work. Last week, it ran 6 rounds on a code refactoring task - each round producing smaller findings. By round 5, the findings were cosmetic - but the loop had no way to say "good enough." I killed it manually. The agent didn't fail. It wandered. Without an honest failure exit, the loop produces "done" because that's the only available stopping condition - the agent generates the only output that stops the cycle.
The fix is in the design: a bounded retry budget that ends in an explicit failed state, with no penalty for honest quitting. "I could not do this, here's why" has to be a valid outcome. Without it, in FromZeroToShip's words, confidence becomes completion, and the loop wanders.
What my harness looks like
My harness has three components, none of which live in the prompt:
Standing rules. A file injected at the start of every session. It defines checkpoints, forbidden actions, and mandatory verification steps. The agent reads it; in my current workflow, it doesn't modify it.
Correction memory. A tiered system (detailed in my error notebook article) that persists across sessions. When the agent makes a mistake, the correction is extracted into a rule. Next session, the rule is already there. The agent doesn't need to be reminded - the harness injects it.
Verification scripts. Programs I require after the agent reports completion. Did the expected file change? Did the test suite pass? Did the checkpoint actually run? They emit exit codes when run. In my current setup, that requirement is a process constraint, not a separately enforced execution boundary.
Together, these components rebuild the agent's discipline every session. The agent starts fresh. The harness doesn't.
Two gaps remain: claim gating (the agent can say "check passed" without running the check) and honest failure exit (not wired into every path yet). The harness isn't finished. But the structure is what makes it reliable enough to work with daily.
What you can do today
You don't need to build a three-component harness. You need one deterministic check that survives context resets.
Here's a script that inventories whether your agent setup has harness files at all:
#!/usr/bin/env python3
"""Harness Inventory - lists candidate harness files in your project.
Note: this only checks file existence. It does not verify loading,
execution, permissions, or independence from the agent's write path."""
import os
def check_standing_rules():
candidates = ["CLAUDE.md", "AGENTS.md", ".cursorrules",
"copilot-instructions.md", ".github/copilot-instructions.md"]
return [f for f in candidates if os.path.exists(f)]
def check_correction_memory():
candidates = ["ERRORS.md", "LESSONS.md", "RULES.md",
".agent/rules.md", "docs/lessons.md"]
return [f for f in candidates if os.path.exists(f)]
def check_verification_script():
candidates = ["verify.sh", "check.sh", "scripts/verify.py",
"scripts/check.py", "Makefile"]
return [f for f in candidates if os.path.exists(f)]
checks = [
("standing rules (survive context reset)", check_standing_rules),
("correction memory (survive context reset)", check_correction_memory),
("candidate verification file", check_verification_script),
]
print("Agent Harness Inventory")
print("=" * 60)
for name, check in checks:
found = check()
status = "FOUND" if found else "MISSING"
detail = ", ".join(found) if found else "(no candidate file found)"
print(f" [{status:12}] {name}: {detail}")
print("=" * 60)
print("Lists candidate files only. Does not verify loading, execution, or independence.")
Add your own checks for CI config or protected branches. Start by creating a standing rules file - CLAUDE.md, AGENTS.md, or whatever your agent tool loads at startup. The 30-minute action: pick one thing your agent claims to do every session. Write a script that checks whether it actually happened. Run it after the agent says "done." That script - not the prompt - is the start of your harness.
The harness is everything that survives when the context forgets. The prompt is the smallest part of it. I started with one script that checked whether the agent actually did what it claimed. That was the first line of my harness. If you set up one today, that's the first line of yours.
Behind the Scenes: How This Article Was Governed
This article argues that self-report catches zero real violations. The writing process produced eight review rounds and a documented correction trail — all caught outside the draft's own self-assessment.
| What the agent wrote | Who caught it | What it became |
|---|---|---|
| "Charles Solar" as a commenter | Independent review: no such user exists | Attribution removed |
| "30 rules" | Tech blogger review: conflicts with #03's 268 | "268 rules" |
| "opencode has no permission gates" | Human review: opencode has allow/ask/deny | Dropped product comparison |
| CAI comment permalink | Preflight script: author mismatch at source | Corrected permalink |
The agent's self-assessment caught zero of these. Every issue was found by an independent source.
This is an N=1 experience report from building EQ OS, a personal agent governance system. All cited data (68% self-reported, 0 verified failures, 182 violation signals, 5 confirmed violations) was produced by deterministic queries over the evidence database across several months of operation, not manual estimation. The harness described here is a research system, not a shipping product. The "independence" described is currently process constraint, not enforced permission isolation. Articles cited were published July 2026 on DEV Community.
Top comments (1)
This framing is exactly right. The harness is the durable part of an agent system because context will always be temporary. Tests, fixtures, and checks are what keep lessons from disappearing between runs.