Building an AI Model Isn't the Solution — It's Just the Beginning

Harness Engineering in 2026: From Prompt Tricks to Programmable Control Plans

Harness engineering is no longer a buzzword; it is the new discipline underpinning reliable, large‑scale AI systems. After a brief flirtation with prompt engineering (“what magical incantation unlocks the model?”) and context engineering (“how do I fill the context window?”), practitioners have realized the real work happens in the control plane that wraps around a model. That plane is the harness. This article synthesises recent research, industry case studies and design patterns to show what harness engineering really means, why multi‑agent orchestration is hard, and how to build safe systems in regulated domains like mortgages, operations  and various areas. Along the way we address common criticisms—shallow definitions, hand‑wavy case studies, weak security coverage—and fill gaps on token economics, state consistency and evaluation methodologies.

A Clear Definition

Harness engineering is the design of deterministic, programmable control structures that constrain, observe, verify and recover the behavior of autonomous agents—independent of the underlying model. In other words, a harness is the explicit program that decides what context an agent sees, which tools it may call, when it must seek approval, how its output is validated and how state persists between turns. Martin Fowler loosely described the harness as “everything in the agent minus the model”, but that can be confusing because a harness and a model often work as one. Recent surveys emphasize that the harness enforces safety properties (preventing harmful actions) and liveness properties (ensuring the agent eventually completes its task). You can change your model without changing your harness; you can even swap in a new model with better reasoning and your harness will continue to orchestrate, validate and recover just as before.

Harness, Scaffold, Framework or Infrastructure?

Terminology matters when designing critical systems. A harness is a persistent, programmable control layer that spans the entire lifecycle of an agent: planning, tool selection, execution, verification, memory management and error recovery. A scaffold is a temporary skeleton used to bootstrap or test an agent; once the agent is ready, the scaffold is removed. A framework is a reusable collection of components—such as LangChain or Crewai—that helps build harnesses but does not provide a harness itself. Infrastructure refers to the durable runtime environment (databases, vector stores, secret managers, CI/CD pipelines) on which harnesses run. Confusing these terms leads to unrealistic expectations; a scaffold cannot replace a harness, and a framework cannot offer the guarantees of well‑engineered infrastructure.

Why Harnesses Exist

Large language models are brilliant pattern matchers but poor software engineers. They forget what they wrote, hallucinate plausible‑sounding nonsense and over‑fit to training patterns. Real systems demand more than glimpses of intelligence:

• Memory resets and context rot. Without an explicit state manager, agents forget past steps and repeat work. Claude Code solves this by storing three separate memory channels: one for primary outputs, one for a progress journal and one for an event log.
• Confident mistakes and hallucinations. Agents will assert correct‑looking but wrong answers unless their outputs are mechanically verified.
• Tool misuse and side effects. Unrestricted tool access can trigger destructive commands, leak secrets or break systems; harnesses restrict tool scopes and enforce approval.
• Error cascades in multi‑agent systems. Independent agents amplify errors by 17.2× relative to single‑agent baselines, while centralized orchestrators reduce this amplification to 4.4×. Without validation boundaries between agent stages, mistakes propagate unchecked.
• State inconsistency. Agents editing shared state concurrently can corrupt data. Modern harnesses use typed state schemas and checkpoints to ensure consistency.
• Unbounded costs and latency. Multi‑agent pipelines can burn $5–8 per task and take 10–30 seconds for a single request. A harness must control loops, prune context and optimise calls to keep budgets sane.

Harness engineering emerged to solve these systemic issues. It is not a fad; as research shows, improvements in harness design often yield bigger performance gains than switching models. Indeed, some teams report that harness‑level improvements produce more reliable agents than upgrading from GPT‑4 to GPT‑4 Turbo.

Fundamental Components of a Harness

While no two harnesses are identical, most include the following deterministic components:

