What Is an Agent Harness? What Enterprises Actually Lack Isn't a Smarter Model

Agent products like Claude Code and Cursor have gone mainstream this past year — but many developers have noticed something odd: even when two products run on the exact same underlying model, the experience of using them can feel worlds apart.

On public agent benchmarks like Terminal-Bench, the same model plugged into different agent implementations often produces noticeably different scores. Several engineering teams have publicly shared how they took a coding agent from the bottom of the Top 30 to the Top 5 on a leaderboard — without ever swapping the underlying model, just by reworking the engineering system around it.

The takeaway: the model sets the ceiling on what an agent can do, but the engineering layer wrapped around the model determines how much of that potential actually gets realized. That layer has a name — the Agent Harness.

What Exactly Is an Agent Harness?

There's no single, industry-wide definition yet. Different communities use terms like Agent Runtime, Agent Framework, or Execution Layer to describe roughly the same thing. In this piece, "harness" refers broadly to the engineering system that wraps around a model and turns its reasoning into actions that can actually be executed — tool use, context management, memory, workflow orchestration, execution sandboxing, permission control, and auditing/observability.

If the model is the "brain," the harness is closer to the body and nervous system: the brain does the thinking, but the body determines whether that thinking can actually translate into action — what resources it can reach, which tools it can call, what operations it can perform, and how it recovers and gets traced when something goes wrong.

A shorthand that's become popular among developers captures this well:

Agent = Model + Harness

Mitchell Hashimoto, founder of HashiCorp and the creator of Terraform, wrote earlier this year about a habit he'd developed working with AI agents: every time an agent made a mistake, instead of just re-prompting it, he'd take the time to engineer a permanent fix into the agent's runtime environment so it wouldn't happen again. Engineering teams at both OpenAI and Anthropic had published related technical posts. This pattern — fix once, generalize forever — is a big part of why the industry has come to see harness engineering as being just as consequential as improvements to the model itself.

Why Is the Harness Suddenly Getting So Much Attention?

For an individual user, if an agent gets something wrong, you just re-ask. Production deployment inside an enterprise runs on a completely different logic. If an agent can query a database, call a production API, or execute a script, the first question a company asks usually isn't "how smart is it?" It's: what exactly can this thing do, and what can't it do?

Over the past year, more and more engineering teams have shifted their attention from model capability to the runtime environment around it, and a few lessons have started to stand out.

Anthropic, for instance, has written about how enterprise-grade permission control can't rely solely on natural-language constraints in a prompt. Telling a model "don't delete production data" in a system prompt is a soft nudge at best — what actually holds is a structured, enforceable permission system built into the harness layer itself. A prompt can express intent, but only system-level boundaries can actually constrain behavior.

Sarah Wooders, co-founder of Letta, has made a similarly sharp point: memory shouldn't be treated as a bolt-on feature — it should be a core part of the agent's runtime. If all of a company's accumulated business memory lives inside a closed harness it doesn't control, switching platforms later means starting from zero; everything built up along the way gets left behind.

Both point to the same conclusion: the harness isn't just about making an agent more capable — it's increasingly about how an enterprise governs its agents at all.

As Agent Harnesses Standardize, a New Question Emerges

With the release of things like the Claude Agent SDK and AWS AgentCore, building a basic agent runtime is becoming a fairly standardized capability. Workflow orchestration, tool calling, and baseline observability are now available off the shelf, through cloud services or open-source frameworks.

Which means "do you have an agent runtime" is quickly stopping being the differentiator. As harness capabilities converge across the industry, a different kind of divide starts to show up.

Data infrastructure has a well-established design principle called data gravity: as data grows larger and more interconnected, it's often cheaper and faster to bring compute to the data than to keep moving data around. Vendors like VAST Data have started applying this same logic to how AI-era data platforms should be built.

If you think of an agent as a new kind of compute, the question becomes: should the agent keep pulling data into its own runtime, or should it be built directly on top of the data infrastructure a company already has?

Right now, there are broadly two architectural approaches to enterprise agent deployment.

