The prediction
The harness engineer job disappears in 2026
My prediction: in most agent teams, the harness engineer job disappears in 2026. The job that replaces it is the harness configuration engineer, the person who tunes the instruction, model, skills, and tools each harness runs with, and makes those configurations win production tasks.
I expect only the organizations that ship complete harnesses, frontier labs, platform vendors, and open-source communities, to keep harness engineers, and they should. An agent harness is the runtime half of an agent, the loop that plans, calls tools, edits files, and carries state, and building that loop well is exactly the deep work those organizations are structured to do. Harness engineering, a term the community itself has started using, is thriving there.
Everywhere else, I think the job quietly changes hands. Not because the work got less important, but because the reason to do it in-house is going away. Here is why.
Here is why
Harnesses became infrastructure you plug in
The layer got a contract: the Unified Harness Protocol (UHP, specified at unifiedharnessprotocol.org) unifies the interfaces across agent harnesses such as DeepSeek Harness, Codex, Claude Code, Hermes, and Pi. One contract, every harness. And HarnessRouter open-sourced its implementation of that protocol, so teams can simply run it rather than build one.
That changes what a harness is to a product team. Once every harness runs behind the same contract, same task in, same streams and artifacts out, existing harnesses become plug-ins to your backend. The harness system you would have built in-house, the loop, the sessions, the streaming, the file plumbing, stops being something you write and becomes something you select. Teams stop developing harness systems and start shipping features. That trade is a business win, and businesses take it.
The supply side keeps making the trade better. Complete harnesses improve continuously with the labs behind them, and beyond the ones I named, larger platform vendors keep entering with complete harnesses of their own. Competing with that from inside a product team is a strategy few roadmaps can afford.
So what is left to engineer? More than most teams expect, because the unit you now choose is not the bare harness but the configuration, and configurations differ enormously on the same work: in the published same-task benchmark linked below, eight harness and model configurations each ran the same task five times on identical input, and cost per task varied by approximately 475 times while p95 end-to-end latency varied by more than 3 times. Results vary by task, and that spread is across harness and model alone; I expect the dials inside the harness to widen it further. Someone has to own that variance. That someone is the harness configuration engineer.
The configuration
Four dials: instruction, model, skills, tools
A configuration is a harness together with everything you set inside it. In my experience, four dials do most of the work:
- Instruction: the operating brief the agent runs under, from the task itself to the standing guidance the harness reads. In my playbook, the first dial to test and usually the cheapest to turn.
- Model: the reasoning engine behind the harness, chosen per task class rather than per company.
- Skills: the packaged procedures and domain knowledge the harness can load, so the agent starts from your team's way of working instead of a blank page.
- Tools: what the agent can touch while it works, from repositories and files to the services it is allowed to call.
Here is the part I consider the key: the winner is not the team that sets any one dial perfectly. It is the team that iterates the dials fastest. When instruction, model, skills, and tools can be adjusted quickly and measured on real tasks, the team ships faster, optimizes faster, and keeps winning as the field changes. Configuration speed, not configuration perfection, is the compounding advantage.
The role
What a harness configuration engineer does
When people ask me what this person does all day, my answer is four verbs: benchmark, eval, test, and set up the fallback. In practice the loop looks like this:
- Map the task classes: know which kinds of work your product actually sends to agents, because winners are per task class, not per company.
- Benchmark on your own tasks: build the evals first, the fixtures and written success criteria that turn real production work into repeatable tests, versioned like code. Race candidate configurations through them, same task, same conditions. Gate on success and quality first: a configuration that fails cheaply is not a candidate, it is noise. Rank the passers by cost and latency.
- Ship the winner: point each task class at its winning configuration through one integration.
- Set up the fallback: decide in advance which configuration takes the task when the winner fails or degrades. Behind one contract, the fallback is one configuration away instead of a second integration.
- Iterate the dials: a new model version, a changed tool, an improved skill, each is a new configuration to put through the loop, not a silent upgrade to trust. Yesterday's winner is a hypothesis, not a fact.
- Keep score in the right units: cost per successful task and p95 latency.
None of this is a checklist you run once. It is an operating loop, benchmark to eval to ship to fallback and back again, and in teams that run it the agent feature stops being a bet on one vendor's roadmap and becomes a managed system.
The craft
The skills look different from build-side skills
The build-side harness engineer thinks about tool dispatch, context management, and failure recovery. The configuration engineer's craft is measurement: translating user-facing quality into gate criteria, keeping fixtures honest, and knowing the contract surfaces (tasks, sessions, streaming, files, artifacts) well enough that nothing in the practice is welded to one vendor.
I think of it the way infrastructure teams came to think of databases. Few companies write one; many employ people who choose, tune, and operate them against measured workloads. The harness is on the same path, and the operating role deserves its own name and its own craft.
The working model
How a team works with a harness configuration engineer
The division of labor falls neatly across the four dials. The team brings what it knows best: the skills and tools the product needs. Product engineers contribute the domain procedures worth packaging as skills, and they connect the tools, the repositories, files, and services the agent must touch to do real work. No configuration engineer can invent that knowledge for them.
The configuration engineer takes those inputs and makes sure the harness is configured at its best and continuously optimized: pairing the team's skills and tools with the right harness, model, and instruction per task class, gating and benchmarking, and re-tuning as both the product and the field move. The team feeds the dials; the engineer runs the loop.
In practice it works like any platform role. A new task class or a new tool arrives from the team the way a schema change would, and the configuration engineer answers with an arena run and an updated winner. Neither side needs to block the other, and both get faster: the team ships product, the engineer ships better configurations of it.
The workbench
What the role needs from its tools
A configuration engineer is only as fast as the field they can race. That is the practical reason HarnessRouter is built the way it is: one contract, harnesses like Codex, Claude Code, and Hermes running with multiple models behind it, Harness Arena to race configurations on your own tasks, public benchmarks and rankings for the state of the field, and routing that points a task class at its winner without new plumbing. I wanted the loop in this article to be an afternoon of work, not a platform project.
Because the contract underneath is open, the practice is hard to strand: the fixtures and evals you build keep carrying value as the field turns over.
The conclusion
If you already do this work, take the title
In many product teams someone is already doing half of this job without a name for it: running ad hoc comparisons, maintaining a folder of test prompts, arguing for a switch the org will not revisit. Naming the role is how the work gets budget, headcount, and rigor.
Harness engineers will keep making harnesses better, inside the organizations that ship complete harnesses. Harness configuration engineers will decide which of those harnesses earn production traffic, and how each one is instructed and equipped. Products win on that second decision, and the winning is done in the loop: benchmark, eval, test, set up the fallback, and go again. I may be off on the date. I do not think I am off on the direction.
FAQ
Harness configuration engineer FAQ
What is a harness configuration engineer?
The engineer who owns which configuration, an agent harness plus the instruction, model, skills, and tools inside it, serves each class of production task. Day to day that means maintaining evals, benchmarking candidates, shipping winners with fallbacks behind them, and re-testing whenever anything upstream updates.
Is harness engineering going away?
No. It is thriving where complete harnesses are shipped: labs, platform vendors, open-source projects. What changes is inside product teams, where the leverage moves to configuration. One craft keeps improving the contenders; the other decides, per task class, which contender actually gets used.
How does a product team work with a harness configuration engineer?
The team brings the ingredients only it can know: which of its procedures deserve to become skills, and which of its systems the agent needs as tools. The configuration engineer turns those into winning configurations, choosing harness, model, and instruction per task class, and keeps re-tuning as product and field move.
How do I start as a harness configuration engineer?
Pick a single real task and write down what success means for it. Field a few configurations, drop the ones that miss that bar, rank the rest by cost and latency, and route the task class to the winner. Repeat for the next task class, and re-run whenever the field moves.
Build the practice on one contract
Create an API key, wire one integration, and start racing configurations on the tasks your product already runs.
Start building