Component	Purpose	Example	Sources
Intent capture & issue framing	Converts a user’s high‑level goal into a structured, bounded task specification. This includes clarifying questions, aligning on constraints and deciding whether to proceed autonomously.	Claude Code’s planner agents request clarifications before acting and save plans to disk for reuse.	[Anthropic]
Tool registry & scope	Defines which tools are available, what arguments they accept, and which safety policies govern them. Tools may include file editors, search, code interpreters, and API clients.	LangChain exposes tools to the agent as typed functions and hides unused tools to reduce cognitive load.	[LangChain]
Context & memory management	Determines how past actions, messages and knowledge are stored, retrieved and summarized. This includes pruning old context, using structured notes and limiting context length.	Claude Code maintains long‑term knowledge in index/ and topic/ files and uses a raw transcript for reproducibility.	[Anthropic]
Prompt construction & instructions	Builds the final message sent to the model, including system prompts, tool schemas, memory files and user input.	Cursor’s .cursor/rules files provide static context (like coding standards), while dynamic prompts assemble current context and user intent.	[Cursor]
Execution loop & planning	Implements the Thought–Action–Observation cycle. Some harnesses interleave reasoning and action (ReAct); others separate planning and execution for speed.	OpenAI’s SDK uses a REPL‑like loop; LangGraph models execution as a graph of states and actions.	[OpenAI]
Verification & feedback loops	Determines whether outputs meet constraints. Includes deterministic checks (unit tests, linters, type checkers) and inferential checks (LLM judges).	LangChain’s build–verify loops run tests and diff results; Anthropic’s evaluator agent scores outputs separately from the generator.	[LangChain]
Error recovery & retries	Categorizes errors and defines retry policies, fallback strategies or human escalations. Given even 99 % step reliability, a 10‑step workflow has a 10 % failure rate.	Harnesses implement loop detection to prevent infinite recursion and require human approval for high‑risk retries.	[LangChain]
Guardrails & permissions	Enforces hard rules (e.g., no network access, no deletion) and triggers human review for sensitive operations.	OpenAI’s agent harness uses custom linters to ban dangerous code patterns; Anthropic’s PermissionBridge requires explicit confirmation before executing commands.	[Epsilla]
Observability & audit logging	Captures structured logs, metrics and traces; stores run history and user feedback for monitoring and compliance.	Google’s Galileo framework proposes evaluating trajectory metrics (agent reasoning steps) and outcome metrics (final results) for continuous monitoring.	[Galileo]
Subagent orchestration	Enables nested agents, dynamic delegation and failure isolation; each subagent runs in its own context with explicit handoff protocols.	AutoGen uses structured message schemas to ensure subagents pass only allowed data.	[AutoGen]

Each component addresses a specific failure mode. Missing or weak components lead to brittle behaviour; for example, weak context management causes context bloat and memory rot, while insufficient guardrails allow prompt injection and secret leakage.

Deep Dive: Multi‑Agent Orchestration

Trust Propagation and Cross‑Agent Validation

In multi‑agent systems, trust does not propagate automatically. If Agent A produces a plan, Agent B should not blindly accept it; there must be a validation step. Research from DeepMind and colleagues shows that independent agents amplify errors by orders of magnitude compared to single‑agent baselines. The study recommends inserting validation boundaries between agents, where deterministic checks (tests, type validations) ensure the output conforms to specifications before it is consumed. Claude Code implements this by having a reviewer agent verify code before merging, and by storing progress journals that allow independent auditors to reconstruct reasoning. Structured message schemas (e.g., JSON or Pydantic models) enforce contracts so that one agent cannot smuggle arbitrary data into another.

Guardrails at Agent Boundaries

Guardrails live at every interaction boundary, not just at the orchestrator. Each agent must check inputs, validate outputs and restrict tool usage. The PermissionBridge in SemaClaw attaches policies to each tool call and requires explicit approval for high‑risk actions like file deletion or external API access. The modern agent harness blueprint recommends dividing the system into trust zones: low‑trust model context, medium‑trust execution zone and high‑trust operator zone. Data and control signals can only flow from lower zones to higher zones through explicit approvals; this prevents prompt injection in retrieved documents from automatically triggering high‑privilege operations.

Failure Isolation and Blast Radius

When one agent fails, it should not collapse the entire graph. Two techniques help:

1. Context isolation. Each agent operates on its own context window; subagents cannot directly modify the parent’s state. AutoGen, for example, spawns a new context for each subtask and passes only the minimal structured result back. Claude Code uses worktrees to isolate edits so a crashing agent cannot corrupt the main branch.
2. Typed state and checkpoints. LangGraph models the entire workflow state as a typed dictionary. Checkpoints after planning, mid‑execution and pre‑action allow recovery if a later agent fails. When a subagent fails, the orchestrator can roll back to the last checkpoint and delegate the task to another agent rather than continuing with potentially corrupted state.

Conflict Resolution