The standalone-runtime model: enterprise data is connected piece by piece — via MCP, APIs, connectors — into a newly built, independently running agent runtime, which then owns tool calling, workflow, and governance. This is flexible to deploy and is the approach most general-purpose agent platforms take today.

The data-native model: the agent is built directly on top of infrastructure the enterprise already has, reusing its existing data model, permission system, compute, and business components — rather than standing up a parallel data environment just for the agent.

Both approaches can produce a working agent. What differs is how dependent each one is on the enterprise's existing data infrastructure.

DolphinX: A Data-Native Approach to the Agent Harness

For enterprises that already have a mature data infrastructure, the more natural move isn't to build a brand-new agent runtime alongside it — it's to let the agent be built, from day one, directly on top of the data and compute systems the business already trusts.

DolphinDB has run in production environments for years as a high-performance data and compute platform, managing time-series, relational, warehouse, text, and vector data, handling batch, streaming, and heterogeneous compute — and, in sectors like finance, energy, and industrial operations, accumulating a large library of battle-tested business components along the way.

That's the foundation DolphinX is built on. Rather than placing the agent outside DolphinDB and standing up a separate runtime layer, we built the agent directly on the existing data and compute base — reusing the data model, permission system, and business capabilities the enterprise already has, instead of duplicating that infrastructure from scratch.

That was the founding design idea behind DolphinX, and it reflects one way we think about what an enterprise-grade agent actually requires.

The impact of this architecture isn't just about deployment mechanics — it's that problems many enterprises already solved once don't need to be solved all over again just because an agent is now in the picture.

The agent lives at the data's front door — no detours to reach it. In most agent architectures, the model has to go through an MCP layer, an API gateway, or a connector to reach enterprise data. DolphinX works differently: DolphinDB is the enterprise's high-performance data entry point, so the agent runs directly on top of the data — there's no data to "connect," because the data is already right there.

Permissions and governance are inherited from the data layer, not bolted on. When an agent invokes a skill that reads from a time-series database, it operates under the same IAM identity and access rights the business-line engineer already has. Scripts the model generates go through static code analysis that automatically blocks high-risk operations like DROP TABLE. The enterprise's existing governance boundaries don't need to be redesigned around the agent — the agent was born inside them.

Business knowledge becomes a reusable skill, not a one-off prompt. What's genuinely valuable inside most companies isn't a clever prompt — it's years of accumulated operational know-how, research workflows, and business rules. DolphinX ships with dozens of built-in skills spanning finance, streaming compute, machine learning, operations, and testing. On top of that, companies can encode their own internal expertise as private skills, so the agent doesn't have to rediscover business logic from scratch every time it faces a familiar task. A meaningful share of hallucination problems come from models lacking reusable prior knowledge to draw on — not from a shortfall in raw model capability. The knowledge base can be shared internally within an organization, without requiring uploads to the cloud or reliance on any individual's local setup.

Memory and context management work the same way. Organizational knowledge, team experience, and individual preferences can each be captured separately, then brought together within the same business context when needed. The system dynamically assembles prompts, conversation summaries, skills, and memory based on the available context budget, and developers can inspect exactly what context the model is actually using at any given moment — making agent behavior easier to understand and debug.

Taken further, once the agent stops being a standalone system bolted onto the enterprise, governance changes shape too. Agents, models, skills, MCP connections, permissions, and audit logs can all live inside one unified management layer, instead of being scattered across separate platforms that each need to be maintained on their own.

Closing Thoughts

While much of the industry debates how to constrain agents with longer prompts or more elaborate chains of reasoning, we took a more fundamental approach — giving the agent the enterprise's "DNA" from the moment it's created: its existing data model, its governance rules, its accumulated business experience.

The competition among enterprise agents likely won't be decided by the model alone — it will increasingly come down to the infrastructure the agent is built on.

If you're exploring how to bring agents into production at your organization, we'd welcome you to try DolphinX and see what it feels like when an agent is built directly on top of the data and compute infrastructure you already have.

DolphinX is available to download and try today — we'd love to hear about your use cases and experience.