Harness Engineering: The Right Idea on the Wrong Foundation
There's a new term gaining traction in the AI engineering space: harness engineering.
The idea is compelling. As AI agents take over more execution — writing code, managing workflows, making operational decisions — the human role shifts from writing individual lines of code to something arguably more important: defining the environments, constraints, and feedback loops that allow agents to operate effectively.
In other words, humans become the architects of the space. Agents become the executors within it.
I agree with this direction. It makes sense. Agents, like humans, need guidance and boundaries. The concept of engineering those boundaries as a formal discipline is overdue.
But — and you knew there was a "but" coming — this conversation seems to have two blind spots that deserve more attention than they're getting.
Blind Spot #1: Agent Sprawl Is Coming — And We've Seen This Movie Before
Remember when microservices were the answer to everything?
Every conference talked about breaking monoliths into small, independent services. Every team rushed to deploy dozens, then hundreds, of microservices. It was modern. It was scalable. It was the future.
And then reality hit. Organisations found themselves drowning in an orchestration nightmare that few had planned for. Services calling services calling services, with limited visibility into what depended on what. The tooling to manage the complexity came after the complexity was already unmanageable.
Agent sprawl will follow the same pattern — but with a critical difference.
Microservices execute deterministic logic. When service A calls service B, you can predict the outcome. Agents make autonomous decisions. When agent A interacts with agent B, the outcome space is exponentially larger. The blast radius of "too many, poorly governed" isn't a slow degradation — it's an unpredictable cascade.
The harness engineers that this new discipline promises? They risk being overwhelmed before the first feedback loop even completes. Not because the concept is wrong, but because organisations tend to do what they've always done: deploy first, govern later.
We don't need more agents. We need agent governance before we need more agents.
Blind Spot #2: You Can't Harness What Sits on a Broken Foundation
Here's the question that the harness engineering conversation tends to step around: what does the agent actually operate on?
The original concept talks about "making the codebase itself understandable to the agent." This sounds reasonable in a conference slide. In practice, it assumes something that rarely exists in enterprise environments — a codebase that can be readily understood.
I've spent over three decades working inside critical infrastructure — payment systems, banking, telecommunications. I can tell you what most enterprise codebases actually look like:
- Decades of accumulated technical debt
- Documentation that was outdated the day it was written — if it was written at all
- Workarounds stacked on workarounds, where the original reason for the workaround has been long forgotten
- Architecture decisions driven by vendor relationships, not requirements
- Knowledge that exists only in the heads of people approaching retirement
Deploying agents on top of this is like putting a Formula 1 engine in a car with no suspension. The engine is magnificent. The car falls apart at the first corner.
The agent doesn't fix your broken infrastructure. The agent amplifies it. Every inefficiency, every undocumented dependency, every architectural compromise from 2004 that "we'll fix later" — the agent will find it, interact with it, and propagate it at machine speed.
Before we engineer the harness, we need to engineer what the harness sits on.
The Conversation That Keeps Getting Postponed
There's a reason this part of the discussion tends to get deferred. Fixing infrastructure is expensive, slow, politically difficult, and deeply unglamorous. It's hard to build a compelling business case around "we spent 18 months cleaning up technical debt so our agents would have a solid foundation." It's much easier to present "we deployed 47 AI agents across our operations."
But here's what three decades of enterprise reality have shown me: the organisations that skip the foundation work will likely spend more time debugging their agents than the agents spend doing useful work.
Harness engineering as a concept is sound. The direction is right. But a harness is only as good as what it's attached to.
An agent with perfect guardrails, operating in a well-defined environment, with clear feedback loops — on top of infrastructure that was never designed for agent interaction — is still an agent waiting to amplify the wrong thing at the worst time.
So What Can We Actually Do About It?
It's easy to point at problems. What's harder — and more useful — is thinking about practical steps. These aren't prescriptions. Every organisation is different. But they're questions and approaches that might help sharpen the thinking before the deployment pressure wins.
Start with a honest diagnostic — not a checkbox audit.
Before deploying a single agent, walk the infrastructure it will touch. Not on a diagram — in reality. Where is the documentation? Where are the undocumented dependencies? Where does knowledge live only in someone's head? This isn't about finding blame. It's about understanding what an agent would actually encounter on day one. Most organisations are surprised by what this exercise reveals.
Separate "agent-ready" from "agent-possible."
Just because an agent can be deployed on a system doesn't mean the system is ready for it. A useful exercise: for each candidate process, ask "if this agent makes a wrong decision at 3 AM, how quickly can we detect it, understand it, and reverse it?" If the answer involves waking up three people who each hold a different piece of the puzzle, the system isn't agent-ready — it's agent-possible. There's a significant difference.
Treat remediation as investment, not cost.
Cleaning up technical debt, documenting tribal knowledge, resolving architectural workarounds — this work often gets classified as cost. It's actually the highest-ROI investment an organisation can make before any AI deployment. An agent operating on a clean, well-documented foundation will deliver compounding value. The same agent on a fragile foundation will deliver compounding problems. The maths is straightforward, even if the budget conversation isn't.
Govern the population before it governs you.
The microservices lesson is available to anyone willing to learn from it: set boundaries on quantity, scope, and authority before deployment, not after the orchestration becomes unmanageable. For agents, this means answering uncomfortable questions early: How many agents is enough? Who authorises a new agent deployment? What's the retirement criteria for an agent that's no longer needed? These questions feel bureaucratic until the alternative becomes real.
Build the feedback loops for humans first, then for agents.
Harness engineering emphasises feedback loops for agents — and rightly so. But consider this: if your organisation doesn't already have effective feedback loops for human decision-making (clear escalation paths, post-incident reviews that actually change behaviour, metrics that measure outcomes rather than activity), adding agent feedback loops on top won't solve the structural gap. It will add a layer of data that the existing human loops aren't equipped to process.
The Sequence Matters
If there's one takeaway from all of this, it's that the order matters more than the ambition.
Diagnose before you deploy. Remediate before you automate. Govern before you scale. Then — and only then — engineer the harness.
This sequence is slower. It's less impressive in a quarterly review. It doesn't generate the kind of announcements that trend on LinkedIn.
But it works. And in enterprise environments where failure isn't a learning opportunity but a direct impact on millions of transactions, customers, or operations — "it works" is the only metric that matters.
The Bottom Line
Harness engineering isn't wrong. It's incomplete.
The conversation about how humans should structure the space for AI agents is necessary and overdue. But it tends to skip the hardest, most expensive, and most important question: is the space itself ready for agents?
In most enterprises, the honest answer is "not yet." And that's not a failure — it's an opportunity. The organisations that take the time to prepare the foundation will be the ones where harness engineering actually delivers on its promise.
The right idea, on the right foundation, at the right time. That's the combination worth pursuing.