Agents will sometimes disagree—two summary agents may produce conflicting valuations. Conflict resolution strategies include:

• Deterministic arbitration. Use deterministic rules such as majority voting, highest confidence score or a pre-defined authority hierarchy. In telecom RF optimization, a coverage agent and an interference agent might produce different network tuning recommendations; a separate RF arbiter agent can apply operator-defined rules and combine them deterministically, logging the rationale, applied weights, KPI thresholds, and final parameter decisions for NOC teams and audit traceability.
• Meta‑agents or consensus mechanisms. Introduce a higher‑level agent to compare outputs, request clarifications and decide. The CHI paper on task‑aware delegation proposes dynamic delegation cues—uncertainty thresholds trigger a high‑assurance mode where additional agents (or humans) adjudicate differences. In subsurface gas injection optimization, a reservoir simulation agent may recommend increasing injection rates to improve recovery, while a geomechanics agent warns of fracture risk due to rising pressure; a higher-level arbiter agent evaluates uncertainty thresholds, triggers additional simulations or expert review, and resolves the decision using predefined safety and reservoir constraints.
• Human injection points. When conflicting outputs exceed a risk threshold (e.g., high mortgage rejection risk), the harness pauses and requires a human decision. The human’s decision and rationale become part of the audit log for compliance. When conflicting outputs exceed a risk threshold (e.g., high mortgage rejection risk), the harness pauses and requires a human decision. The human’s decision and rationale become part of the audit log for compliance.

Agent Boundaries in Regulated Domains

In domains like mortgages and loans, regulatory compliance requires fine‑grained control at agent boundaries:

• Prompt injection across turns. Malicious documents or websites can instruct the agent to make biased decisions. The Agent Harness Survey shows that prompt injection in retrieved tool content leads to harmful outcomes if not sanitized. A harness should treat all external content as untrusted, separate raw from summarized content, and apply LLM‑based or rule‑based filters before it enters the model context.
• Data leakage between agents. In use cases of precision agriculture , Sensitive farm financial data must never be visible to agronomic or yield optimization agents. Use separate contexts and a data broker that redacts or abstracts sensitive fields unless absolutely necessary. Capability-based access control ensures that each agent can only access domain-specific inputs (e.g., soil, weather, crop health) and cannot read or write outside its permitted scope, preventing unintended exposure of farmer financial or personal information.
• Audit trails and explainability. Mortgage lenders must comply with ECOA, FCRA, GDPR and the EU AI Act. Harnesses must log every decision, record the data sources used, keep evidence of model outputs and allow reproduction of results. Google’s Galileo evaluation framework emphasises capturing trajectory metrics (intermediate reasoning) and outcome metrics (final decisions), which is essential for regulatory audits.
• Agent impersonation. Agents must authenticate when making requests or delegating tasks. A harness can issue cryptographically signed tokens for each agent and require signature verification before accepting a message, preventing one agent from impersonating another in complex graphs.

Analysis of Case Studies

OpenAI’s “One Million Lines” Codex Experiment

OpenAI’s 2026 post describes how a small team built a production application with ~1 million lines of code using Codex agents. While the number is impressive, critical analysis raises questions:

1. Does more code mean better code? Without measuring quality (bug rate, maintainability, security), a high line count may simply reflect verbose or redundant output. The harness enforced mechanical rules (custom linters, test generation), but the post does not report metrics like defects or performance. Rigorous evaluation frameworks such as cost per successful task or trajectory vs. outcome metrics are needed to gauge efficiency.
2. What was the failure rate? The post does not disclose how often the harness had to roll back or how many human interventions were required. A harness should track and report end‑to‑end success rates and mean time to recovery.
3. Is Terminal Bench representative? The experiment relied on Terminal Bench 2.0, a synthetic benchmark. While LangChain demonstrated a 13.7 percentage point improvement after harness tweaks, we need real‑world workload benchmarks (e.g., WebArena, AgentEval) to validate generalisability.

Despite these criticisms, the experiment underscores how harness design—planning, verification, permission control—makes large‑scale code generation feasible. It is a proof of concept, not a final word on agent productivity.

Anthropic’s Three‑Agent Architecture

