Harness Engineering Still Needs Governance
The industry has moved from prompt engineering to harness engineering: execution systems that coordinate models, tools, memory, and retries across long-running agent loops. Harnesses solve how agents run. They do not solve what agents are allowed to produce.
That gap is the governance problem that harness engineering leaves open.
What harness engineering solves
A harness is the coordination layer between an LLM and the execution environment. It handles task decomposition, tool selection, retry logic, memory injection, context management, and output routing. Modern harness frameworks — LangGraph, AutoGen, CrewAI, Prefect, and company-specific implementations — have become sophisticated infrastructure in their own right.
Harness engineering solves real problems:
Execution continuity: Long-running tasks don't fail when context limits are reached
Tool coordination: Multiple agents and tools operate in sequence without manual orchestration
State management: Progress is preserved across sessions
Retry logic: Transient failures are handled automatically
Parallelism: Independent subtasks run concurrently
These are infrastructure problems, and harnesses solve them well.
The governance gap
What harnesses don't solve is what the agents are allowed to produce.
A harness can coordinate ten agents running in parallel across a complex feature implementation. It cannot ensure that none of those agents introduces a banned dependency, violates a service boundary, bypasses the approved authentication pattern, or generates code inconsistent with the architectural decisions your team has made.
Harness engineering and governance infrastructure operate on different surfaces:
Harness engineering controls: execution flow, tool availability, context injection, retry behavior, agent coordination, memory management.
Governance infrastructure controls: what constraints apply to what output, which architectural decisions are in force, how conflicting rules resolve, whether generated code is compliant before it is accepted.
A team can have excellent harness engineering and zero governance. The agents run reliably, coordinate well, and produce non-compliant output consistently.
Why observability is not sufficient
The natural response to this gap is observability: log what agents produce, trace which tools they called, alert when violations appear in output. This is valuable. It is not governance.
Observability tells you what happened. Governance shapes what is allowed to happen.
When an agent running in a ten-step autonomous loop violates an architectural constraint in step 6, observability surfaces the violation after the fact. The code may already be committed, the PR opened, or the downstream service affected. Governance would have prevented the violation from being generated in step 6.
The gap between detection and prevention compounds at scale. An agent producing 200 files per run that is observed to violate constraints 8% of the time produces 16 violations per run. An agent that is governed to prevent violations produces zero — without requiring a human to review 200 files looking for 16 problems.
Governance propagation across execution surfaces
Harness architectures introduce a specific governance challenge that single-agent sessions don't have: governance must propagate across all execution surfaces, not just the primary agent.
A typical multi-agent harness might include:
A planning agent that decomposes the task
Implementation agents that write code
A validation agent that checks output
A documentation agent that updates references
Tool calls to external services
Each of these surfaces can produce output. Governance must apply consistently across all of them. The constraint that says "use the repository pattern for all data access" applies whether the code is written by the implementation agent, the validation agent fixing something it found, or a sub-agent spawned to handle a subtask.
Governance propagation means: the same structured decision records, applied with the same precedence rules, enforced at the hook level across every output surface in the harness — not just the entry point.
Where governance fits in the harness stack
Governance is not an alternative to harness engineering. It is an additional layer that sits above the execution layer.
The harness controls how agents run. Governance controls what they're allowed to produce. Both are necessary. Neither replaces the other.
The practical implementation:
Decision records as durable constraints — Architectural decisions (ADRs) stored as structured, typed, scoped records with explicit precedence. Not documentation. Active constraints.
Pre-generation retrieval — Before each agent writes output, relevant constraints are retrieved based on the specific file, module, and operation being performed. Constraints are injected structurally, not as advisory text.
Hook-level enforcement — Generated output is validated against the applicable constraints before it is accepted. Violations are blocked or flagged, not discovered in review.
Propagation across agents — The same constraint set applies across all agents in the harness, including sub-agents and tool calls that produce output.
This is what Mneme provides for harness-based AI development. The harness handles coordination. Mneme handles what the coordinated agents are allowed to produce.
Harness engineering is necessary infrastructure. It is not sufficient infrastructure. The governance gap it leaves open gets larger, not smaller, as harnesses become more capable and autonomous.
Originally published at mnemehq.com