Agent Framework vs. Harness: 7 Capabilities Production AI Agents Need

Most teams building agents in 2026 have had the same six-month arc. Week one, a hundred lines of Python wired to a model and three tools does something genuinely impressive. Week twelve, the same agent is a 4,000-line module full of retry logic, token accounting, transcript truncation, and a growing list of tool calls that must never run without someone clicking "yes."

None of that extra code is the agent. It's the harness — and the reason it accretes so painfully is that almost nobody plans for it up front.

1. Framework vs. harness

A framework gives you abstractions for authoring agent behavior: how to declare tools, how to structure a chain or a graph, how to pass state between steps. LangGraph, CrewAI, the OpenAI Agents SDK, Strands, Pydantic AI — these are all frameworks, and they're good at what they do.

An agent harness is the runtime layer around the model that turns a text generator into a reliable, long-running actor. It owns the execution loop itself: planning, tool dispatch, context management, sandboxed execution, approval gates, session state, and observability.

The distinction matters because the framework's job ends roughly where production begins. A framework will happily let you write an agent that blows past the context window on turn 40, calls a destructive API without asking, or leaves you with no record of why a run failed. The harness is what stops those things from happening.

You can build a harness yourself. Thousands of teams are doing exactly that right now, mostly without realizing it, one bug fix at a time.

2. The seven things a harness has to do

Here's what I'd consider table stakes, based on what actually breaks in production.

2.1 Sandboxed execution

The moment your agent writes and runs code — and useful agents almost always end up wanting to — you need isolation. Not "we validate the string before exec." Real process isolation, an ephemeral filesystem, controlled network egress, and a teardown path.

Two properties matter more than people expect. First, provisioning should be lazy: spinning up a sandbox for every run when 80% of runs never need one is pure cost. Second, secrets must never enter the sandbox. If your agent's credentials are reachable from code the model wrote, you have a prompt-injection-to-credential-exfiltration path, and no amount of prompt engineering closes it.

2.2 Context engineering

This is where naive implementations die. A long-running agent generates enormous transcripts, and the context window is a hard wall.

Four techniques, in rough order of how much they buy you:

Compaction. When history approaches the model limit, summarize older turns rather than truncating them. Truncation loses the decision that explains the current state; summarization keeps it.

Deferred tool loading. If an agent has access to twelve MCP servers with twenty tools each, loading all 240 schemas into the system prompt burns thousands of tokens before the user says a word. Load definitions on demand instead.

Large tool response offloading. A tool returns 400KB of JSON. Putting that in context is catastrophic. Write it to the sandbox filesystem and hand the model a path plus a summary — let it grep the file if it needs detail.

Sub-agents. Delegate a bounded subtask to a fresh agent with its own clean context, and return only the result. This is the single most effective way to keep a long run's context small, because the sub-agent's 30 turns of exploration never touch the parent's transcript.

2.3 Human checkpoints

Some tool calls are irreversible. Sending an email, merging a PR, issuing a refund, dropping a table. The harness needs to pause mid-run, surface the pending call with its arguments, and wait.

The important design decision is where the approval policy lives. If every agent declares its own — a per-tool permission_policy in each agent definition — then the safety of your system depends on every author remembering to set it on every sensitive tool. That's a policy model that fails silently and fails open.

The alternative is marking a tool as destructive once, centrally, at the layer that brokers tool access. Then every agent that touches it inherits the approval gate whether its author thought about it or not. Same enforcement, inverted default.

2.4 Structured session state

Agent runs are long, resumable, and frequently multi-user. "Which run was this, what turn are we on, can I pick this up tomorrow, can I share it with a colleague" are all questions with no good answer if session state is a dict in process memory.

2.5 Credential brokerage

Your agent needs to reach Jira, Salesforce, GitHub, an internal database. The lazy path is a shared service-account token in an env var. It works immediately and it's a governance dead end: downstream logs show "a service" rather than which agent acted for which user, rotation means touching every agent, and every user of the agent gets the union of all permissions the service account holds.

The harness should never see raw credentials. It should ask a broker for a scoped, short-lived token per call, ideally carrying both the agent's identity and the user it's acting for.

2.6 Model indirection

Hard-coding gpt-4o into an agent definition means a provider outage is your outage, and changing models is a code change plus a deploy. Route through a name that resolves to one or more real models, and swapping a model becomes configuration.

2.7 Observability at the right granularity

Standard LLM tracing shows you individual model calls. That's necessary and not sufficient. The unit you actually debug is the session: turns, wall-clock duration, total cost, token count, active context size, tool call count, sub-agents spawned, errors.

The metric people most often miss is active context size over the run. Watching it climb toward the limit tells you compaction is about to fire, which usually explains the quality cliff at turn 30 that nobody could account for.

Per-turn breakdown by event type is the other high-value view. A turn dominated by tool time is tool-bound; a turn dominated by model time is model-bound. Those two facts point at completely different fixes, and without the breakdown you'll guess.

3. The build/buy line

Here's the honest accounting. Sandboxing is a few weeks of real infrastructure work and an ongoing security surface. Context engineering is a few weeks plus a long tail of tuning. Approvals are straightforward until you need them to be org-wide policy. Session state is a database and some API surface. Credential brokerage is the hard one — per-user OAuth, token refresh, delegation, and rotation is a quarter of work for a team that has done it before.

That's roughly two engineer-quarters to reach parity with what hosted harnesses give you on day one, and none of it is differentiated. Your agent's value is in its instructions, its tool selection, and its domain knowledge. Nobody will buy your product because you wrote a good sandbox.

The reasonable position: if agents are a side project, use a framework and accept the ceiling. If agents are becoming the product, get the harness from somewhere and spend your quarters on behavior.

A few open-source and hosted options have converged on essentially the list above. TrueFoundry's agent harness is one worth looking at as a reference implementation — it's the open-source TrueForge harness embedded unchanged in a platform, so you can read exactly how sandboxing, compaction, deferred tool loading, and approval gates are wired rather than inferring it from marketing copy. Their session observability model is also a useful spec for the metrics list in point 7, whether or not you use their runtime. Claude Managed Agents and LangSmith's managed Deep Agents cover similar ground with different tradeoffs — notably pro-code-only definitions and per-workspace rather than per-user credentials.

4. What to do Monday

If you already have agents in production, audit against the seven points. Most teams find they have two or three, partially, with the rest living as undocumented workarounds.

Then pick the one that's actually hurting. For most teams it's context engineering, because it's the one that degrades quality invisibly rather than throwing an error. Instrument active context size per turn first. You'll likely find your agent has been silently truncating its own history for weeks.