Your AI Agent Isn't Broken. Your Harness Is.
The model isn't your bottleneck anymore.
You've upgraded the model three times this year. You've refined the system prompt, tuned the temperature, and read every paper on chain-of-thought reasoning. Each change delivered marginal improvement. But in production, your agent still hallucinates at the worst moments, loses context mid-task, and collapses when real-world ambiguity enters the picture.
The fault doesn't live in the model. It lives in what surrounds it.
Harness engineering is the discipline separating teams that ship 1,300 AI-generated pull requests per week from teams whose agents never make it past the demo. Most practitioners don't know it exists. Those who do have an advantage no model upgrade can replicate.
The Three Layers Most Teams Build — and the One They Skip
Prompt engineering came first. You learned to write instructions that guided the model toward useful outputs. Context engineering followed, teaching you to curate what entered the context window and in what order. Both disciplines matter.
Neither addresses the structural question: what holds the agent together when a task spans hundreds of steps, multiple tools, and genuine ambiguity?
That's the harness.
- Prompt engineering shapes what the model knows in a single call
- Context engineering shapes what information the model sees and how it's ranked
- Harness engineering shapes the environment, constraints, feedback loops, and recovery paths that make the model reliable at scale
Skip the harness and your agent is a sports car without a chassis. Fast in a straight line. Dangerous everywhere else.
What a Harness Actually Is
A harness isn't a framework or a library. It's the accumulated set of decisions about how your agent operates between calls:
- How context is serialized and pruned when the window fills
- Which tools are exposed at which points in the workflow
- What happens when a tool call fails or times out
- Where state lives between sessions so the agent can recover
- How the agent detects when it's looping and breaks the cycle
- What escalation paths exist when confidence drops below a threshold
Every production system that works has solved these problems — most of them quietly, buried inside custom infrastructure that never gets written about. That silence explains why 88% of AI agent projects never reach production. Not because the models are bad. Because nobody built the harness.
Context Folding: The Technique You're Not Using
The context window is finite. Long tasks will fill it. What happens next determines everything.
Most teams let context grow until the model starts forgetting, then restart the session and lose progress. The teams building production agents do something different. They fold.
Context folding works like this:
- When a subtask completes, the agent distills that subtask's full context into a compact summary
- The summary replaces the subtask history in the active window
- The full history is written to external storage, retrievable if needed
- The main task continues with a clean, lean context
The agent never forgets. The window never overflows. Tasks that would otherwise collapse at step 47 now run to completion.
Intent Before Architecture
Here's the part most teams skip when designing multi-agent systems: defining what the agents are actually trying to accomplish at an organizational level.
Intent engineering is the practice of encoding goals, constraints, and trade-off hierarchies into agent infrastructure before any code is written. Not in the system prompt. In the architecture itself.
When agents operate without explicit intent encoding, they optimize for completing the task as specified. When the specification is ambiguous or incomplete — and it always will be, eventually — the agent produces outputs that are technically correct and practically wrong.
Intent engineering asks:
- What does success look like at each layer of the system?
- What trade-offs should the agent make when constraints conflict?
- When should the agent stop and escalate versus proceed with its best guess?
Teams that answer these questions before building ship agents that behave predictably in production. Teams that skip them spend their time debugging behaviors that are rational from the model's perspective and baffling from the user's.
The New Role Nobody Has a Title For
Software engineering in 2026 is undergoing the same transition that infrastructure engineering went through when DevOps emerged. A new discipline is taking shape at the intersection of systems design and AI behavior.
The agent harness engineer:
- Designs the execution environment that agents operate within
- Builds context management infrastructure for long-horizon tasks
- Defines the escalation and recovery protocols that keep agents safe in production
- Monitors agent behavior at the system level, not the prompt level
This isn't a prompt engineer. This isn't a data scientist. This is an infrastructure role requiring deep knowledge of how models behave under real-world conditions and how to build systems that channel that behavior productively.
Most organizations don't have this person yet. The ones that do are shipping what everyone else is still demoing.
The Stripe Number
Stripe ships roughly 1,300 AI-generated pull requests every week. Full pull requests. Reviewed, merged, deployed.
That number is not a model capability story. The models Stripe uses are the same models available to every other team. The difference is harness depth. They built infrastructure that lets hundreds of agents work in parallel, manage their own context, recover from failures, and produce outputs that meet production standards.
The model is a commodity. The harness is the moat.
Where to Start
Most teams try to solve harness problems by improving prompts. That's the wrong tool for the problem.
Start here instead:
- Map every point where your agent can fail and define explicit recovery behavior for each one
- Build external state storage from day one, not as an afterthought when sessions start breaking
- Define escalation thresholds before you need them, not after your first production incident
- Instrument agent behavior at the step level so you can observe what the agent actually did, not just what it returned
The harness isn't glamorous. No benchmark measures it. No paper names it as the decisive factor in production readiness.
But when your agent runs a hundred steps without losing the thread, recovers from a failed API call without human intervention, and produces outputs that meet production standards on tasks your competitors' agents can't finish, you'll know exactly where the advantage came from.
The model was never the variable that mattered most.