Harness Engineering
Harness engineering is the practice of building the system around a model so that a mistake it makes once never happens again - not by retraining the model, but by changing what surrounds it. The term is credited to Mitchell Hashimoto (co-founder of HashiCorp, creator of Terraform), who framed it in a February 2026 post as the third phase of AI engineering maturity, following prompt engineering and context engineering.
The Core Idea
"Anytime an agent makes a mistake, you take the time to engineer a solution so that the agent never makes that mistake again." The model's weights do not change - the harness around it does. That is the core trick: permanent behaviour change without retraining.
This reframes what "the model is unreliable" means in production. A raw model calling raw tools will repeat the same failure mode every time it hits the same situation, because it has no memory of having failed before. A harness gives it that memory - as code, not as a hope that a better prompt will fix it next time.
The Five-Layer Model
A production-grade harness is usually described as five layers stacked around the model:
1. Tool Orchestration
Which tools exist, how they are dispatched, and what happens when a tool call fails or returns something unexpected. See Tool Calling Patterns.
2. Verification Loops
Automated checks that confirm the agent's output is actually correct - tests, linters, schema validation - rather than trusting the model's own claim that it succeeded.
3. Context & Memory
What the agent remembers between steps and sessions - project conventions, past failures, standing instructions. See Memory & CLAUDE.md for a concrete implementation of this layer.
4. Guardrails
Hard limits on what the agent is permitted to do - permission scopes, approval gates, blocked commands. See Guardrails & Permissions.
5. Observability
Logging and tracing of every step the agent took, so failures can be diagnosed and fed back into the other four layers instead of being fixed by memory and vibes. See Tracing LLM Calls in Production.
What a Harness Looks Like in Practice
A request flowing down through each layer of the harness - a failure at any layer feeds back into a permanent fix, not a one-off correction
Harness Engineering vs Prompt and Context Engineering
| Discipline | Question it answers |
|---|---|
| Prompt engineering | What should I say to the model? |
| Context engineering | What should the model see when it answers? |
| Harness engineering | What system catches it when it gets the answer wrong? |
Getting Started
The practical habit
Every time an agent fails in a way you had to notice and correct by hand, write down exactly what went wrong, then turn that into one of the five layers above - a new guardrail, a new verification check, a new line in memory. Do this consistently and the harness becomes an asset that compounds, independent of which underlying model you swap in.
This is also why harness engineering is described as model-agnostic: because the fixes live in the surrounding system rather than in the weights, a harness built around one model's failure modes keeps most of its value when you switch to a different model or a newer version.
Checklist: Do You Understand This?
- Can you explain why harness engineering changes agent behaviour without retraining the model?
- Can you name the five layers of a production harness and give one example of each?
- Do you understand why a verification layer must check the result independently, not just accept the model's claim that it succeeded?
- Can you explain the difference between a guardrail (prevents an action) and a verification loop (checks a result)?