The model is not the product. The harness is.
Agent harness engineering is the discipline of designing everything around a large language model that turns it into a working agent: the tools it can call, the context it sees each turn, the caching that makes repeat turns affordable, the routing that picks which model handles which job, and the evaluation loop that tells you whether any of it actually works. The model supplies raw intelligence; the harness decides how much of that intelligence reaches your task — and at what price.
I've spent the last year building two coding agents — SoulForge (840+ stars on GitHub) and its successor Empryo — and the single most important thing I learned is this: most of an agent's quality is decided before the model generates a single token.
Why the harness beats the model
Everyone has access to the same frontier models. Claude, GPT, Gemini — they're an API key away from every competitor you have. So when two agents use the same model and one fixes the bug while the other burns $18 of tokens and gives up, the model didn't make the difference. The harness did.
Here's the sharpest example I have, from benchmarking Empryo. When I gave a small model (Claude Haiku) a ranked structural map of the codebase in context — Empryo's "genome" — it fixed bugs that otherwise required a frontier model, at roughly one fifth of the cost. Same task, same repo, same prompts. The only variable was what the harness put in front of the model.
That result generalizes into a rule I now design by:
Intelligence you rent per token. Understanding you index once.
Every token the model spends rediscovering your codebase's structure — grepping, reading files, guessing where things live — is rented intelligence doing a job the harness should have done once, for free.
The six components of an agent harness
Every serious agent product I've studied or built iterates on the same six loops.
1. Tool design
Tools are the agent's hands, and more hands are not better. Each tool you add grows the decision space, the prompt, and the failure modes. The craft is in sharpness: a tool that edits code by symbol (a function, a class) through the syntax tree beats a tool that pastes strings, because it can't corrupt whitespace or match the wrong occurrence. In Empryo, moving from string edits to AST edits meant the 60th edit in a session was as reliable as the first.
2. Context engineering
The model only knows what's in the window. What goes in — and in what order — is the highest-leverage decision in the whole system. The pattern that worked for me: front-load stable, structural knowledge (a ranked map of the repo: files, symbols, dependency edges), so the agent orients instantly instead of spending its first ten tool calls exploring. Search tells you where a string appears; structure tells you what the code is.
3. Compaction
Long sessions die one of two deaths: the context overflows, or the summary that replaces it loses the thread. Compaction is the art of throwing away the right things — keeping decisions, discarding transcripts of tool output, re-deriving what can be re-derived. Done well, an agent stays coherent across hours of work. Done badly, it re-reads the same file eleven times.
4. Prompt caching
Agents resend nearly identical prompts dozens of times per task. Providers will serve the repeated prefix from cache at a fraction of the price — if your harness keeps that prefix byte-stable. One late-arriving injection at the top of the prompt invalidates everything after it. Caching discipline routinely cuts real bills by half or more, which is why it's an architectural concern, not an optimization pass.
5. Model routing
Not every step needs the frontier model. Read-only exploration, summarization, and classification run fine on small models; the big model should be saved for the edits that matter. Empryo routes per role — cheap models for scouting, strong models for writing — across 22 providers, including free local ones. Routing is also your safety net: when a provider fails mid-stream, the harness should ride a fallback chain without losing the turn.
6. Evaluation
The loop that makes the other five improvable. Benchmarks of real tasks — actual merged bug fixes, not synthetic toys — with the provider's billing console as the source of truth for cost. When I audited agents' self-reported spend against the actual bill, one competitor's numbers were off by up to 32%; an agent's cost display should be a bill, not a vibe. If you don't measure against ground truth, your harness improvements are folklore.
How to start
- Instrument first. Log tokens, cost, steps, and outcomes per task. Compare self-reported cost against the provider console once — you may be surprised.
- Cut tools before adding them. Merge overlapping tools; make the survivors sharper and harder to misuse.
- Stabilize your prompt prefix. Put static context first, volatile context last, and watch your cache hit rate.
- Index what the agent keeps rediscovering. For code, that's the dependency graph. For other domains, it's whatever structure the agent greps for every session.
- Build a ten-task benchmark from your real workload. Run it after every harness change. Green rows you can't reproduce are ads, not evidence.
Where this discipline is heading
The term is young, but the job is already real: every team shipping agents in 2026 has someone doing harness engineering, whether they call it that or not. The models will keep getting better on their own schedule. The harness is the part you control — and in my experience, it's where products win or lose.
If you want to see one harness in full, Empryo is free to try: a live code genome, AST-first editing, per-role model routing, checkpointed time travel, and benchmarks published with the receipts. Its story — and the open-source experiment it grew from — starts with SoulForge.
Frequently asked questions
What is agent harness engineering?
The discipline of building everything around an LLM that turns it into a working agent: tool belt, context, compaction, caching, routing, and evaluation. The model provides intelligence; the harness decides how much of it reaches your task.
Is harness engineering the same as prompt engineering?
No. Prompt engineering tunes the words in a single request. Harness engineering designs the system that assembles every request: which tools exist, what context gets injected, what stays cached, which model runs. Prompts are one component; the harness is the machine.
Why does the harness matter more than the model?
Everyone rents the same models. Differentiation lives in what you build around them — the harness is why a small model with a ranked code graph outperformed a frontier model at a fifth of the cost in my benchmarks.
How do I get into harness engineering?
Build one. Take a real, repetitive task from your own work, wire an LLM to three sharp tools, measure cost and outcomes honestly, and iterate on the six loops above. The field is young enough that a well-instrumented side project puts you at the frontier.