← Back to essays
·2 min read·By Ry Walker

The Agent Harness Problem

The Agent Harness Problem

Every enterprise building agents right now is having the same conversation, whether they realize it or not. We built something that works for engineers. Now we need non-technical people to use it. And we cannot dumb it down. This is not a UX problem. It is an architecture problem — and the architecture lives in the harness around the model. The harness is where every interesting question lands: how do you serve layered roles with layered guardrails, how do you wire skills to real systems, how do you stay flexible across CLIs and models and clouds, how do you carry context that the model never had. Six atomic posts, one per axis:

The model is fine. The harness is starving. Whoever feeds it best wins the next decade.

— Ry

Key takeaways

  • Enterprise agent systems need layered interfaces that serve technical builders and non-technical operators without dumbing anything down.
  • Skills defined as markdown are insufficient — real skills require tools, tests, memory, and deep integration with the systems they operate on.
  • Platforms must support multiple CLIs, multiple models, multiple repos, and self-hosted deployment, because no enterprise wants to be locked into one vendor's harness.
  • The agent harness layer — Claude Code, OpenCode, or equivalent — is fully commoditized. The differentiation lives in context engineering, orchestration, and the tool layer.
  • The iteration loop is the product: building an agent is easy, getting an agent right is the hard part, and conversational refinement beats consulting engagements.
  • Context engineering, not infrastructure plumbing, is the work that determines whether an agent system actually functions.
  • Companies with mature dev tooling build most of their agent stack themselves. Companies without it buy off the shelf — and that buy cohort is the real market opportunity.
  • Agents will break out of engineering orgs in 2026. The same primitives that power coding agents serve GTM, customer success, and operations — but the non-engineering versions are lighter because they need no environment setup, no CI/CD, no test suite.

FAQ

What is the agent harness?

The harness is everything around the model — the sandbox, tools, system prompts, memory, governance, and iteration loop. It is the layer that turns a capable model into a usable agent inside an enterprise.

Why are markdown skills insufficient for enterprise agents?

Markdown descriptions tell an agent what exists but not how to operate on it reliably. Real skills need executable tools wired to specific endpoints, automated tests, schema validation, and memory of prior runs so the agent does not waste effort rediscovering the environment.

Why must agent platforms support multiple CLIs, models, and repos?

Enterprises already have multiple model contracts, mixed coding CLIs, and complex repository topologies including monorepos and submodules. A platform locked to one harness inherits that harness's bugs forever and cannot serve customers who need self-hosted or EU-resident deployment.

Is the agent harness itself a defensible product?

No. The harness — whether Claude Code, OpenCode, Goose, or Aider — is commoditized. Companies migrate between them freely. The defensible layers are context and memory, orchestration and session state, and the tool integrations that wire agents to internal systems.