Harness Engineering Is Becoming a Real Job — Here's What's Actually in the Job Description

Companies don't need someone who can "prompt an agent" anymore — they need someone who can build the permissions, adapters, and interfaces that let an agent operate safely inside real systems, and that's turning into a distinct engineering role.

For the last two years, the career advice around AI agents has mostly been about learning to prompt them well. That's no longer the scarce skill. The scarce skill is building the scaffolding an agent sits inside of — the thing increasingly called a harness — and it's specific enough, and hard enough, that it's becoming its own job description rather than a side responsibility of "the AI person" on a team.

The clearest public walkthrough of what this actually involves comes from Lenny's Newsletter, which documents how the product-management tool ChatPRD built a harness to debug Sentry bugs automatically. The piece is worth reading in full if you're weighing whether to specialize here, because it makes a point that's easy to miss: the model was never the bottleneck. The team used the Claude Agent SDK as a foundation, then spent the bulk of their engineering effort on a custom terminal UI and a set of adapters connecting the agent to Sentry, Linear, GitHub, and Vercel. That's the job, in miniature. Four systems, four different auth schemes, four different data shapes, and a UI that lets a human watch and intervene without babysitting every step.

What "harness" actually breaks down into

If you're trying to figure out whether this is a skillset worth building, it helps to separate it into pieces that get hired for separately, or at least evaluated separately in an interview:

Permissions design. Deciding what an agent is allowed to do unattended (read a ticket, draft a PR) versus what needs a human in the loop (merge, deploy, delete, spend money) — and encoding that as actual policy in code, not as a prompt instruction the model might ignore under pressure. This is closer to access-control engineering than to prompt writing.
Tool adapters. Thin, well-tested wrappers around each external system (Sentry, Linear, GitHub, Vercel, or whatever your company's stack is) that translate the agent's intent into a safe, validated API call and translate the response back into something the model can reason about. This is ordinary software engineering — error handling, retries, schema validation — applied to a new consumer.
Terminal or console UI. A way for a human to see what the agent is doing, approve or reject actions, and step in when it gets stuck. ChatPRD built a custom one; plenty of teams will use off-the-shelf agent consoles instead, but someone still has to decide what's shown, what's hidden, and what requires a click before it happens.
Tool selection at scale. A write-up from Machine Learning Mastery flags something worth knowing if you're building anything beyond a demo: agent accuracy on tool calls tends to degrade once the tool catalog passes roughly a dozen options — the model starts miscalling tools, hallucinating parameters, or stalling on bad calls. The mitigations it lists (gating which tools are even visible in a given context, retrieval-based tool lookup, routing to specialized sub-agents, explicit planning steps, fallback logic, and benchmark harnesses to catch regressions) are themselves a checklist of things a harness engineer needs to know how to implement, not just know about.
Context and memory engineering. The same source draws a distinction worth internalizing: context engineering (what goes into a single inference call, and where) and memory engineering (what persists across sessions, how it's stored, how it's retrieved) are different disciplines with different failure modes. Its claim is that most breakdowns in long-running, multi-session agents trace back to conflating the two — treating session memory like it's just more context, or vice versa — particularly at the point where the system decides what to retrieve.

The evidence this is a real, fundable role — not just a hobbyist niche

Skeptics will reasonably ask whether "harness engineer" is a job or just a task inside someone else's job. Two data points from the digest suggest it's moving toward the former. First, Microsoft's Aspire team — a 10-person group — used GitHub's Agentic Workflows to automate cross-repo documentation PRs, and over two releases merged 82 PRs at a median of 44.8 hours after the corresponding product PR shipped, with no new headcount and no process retraining. That's a small team getting outsized leverage specifically because someone invested in the scaffolding (the workflow definitions, the review routing, the trigger logic) rather than having engineers write docs PRs by hand. Second, Microsoft Research's SkillOpt project treats agent "skill" files — the instructions and constraints that shape how an agent behaves in its harness — as something to be systematically optimized rather than hand-edited, and reports it was best or tied-best across all 52 cells of a benchmark grid (six benchmarks, seven models, three execution modes), with the optimized skills transferring across different models and different harnesses. Whether or not that specific tool becomes standard, it signals that the industry is starting to treat harness configuration as an engineering artifact with its own tooling and benchmarks — the same trajectory that turned "DevOps" from a set of ad hoc scripts into a discipline.

There's also infrastructure now being built explicitly for this layer. Google's newly announced "Managed Agents" capabilities in the Gemini API — background and async execution, remote MCP server integration, custom function calling, credential refresh across interactions — are effectively pre-built plumbing for the exact problems the ChatPRD team solved by hand. That's a normal pattern: what one team builds bespoke this year, a platform vendor productizes next year. It doesn't eliminate the harness-engineering role; it raises the floor and shifts the job toward integrating and configuring managed primitives rather than writing every adapter from scratch, similar to how cloud infrastructure didn't eliminate ops engineers, it changed what they spent their time on.

What this means if you're aiming at this role

A few concrete, checkable things to put on a portfolio or resume if you want to be credible for this work: build one adapter end to end against a real API you don't control (auth, error handling, rate limits included, not a happy-path demo); design and document a permissions model for an agent that distinguishes read/propose/act actions and shows why each boundary is where it is; and build or configure a review interface where a human approves agent actions before they execute, since that's the piece most companies will insist on before letting an agent touch production. If you're evaluating a harness-engineering job offer or scoping your own responsibilities, ask specifically who owns the permissions model, who owns the adapters, and who owns the human-review surface — in a lot of teams right now those three things have no clear owner, which is exactly the gap this role is forming to fill.

One caveat worth stating plainly: none of the sources above establish a hiring-market number for this specific title, and "harness engineer" isn't a job title you'll see on postings yet — it's showing up inside titles like "AI infrastructure engineer," "agent platform engineer," or just "senior backend engineer, AI systems." Treat this as a skillset to build and describe accurately, not a title to search for on LinkedIn.