Konstantin Semenenko
July 22, 2026
4
minutes read
An AI agent's reliability comes almost entirely from the engineering around the model, not the model itself. An audit of one leading coding agent found roughly 98% of its code is the deterministic harness (permission gates, context pipelines, tool routing, failure recovery) and only about 2% is model-facing logic. Agents like Claude Code, Cursor, and Codex often run on similar models; what separates them is their harnesses. So "which model is best" is the wrong reliability question, "is our harness good" is the right one, and that is engineering, not model selection.
The most useful thing to understand about AI agents in 2026 is that their reliability is an engineering property, not a model property. A systematic audit of one leading coding agent found that roughly 98% of its codebase is the deterministic harness, the permission gates, context pipelines, tool routing, and failure recovery around the model, and only about 2% is model-facing decision logic. That single number reframes the whole conversation: the thing that makes an agent reliable is overwhelmingly the system built around the model, not the model inside it. It explains why agents running on nearly identical models behave so differently, why swapping in a "better" model rarely fixes an unreliable agent, and why the teams shipping dependable agents talk about verification and permissions rather than benchmarks. This explains the 98% finding and what follows from taking it seriously.
We build the engineering layer that makes AI agents reliable, so this is a practitioner's argument for where reliability actually comes from, grounded in how these systems are really built.
The number comes from looking at what an agent's code actually does. When researchers audited a leading coding agent, the vast majority of its implementation was not prompts or model calls, it was deterministic infrastructure: code that decides which tools are available and validates their arguments, code that assembles and compacts what the model sees, code that routes tool calls and sanitizes their results, code that catches failures and recovers, and code that enforces what requires human approval. The model-facing part, the prompts and the logic that hands control to the model, was a thin sliver on top.
That distribution is the argument. If 98% of what makes an agent work is deterministic engineering, then the agent's behavior is 98% determined by that engineering, not by the model. The model is a powerful component, but it is one component in a system that is mostly not the model. This matches how the field now defines the term: harness engineering is the discipline of designing the tools, context delivery, execution constraints, memory, and feedback loops around a model, and multiple independent analyses converge on the same conclusion, that agent failures usually stem not from the model's reasoning but from how the harness exposes information, enables actions, records evidence, and enforces policy.
The clearest evidence for the harness thesis is sitting in plain view: the major coding agents often run on the same or comparable frontier models, yet they behave very differently in reliability, and the difference is the harness. Claude Code, Cursor, Codex, and others make different choices about how they manage context, which tools they expose and how, how they verify work, how they recover from failures, and where they require approval, and those choices, not the underlying model, produce the difference in how dependable each feels on real tasks.
This is why "which model should we use" is the wrong first question for reliability. Two teams can build on the identical model and get wildly different results, because one built a disciplined harness and the other wrapped the model in a thin loop and hoped. Upgrading the model under a weak harness gives you a more capable engine in a car with no brakes, faster, not safer. The reliability lever is the harness, which is engineering you own, not the model, which is a component you rent. That is an empowering conclusion, because it means agent reliability is something a team can build rather than something it has to wait for a model release to receive.
The reason the harness carries reliability is that the things that make an agent trustworthy are precisely the things a model cannot do for itself. A model cannot guarantee it only takes permitted actions, that requires a permission gate outside the model. It cannot reliably verify its own output, that requires deterministic checks the model does not control. It cannot stop itself from looping forever, that requires an execution limit imposed by the harness. It cannot isolate its own blast radius, that requires a sandbox. It cannot enforce that consequential actions get human approval, that requires an approval gate the model cannot bypass.
Every one of these is a reliability property, and every one lives in the harness by necessity, because a property the model enforces on itself is a property the model can also fail to enforce. This is the core insight behind our MCAF framework: the rule that the agent may not guess, the layered verification, and the quality gates are harness mechanisms that hold regardless of what the model does, which is exactly why they make the system reliable. The harness is where you put everything that must be true no matter how the model behaves, and that is most of what reliability is, the same layered view we lay out in harness engineering vs loop engineering.
Taking the 98% seriously changes where a team spends its effort:
The mindset shift is from consumer to engineer: from picking the best model to building the best system around whatever model you use. The first is shopping; the second is the actual work.
AI agent reliability is an engineering property, not a model property, and the 98% harness finding makes it concrete: roughly 98% of a leading agent's code is deterministic harness, and only about 2% is model-facing logic, so the system around the model, not the model, determines whether the agent is dependable. This is why agents on similar models behave so differently, why model upgrades rarely fix unreliable agents, and why the reliability-critical properties (permissions, verification, stopping conditions, sandboxing, approval) all live in the harness by necessity, because a model cannot enforce them on itself. The practical shift is to invest in the harness rather than the model search, judge agents by their harness rather than their demo, and treat the harness as the durable asset it is. Reliability is not something you select; it is something you build.
If you want AI agents whose reliability comes from a real harness, verified, permissioned, bounded, and observable, rather than from hoping the model behaves, that is where our AI Dev Team work starts.
What does "98% harness" mean? An audit of a leading coding agent found that roughly 98% of its code is the deterministic harness (permission gates, context pipelines, tool routing, failure recovery) and only about 2% is model-facing decision logic. It illustrates that an agent's behavior and reliability are overwhelmingly determined by the engineering around the model, not the model itself.
Is AI agent reliability about the model or the engineering? Overwhelmingly the engineering. Agents built on similar models behave very differently because of their harnesses, the system of tools, context management, verification, permissions, and failure handling around the model. The reliability-critical properties live in the harness because a model cannot reliably enforce them on itself.
Why do agents on the same model behave differently? Because they have different harnesses. Claude Code, Cursor, and Codex make different choices about context management, tool exposure, verification, failure recovery, and approval gates, and those engineering choices, not the shared underlying model, produce the differences in how reliable each is on real tasks.
Will a better model make my agent more reliable? Usually not by much. A more capable model under a weak harness is more capable and still unreliable, because the properties that make an agent dependable (permissions, verification, stopping conditions) are harness functions, not model functions. If an agent fails in production, the fix is almost always harness work, not a model swap.
What should I invest in for a reliable agent? The harness: verification that checks the agent's output, permission boundaries the model cannot cross, execution limits that prevent runaway loops, sandboxing that bounds blast radius, and observability that makes behavior traceable. These deterministic controls, not model selection, are what make an agent reliable, and they compound across model generations.
