vs context
Harness engineering vs context engineering: the open-source files that keep the fix
Prompt engineering changes what you ask. Context engineering changes what the model can see. Harness engineering designs the environment the agent operates within: the guides that steer it before it acts, the sensors that check its work after, and the permissions that bound it. In Kortix, the open-source AI Operating System, those rules live in a repo you own.
The permission is declared in the agent file
---mode: primarypermission: allow---The starter agent file opens with its mode and its permission before the prompt starts.
Three layers, three artifacts
Most teams meet these three terms in one article and assume they are one job at three sizes. They are three jobs, and each one leaves a different artifact behind.
Prompt engineering is what you say to the model. You rewrite the instruction, add an example or a format, and hope the next answer is better. The artifact is a prompt or a template, and its reach ends with the exchange that used it.
Context engineering manages what the model can see while it works. Which files get retrieved, what survives compaction, what drops out when the window fills: in the three-layer split Milvus uses, that is the context layer, scoped to the window. The artifact is a retrieval and compaction policy, and it runs on every turn.
Harness engineering designs the world the agent operates in. Mitchell Hashimoto introduced the term in February 2026, describing a habit: every time an agent made a mistake, he engineered a permanent fix into the agent's environment. The artifacts are guides, sensors and the permissions that bound what the agent may touch.
The scope separates them, and one sits inside the other. Prompt and context work on the turn: what the model is asked and what it can see while it answers. The harness is the environment around that turn, from the guides that steer the agent before it acts to the sensors that check the work after, plus the permissions and orchestration that decide what it may run at all. LangChain's inventory of a harness runs from system prompts and tool descriptions through sandbox, browser and orchestration logic to the hooks and middleware that make a step deterministic. That is a list of parts. The engineering is deciding which part catches which failure.
| Layer | What it optimizes | The artifact it leaves | What it cannot fix |
|---|---|---|---|
| Prompt engineering | The words in one request | A prompt, a template, a few-shot set | A rule the next session never sees |
| Context engineering | What the model can see this turn | A retrieval and compaction policy | A mistake the model can see and still make |
| Harness engineering | The environment and loop around the agent | A guide, a sensor, a permission | A failure nobody wrote a check for |
Guides act before, sensors after
Martin Fowler's model of guides and sensors shows why the third layer is not a larger version of the first two. Guides are feedforward controls: they anticipate what the agent will do and steer it before it acts. Sensors are feedback controls: they observe what the agent did and help it correct. Each comes in two kinds, computational (tests, linters, type checkers, structural analysis) and inferential (semantic review, a model as judge). The trade is speed and determinism against semantic judgment.
Skip one side and the failure is predictable:
"Separately, you get either an agent that keeps repeating the same mistakes (feedback-only) or an agent that encodes rules but never finds out whether they worked (feed-forward-only)." Fowler, 2 April 2026
Read that line next to a context window. A bigger window is a bigger feedforward budget. It gives the model more to read and it observes nothing. Agents are also poor judges of their own output, which is why the evaluator has to sit apart from the generator, the way a GAN separates the two. A window cannot be that separate evaluator.
One duplicate helper, three repairs
An agent building a billing screen writes formatCurrency. The repo already exports formatMoney from src/lib/money.ts. Review catches the duplicate, the function is deleted, and two weeks later a different session writes it again inside the invoice table.
The prompt fix is a line in the prompt: search src/lib before writing a helper. It holds for as long as that prompt is the one in force. Compaction trims it, a new agent file starts without it, and nothing in the system notices the second duplicate.
The context fix retrieves src/lib/money.ts into the window, or indexes exported helpers so the file is within reach. The model can see the helper now. It may still write its own, because a name in context is not a rule, and you learn about it at review again.
The harness fix is a structural test that fails when a new export duplicates an existing helper, with the correction inside the message: reuse formatMoney from src/lib/money.ts. Fowler singles out exactly that shape, custom linter messages that include instructions for the self-correction, and classifies structural tests as computational sensors. A check runs on every change. The second duplicate cannot merge, and the message steers the retry on the first attempt.
Which layer gets the hour
A prompt edit takes minutes. A retrieval policy takes an afternoon. A check takes an hour, plus the upkeep of keeping it true. The order that pays:
- First time an output is wrong, edit the prompt and write the failure down.
- The same failure when the agent lacked information, fix retrieval or compaction.
- The same failure a second time, write the guide and the sensor. This is the only layer that makes a recurrence visible.
- A boundary that must hold, such as no writes to production, belongs in a permission. A sentence in a prompt cannot enforce it.
That last one reads like copy and behaves like code. A prompt that says "never touch production" is a request. A declared permission is a control the runtime can check, and it is the piece a prompt cannot express.
The harness is a file you can read
Kortix keeps your agents, the skills they share, your company memory, and every connector in one git repo. It is versioned and diffable. The agent file opens with description, mode and permission, and the body after that frontmatter is the prompt, so a control you add after a failure lands in a diff. Approval gates you set. Off until you set them.
Questions the comparison raises
Each answer names the layer a problem belongs to.
- What is harness engineering vs context engineering?
Harness engineering designs the environment an agent works in: the guides that steer it before it acts, the checks, permissions and feedback that stop a mistake from returning, and the orchestration that runs them. Context engineering decides what the model can see on one turn, which is one input inside that environment.
- Is context engineering part of the harness?
Partly. A harness holds the system prompts, the retrieval and compaction rules, the tools, the checks and the orchestration, so context work is one job inside it. Harness engineering is the work of designing that container: the rules that steer the agent before it acts, and the checks that catch it after.
- Does a bigger context window remove the need for a harness?
No. A bigger window changes how much the model can read, and reading more does not tell it whether its work passed. Cognition enabled the 1M-token beta but capped usage at 200K tokens so the model believed it had runway. That cap is harness work.
Put the check where the agent runs
One repo holds the agent file, the skill and the permission, so the fix you write after a failure is reviewable before the next session starts.