I wrote a piece about "agent harnesses" - both the "inner" harness (the coding agent / assistant), the "outer" harness (all the parts *you* bring to it), and the piece I feel is missing (and am building, free + open source). If you find this information helpful, please subscribe (link below).
>If the inner harness provides a set of core capabilities, the outer harness is everything you bring to it. Böckeler's framework breaks it into two categories: feedforward controls and feedback controls.
>Feedforward controls, or "guides", are everything that shapes behavior before the agent acts, with the goal of preventing mistakes before they happen. They come in several flavors:
>Guidance - CLAUDE.md files, architecture docs, coding conventions. Either auto-loaded by the agent or indexed so the agent reads them on demand when relevant.
>Skills - reusable procedures the agent activates based on their description matching the task.
>Specs - instructions the human explicitly tells the agent to read and follow. (I wrote about spec-driven development in Think Before You Prompt.)
>On the other side are feedback controls - post-action observers "optimised for LLM consumption." (She calls these "sensors.") Deterministic feedback comes from tools with fixed, repeatable outputs: linters, type checkers, test runners, build scripts. LLM-based feedback uses a second model to evaluate what the first model produced: code reviewers, spec-compliance checkers, evaluator agents - or the agent itself closing what Osmani calls the "self-verification loop" by observing its own output through a browser or screenshot tool.
>Deterministic feedback catches what rules can express; LLM-based feedback catches what only judgment can - architectural drift, spec misinterpretation, subtle regressions. Boris Cherny, creator of Claude Code, noted that giving the model a way to verify its work improves quality by 2–3×. The practitioner heuristic "hooks over prompts for reliability" is a statement about preferring feedback over feedforward - feedback doesn't depend on the agent's attention. My Agent Validator tool is a configurable feedback loop runner for both types - deterministic checks and LLM-based reviews.
>Two other pieces round out the outer harness: persistent memory and codebase preparation. Without cross-session recall, every conversation starts cold - the agent re-learns your codebase, your conventions, your past mistakes. And agents perform dramatically better on clean, well-structured code - the outer harness isn't only what you configure, it's also what you've already cleaned up.
>All four connect through the steering loop: "Whenever an issue happens multiple times, the [harness] should be improved to make the issue less probable to occur in the future, or even prevent it." When something goes wrong, you can improve a feedforward control (prevent it next time), add a feedback control (catch it next time), save it to memory (so the agent doesn't repeat it across sessions), or clean up the code that confused the agent in the first place - or some combination of the above.
>The human's job is the steering loop - channeling what goes wrong into better feedforward, feedback, memory, and code. I wrote about what the human actually does in issue #3.
>This is becoming one of the main functions of the human software engineering role - cultivating the harness.
Full link: https://codagent.beehiiv.com/p/harnesses-explained