Harness engineering vs context engineering.
One is a component of the other, and confusing them is why teams optimise the wrong thing.
Context engineering is about what goes into the model's context window: retrieval, compaction, memory and prompt construction. Harness engineering is the larger discipline that contains it, covering tools, the agent loop, approval policy, and the verification that checks output before a human does. Context engineering is one component of a harness, and it is the component that stops being the bottleneck first as context windows grow.
The relationship, stated once
Context engineering answers what the model sees. Harness engineering answers everything else, and includes context engineering as one of its parts. A team that has perfected retrieval and compaction but has no verification loop has done excellent context engineering inside a weak harness, and the output quality will show it. The reverse also happens: strong tests and approvals wrapped around a model that is being fed the wrong files.
Why context engineering came first
It was the binding constraint. When context windows were small, deciding what to put in them was most of the work, and the discipline formed around that scarcity. As windows have grown, the constraint has moved: the limiting factor is now more often whether the agent's work can be verified cheaply than whether the relevant file fits. Anthropic's harness-design write-up documents the newer failure mode, what it calls context anxiety, where a model begins wrapping up prematurely as it approaches what it believes is its limit.
What harness engineering adds
Tool design and which tools are exposed at all. Approval policy, and what the agent may do without asking. Verification, meaning the tests, linters and reviews that catch an error before a human spends attention on it. Isolation, so a failed attempt does not damage the working tree. And the loop itself: how many iterations, what ends a turn, what happens on failure. None of that is a context question.
The distinction in practice
If your agent produces plausible code that fails your tests, that is a harness problem and no amount of retrieval tuning fixes it. If your agent produces code that ignores an existing convention documented in a file it never read, that is a context problem. Diagnosing which one you have is most of the value in keeping the terms separate.
How Lucid Train handles both
On context: a repository map with symbol extraction under a token budget, automatic compaction with an emergency retry when a provider reports overflow, and persistent memory with optional local embeddings that works offline. On harness: sub-agents in isolated git worktrees, four approval modes, per-role models so a cheap model plans while a stronger one writes the diff, and a publish-state guard that blocks destructive commands after an acceptance check passes.
Which discipline owns which question
| Question | Discipline |
|---|---|
| What files does the model see? | Context engineering |
| How is the conversation compacted? | Context engineering |
| What is retrieved, and how is it ranked? | Context engineering |
| What does long-term memory hold? | Context engineering |
| Which tools exist, and what do they return? | Harness engineering |
| What may the agent do without asking? | Harness engineering |
| What checks the output before a human does? | Harness engineering |
| Where does a failed attempt land? | Harness engineering |
| What ends a turn? | Harness engineering |
Questions
Related
- What Is a Coding Harness?Everything in the agent that is not the model. The part you can actually change.
- Coding Agent vs HarnessAgent equals model plus harness. The harness is the half you control.
- Is Claude Code a Harness?Both, and the confusion is in the question rather than the answer.
- Is GitHub Copilot a Harness?Two products under one name, and only one of them is a harness.