Anthropic introduced a Planner–Generator–Evaluator architecture inspired by GANs. The Planner breaks down tasks, the Generator writes code and the Evaluator scores the result. Context resets prevent anxiety when the Generator runs long tasks. The experiment measured the cost difference between solo runs and harness runs: a solo run on Claude 2 cost roughly $0.37, whereas the harness run cost $0.48 due to the additional evaluation steps. The authors argue the extra cost is justified by higher reliability—reporting 97 % success on simple tasks—yet they acknowledge that high‑level tasks still require human review. The takeaway is that multi‑agent harnesses trade off cost and latency for reliability; you must tune the thickness of the harness to match the stakes of your domain.

Cursor’s Harness and Rule Files

Cursor’s developer environment uses a harness with three components: instructions, tools and model. .cursor/rules files provide static context—coding standards, patterns to avoid, and secrets redactions. Agents operate in Plan Mode, gathering requirements and producing an implementation plan before writing code. Cursor emphasises deterministic hooks (e.g., a linter that prevents test deletion) and skills (auto‑loaded domain knowledge). While Cursor does not publish benchmark scores, its harness design aligns with our fundamental components, focusing on rule‑based safety and reproducibility.

LangChain and Terminal Bench

LangChain’s team improved a coding agent’s Terminal Bench 2.0 score from 52.8 % to 66.5 % by adding a build–verify loop and loop‑detection middleware. They also introduced interactive debugging tools and instrumentation. However, Terminal Bench is synthetic and may not reflect real‑world tasks. Without evaluating cost per success and user experience, the improvement could hide trade‑offs: runtime increased by ~40 % and API costs grew proportionally. This case illustrates that harness improvements have diminishing returns; adding more loops and checks eventually increases latency and cost to unacceptable levels. Choose harness thickness based on domain requirements and budget.

Economics, Latency and State Consistency

Token Economics and Cost Per Success

Operational costs are often hidden behind per‑token pricing. Cost per Successful Task (CPST) is a better metric:

. Run cost includes API inference, GPU compute, vector store queries and tool calls; human cost covers review and escalation; overhead includes compliance and monitoring systems; and build cost covers initial harness development. Studies show that API token pricing is only 20–40 % of total cost. Build robust harnesses early—even at the expense of longer development time—because compliance controls (HIPAA, SOC 2, model risk documentation) must be included in budgets.

Latency vs. Reliability

A single LLM call may take ~0.8 seconds, but multi‑agent flows with verification loops can take 10–30 seconds. Users will not wait this long for a simple answer. Strategies to reduce latency include prompt caching, dynamic turn limits, tiered retrieval (starting with cheap context and escalating to expensive retrieval only when needed) and agentic RAG (retrieving documents after reasoning about what’s missing). Harnesses should degrade gracefully: for quick, low‑risk tasks, use thin harnesses; for mission‑critical tasks, invest in thicker harnesses and inform users about expected delays.

State Consistency and Concurrency

Agents often operate concurrently on shared state. Without explicit coordination, parallel edits can clobber each other or introduce race conditions. LangGraph solves this by treating state as a typed object and requiring atomic updates at checkpoints. Luminity Digital recommends context pruning (removing irrelevant history), checkpoint/state validation (ensuring data adheres to a schema), structured output contracts and bounded task decomposition (decomposing tasks only to a depth where state remains consistent). In regulated domains, use event sourcing or append‑only logs so that all mutations are auditable and reversible.

Evaluation Methodologies

Evaluation is more than unit tests. Galileo’s 2026 report proposes measuring trajectory metrics (accuracy of intermediate reasoning, adherence to plans) and outcome metrics (task completion, user satisfaction). The report distinguishes pre‑deployment testing (benchmarks like AgentBench, SWE‑bench Verified, WebArena) and continuous production monitoring (real‑time tracing and anomaly detection). LLM‑as‑Judge evaluation should be calibrated to align with human judgement (Spearman ≥ 0.80). The agent harness survey warns that environment drift and task ambiguity cause evaluation to be unreliable and emphasises the need for protocol standardisation and compute economics analysis. In sum, evaluate harnesses like any other critical system: write tests, run benchmarks, measure latency and cost, and monitor in production.

Security and Compliance

Security cannot be an afterthought—especially in domains handling financial or medical data.Here we lay out a more comprehensive approach:

