Who really owns your loop?
Half the AI agents shipped in 2025 were orchestration code the model no longer needs. Here's how to tell which side of the framework-vs-harness line you're on — and why it decides where your failures live.
Who really owns your loop?
Most teams answer "framework or harness?" by accident — whatever they reached for first becomes the architecture, and nobody revisits the decision until production breaks. That's the problem. This isn't a tooling preference. It's an architectural commitment that decides who owns your agent loop, where your failure surface lives, and whether the next model upgrade improves your system for free or makes half your codebase redundant.
It sounds academic until you've shipped both. Teams running frameworks in 2026 are debugging orchestration bugs in code they wrote eighteen months ago, for a model that's since gotten smart enough to not need most of it. Teams running harnesses are shipping context and permission design instead — and inheriting every model upgrade for free.
This piece covers what a framework and a harness actually are, the six dimensions that separate them, why the market quietly shifted from one to the other, and how to decide which one your team should be building on.
Agent Framework — a construction kit of orchestration primitives (graphs, crews, nodes, typed workflows) that you wire together yourself. You own the loop; the model is a component you call from inside it.
LangGraph, CrewAI, Google ADK, and Microsoft's unified Agent Framework all follow the same shape. They hand you primitives — a graph structure, a crew of role-typed agents, a set of typed nodes — and leave the wiring to you. You decide the orchestration logic: how the planner routes to the right agent, when a critic re-checks output, how state persists between steps, when a retry fires, when the loop terminates.
That's real leverage when the workflow is genuinely yours to define. It's also real liability: every one of those decisions is now code you maintain. The intelligence of the system lives in your architecture. The model is powerful, but it's still just a function call inside a loop you designed, debug, and eventually rewrite.
Agent Harness — a finished agent runtime shipped by a vendor. The loop already exists: context management, tool execution, permission gates, sandboxing, sub-agents, compaction. You configure and extend it — you don't build it.
Claude Code, Codex CLI, Gemini CLI, and Oracle AI Database's Select AI Agent are harnesses. The agent loop — context manager, planner/model call, tool executor, permission gate — is built-in runtime, not application code. You extend it through skills, MCP servers, hooks, and plugins, not through orchestration logic you write and own.
The trade is explicit: you give up some control over how the loop runs in exchange for a working agent on day one, and every improvement the vendor ships to context handling, tool execution, or sub-agent coordination arrives in your system without a single line of your own code changing.
The clearest way to see the split is to look at where the loop lives — inside your application code, or inside the vendor's runtime.
The question isn't "which framework?" anymore. It's whether the loop you need already exists — and whether you should be building an agent, or building the environment one runs in.
Every framework-vs-harness conversation eventually collapses into the same six trade-offs. Get clear on these and the "which one?" question mostly answers itself.
You write the orchestration loop yourself, or the vendor ships one and you plug into it. This is the root decision — every other dimension flows from it.
Frameworks extend through code you write and maintain. Harnesses extend through configuration — skills, MCP servers, hooks, plugins — that layer on top without touching the runtime.
A framework gives you primitives and a blank canvas. A harness gives you a working agent on day one — the trade is exactly how much you get to decide versus how fast you ship.
In a framework, failures are orchestration bugs — bad routing, state corruption, retry storms — in code you own. In a harness, failures move to context design and permission scoping, which is a fundamentally different debugging surface.
If your incident postmortems keep citing "orchestration logic" as root cause, that's a framework-shaped failure surface — worth asking whether a harness would have prevented it structurally.
When the underlying model improves, framework code often needs refactoring to take advantage of new capabilities. Harness users get the improvement for free the next time the vendor ships a runtime update.
Frameworks give you total control over every decision in the loop. Harnesses give you bounded control — you trade some of that control for capability you didn't have to build.
| Dimension | Agent Framework | Agent Harness |
|---|---|---|
| Loop ownership | You write it | Vendor ships it |
| Extension | Code | Configuration (skills, MCP, hooks) |
| Abstraction | Primitives | Working agent on day one |
| Failure surface | Orchestration bugs | Context and permission design |
| Upgrades | Refactor when models improve | Improvements arrive free |
| Control | Total | Bounded — capability traded for control |
2023–2024 was the framework era. Models were weak enough that elaborate hand-built orchestration — planners, critics, routers, state machines — genuinely compensated for what the model alone couldn't do reliably.
2025–2026 is the harness era. Models got strong enough that a good harness plus well-designed context now beats most bespoke orchestration for the majority of workloads. It's the bitter lesson, replayed for agents: scaffolding you hand-build gets absorbed by the layer below you the moment that layer gets good enough to do it natively.
Even the framework vendors see it coming. Microsoft merged AutoGen and Semantic Kernel into a single, unified Agent Framework. Oracle moved the agent runtime into the database itself. The stack is consolidating around fewer, deeper loops — not more, shallower ones.
None of this means frameworks are obsolete. They still win where the workflow is genuinely custom — regulated pipelines with deterministic guarantees, deep proprietary system integrations, cases where "bounded control" isn't good enough and you need total control. That's a real category. It's just smaller than most teams assumed when they defaulted to building one in 2023.
Choosing a framework because "we might need full control later" is a real cost paid today for a hypothetical you may never hit. Most teams that reach for total control never use more than the harness's bounded control would have given them.
The framework-vs-harness decision changes where your orchestration logic lives. It does not change whether your agent's actions need to be governed before they hit production, validated at the moment they execute, and recorded for audit afterward. That responsibility sits above both architectures — and most teams on either side of the line leave it unaddressed.
A framework team writes its own state machine but rarely writes a certification gate for it. A harness team inherits a well-built loop but still configures its own skills, MCP servers, and permission scopes — and a badly scoped permission gate is a governance gap regardless of who wrote the loop underneath it.
AgentTrust OS sits at that layer, independent of which architecture you chose:
Whether your loop is a LangGraph graph you wrote or a Claude Code configuration you extended with skills, Trust Certify runs the same pre-production gate: does this agent's behavior meet the policy bar before it ever touches a real system?
Framework teams hand-code permission checks inside their state machine. Harness teams configure permission gates through hooks and MCP scopes. Trust Runtime validates every tool call against policy at execution time regardless of which one produced the call — so a misconfigured hook and a missing state-machine check get caught the same way.
Neither architecture gives you an audit trail by default. Trust Audit adds the immutable, signed record of what the agent decided and why — the same record whether the decision came out of your custom router or the vendor's built-in planner.
Not quite. A framework's opinions live in code you can rewrite. A harness's opinions live in a runtime you don't have access to modify directly — you extend it from the outside through skills, MCP servers, and hooks. That's a different layer of the stack, not just a stronger opinion on the same layer.
Regulated pipelines with deterministic guarantees, deep proprietary system integrations, and workflows where "bounded control" genuinely isn't enough still need total control. That category is real — it's just smaller than the market treated it as in 2023–2024, when weak models made elaborate orchestration necessary everywhere.
The raw API gives you the model. A harness gives you the model plus a built runtime loop around it — context management, tool execution, permission gates, sandboxing, sub-agent coordination, and compaction — already solved. Calling the API directly means you're rebuilding that loop yourself, which is exactly the framework-era pattern the harness era replaced.
Look at your last few incident postmortems. If root causes keep landing on orchestration logic — bad routing, retry storms, state bugs — rather than on context or permission design, you're paying the framework tax without a workload that requires it. That's the signal to evaluate a harness for that workload, not necessarily to rip out everything at once.
No — and we'll be honest about that. A harness gives you a well-built loop, not a pre-approved one. You still configure permission scopes, skills, and MCP servers yourself, and a badly scoped permission gate is a governance gap whether the loop underneath it is vendor-built or hand-written. Certification, runtime enforcement, and audit trails sit above the architecture choice either way.
Start from the workload, not the tool. List the workflows you're building and sort each one by whether it needs total control (regulated, deterministic, deeply custom) or would be fine with bounded control in exchange for a working loop on day one. Most teams find the second bucket is bigger than they assumed.
Confidence in every decision — from pre-production certification to post-deployment audit, whether your loop is a framework you built or a harness you configured.
See Pricing & Start Free →