1. Threat modelling and trust zones. Segment the harness into zones (model context, execution, operator) and assign policies to each. Only allow data and control to flow up the trust hierarchy through explicit approvals; block downward flow that would leak secrets. Taint tracking can mark data sources and prevent mixing sensitive and non‑sensitive data.
2. Context poisoning defense. Treat all tool outputs and retrieved documents as untrusted. Use sanitisation (strip markup, remove hidden instructions), summarisation (extract facts without instructions) and adversarial filtering. Research shows that prompt injection into tools leads to harmful outcomes if not neutralized.
3. Secret management. Never expose secrets to the model context without policy checks. The blueprint recommends a secret manager that requires user confirmation before releasing tokens. For mortgage applications, store API keys and credit reports in a high‑trust zone accessible only via signed requests.
4. Audit trails and provenance. Log every action with timestamps, inputs, outputs, tool invocations and human interventions. Use a knowledge system built on typed ontologies with provenance and trust tracing. Regulators can then reconstruct decision chains and verify compliance with laws like ECOA and FCRA.
5. Capability‑based access and domain isolation. Grant each agent the minimum capabilities required to fulfil its task. Use separate contexts and data partitions for different domains (e.g., credit, property valuation, fraud detection) and restrict cross‑domain calls. Tools must check capability tokens before executing sensitive operations.
6. Differential privacy and fairness auditing. Evaluate your harness for disparate impact using test harnesses and fairness rubrics. Record model inferences to support bias testing and explainability.

Following these practices turns the harness into a defence‑in‑depth system that satisfies regulators and protects users.

Future Directions and Open Questions

Harness engineering is maturing, but many open challenges remain:

• Standardization and interoperability. Current harness frameworks are bespoke and lack standard protocols. The agent harness survey calls for protocol standards and shared libraries to reduce fragmentation. Expect open standards for agent handoffs, trace schemas and capability tokens.
• Automated harness synthesis. Could we automatically generate harness code given high‑level specifications? Research into program synthesis and formal verification may enable harness compilers that guarantee safety properties by construction.
• Co‑design with models. As models become more capable, harnesses might become thinner. Conversely, harness constraints could inform model training by rewarding compliance with rules and penalising context manipulation.
• Economic optimisation. Balancing latency, cost and reliability is a multi‑objective optimisation problem. Future harnesses will likely use reinforcement learning or adaptive heuristics to adjust thickness in real time, based on user tolerance for latency and risk.
• Socio‑technical impact. Harness engineering touches ethics, law and labour. How do we ensure harnesses respect worker consent, avoid algorithmic discrimination and align with human values?

Conclusion: Harnesses as the Control Plane, Not the Factory

Harness engineering is the control plane that orchestrates, constrains and recovers AI agents. It is not just scaffolding, but neither is it the entire factory. Without proper harnesses, agents collapse under their own complexity; with them, models become reliable co‑workers. Recent research shows that multi‑agent orchestration, dynamic delegation and rigorous evaluation frameworks can improve performance, but they also introduce cost and latency trade‑offs. Security and compliance require deep integration into the harness, especially in regulated domains like mortgages.

Perhaps the most important lesson is that the harness is not a magic shield. It does not remove the need for careful model selection, prompt design, human oversight or domain expertise. It does, however, provide the deterministic backbone that turns unpredictable LLM outputs into predictable, accountable workflows. As the AI community moves beyond model hype, investing in robust harnesses—and standardising how we build and evaluate them—will be the key to safe and effective AI.

References 

• Martin Fowler – AI Agents & Harnesses
• Anthropic (2026) – Harness Design for Long-Running Applications
• OpenAI (2026) – Codex Agent System Case Study
• Cursor – Rules, Skills & Agent Harness Design
• LangChain (2026) – Deep Agents & Terminal Bench 2.0
• Microsoft Azure – AI Agent Design Patterns
• Dapr – Multi-Agent Orchestration Patterns
• Google Research (Kim & Liu, 2026, via Atlan) – Multi-Agent Error Amplification (17.2× vs 4.4×)
• Gu et al. (2026) – Task-Aware Delegation in Human-Agent Collaboration (CHI)
• SemaClaw (2026) – General-Purpose Multi-Agent Framework (arXiv)
• OWASP – LLM Top 10 Risks (Prompt Injection, Data Leakage)
• Simon Willison – Rule of Two for AI Safety
• European Union – EU AI Act (2026)
• US Federal Trade Commission – ECOA / FCRA Guidelines
• Confident AI & Google Cloud (Galileo, 2026) – Agent Evaluation Frameworks
• Latent Space (2026) – Extreme Harness Engineering & Cost Models