Agent Harness vs Runtime vs Framework: The Terms, Untangled

“Do I need a framework, a runtime, or a harness?” reads like one question with three competing answers. The three words name overlapping layers of the same stack, and even the people who coined them admit the boundaries blur. Here is a clean map, plus an honest look at where the experts still disagree.

The words show up together in agent discussions, in vendor docs, and in the same sentence on a launch blog. A framework, a runtime, and a harness sound like three choices you pick between. They are closer to three floors of one building, stacked loosely, with doorways nobody quite agrees on. That is why the phrase “agent harness vs runtime” turns up so often, as if you had to choose one and drop the others.

Here is the short version. A framework is the library you build an agent with. A runtime is the environment that executes and scales it. A harness is the assembled wrapper that turns a model into a working agent. This guide walks each layer, maps them to a web-dev analogy, and then shows the five reputable sources that place the harness in five slightly different spots.

The same confusion drives the “agent harness vs framework” question, which lines up two layers as if you had to pick a winner. You rarely do. Once the jobs are clear, the versus melts into a stack, and the only real decision left is which layer your setup has not built yet.

The Direct Answer: Three Layers, Loosely Stacked

A framework is the library you build an agent with. A runtime is the environment that executes and scales it. A harness is the assembled wrapper that turns a model into a working agent. They stack as layers, and the boundaries between them are genuinely fuzzy.

Picture the model as the engine at the center. The harness is what wraps that engine so it can do real work: it runs the loop, calls tools, holds memory, and applies guardrails. A framework is the toolkit you reach for while assembling that wrapper. A runtime is the layer underneath that keeps the whole thing running, scaling, and recovering when something breaks.

The reason the terms feel slippery is that one product often spans two layers at once. LangGraph is described by its own makers as both a runtime and a low-level orchestration framework. When a single tool is two layers, any tidy diagram is already a small fib. So hold the layers loosely for now, and treat any single-label claim about one of these products as a simplification.

None of this is settled vocabulary. The words are only months old in this specific sense, and the people using them are still negotiating what belongs where. That is why the honest answer starts with the layers and their jobs, and saves the exact stacking order for later, once the jobs are clear.

The Web-Dev Analogy That Makes It Click

If you have shipped a web app, borrow the mental model you already have. Node.js is the runtime, Express is the framework, and Next.js is the harness: opinionated and batteries-included. It is the fastest bridge into the three agent layers, with one caveat about who actually said it.

In web development, Node.js is the runtime your code runs on. Express is a framework for building a server, handing you routing and middleware as composable parts. Next.js sits on top and bundles routing, rendering, and sane defaults, so you ship a working app without wiring every piece. Map that upward and the agent layers line up: runtime at the base, framework in the middle, harness as the ready-to-run top.

The caveat matters for accuracy. This Node, Express, Next mapping circulated through community discussion, and a DataCamp beginner’s guide even credits it to Harrison Chase of LangChain. The specific web-dev framing is absent from his actual post. What Chase gave the field is the naming itself: he labeled LangChain a framework, LangGraph a runtime, and DeepAgents a harness, and he was upfront that the word harness was new to him too.

Chase also flagged the obvious problem with any tidy analogy. He wrote that there is still “murkiness and overlap,” and readily admitted “the lines are blurry,” noting that LangGraph “is probably best described as both a runtime and a framework.” Use the analogy to get oriented, and keep his caveat handy for the moment the neat picture cracks.

What Each Layer Actually Owns

Each layer owns a different job. A framework gives you composable primitives to assemble yourself. A runtime handles execution, state, durability, and scaling. A harness bundles the loop, tools, memory, and guardrails into something you can run today. The table below pins each one to a product.

A framework is where you have the most control and the most assembly work. LangChain gives you primitives for reasoning steps, tool definitions, prompts, and memory, and you wire them together yourself. You get flexibility, and you own the integration. That is the trade every framework makes with you. You move fast on custom behavior, and slow on anything the primitives do not cover yet.

A runtime is the execution layer you stop thinking about once it works. It runs the agent, persists state between steps, scales under load, and recovers when something fails. LangGraph is marketed for exactly this, described by its makers as “an agent runtime and low-level orchestration framework,” which is why it keeps showing up in both columns. The payoff is that recovery becomes the platform’s job, so you stop hand-coding retries and state-saving around every failure.

A harness is the layer that hands you a working agent. It wraps the model with the loop, the tools, memory management, and guardrails already assembled. Claude Code is a clear example: its own docs call it “the agentic harness around Claude,” providing the tools, context management, and execution environment that turn a language model into a coding agent. The cost of that convenience is depth of control, since the assembled loop is harder to reshape.

One line runs through all three: how much each layer hands you, and how much it leaves you to build. A framework hands you the least and keeps the most control in your hands. A harness hands you the most, a working loop out of the box, so you start fast and give up some control later. A runtime sits between them, lifting the execution weight while the agent logic stays yours.

Where the Sources Disagree (the Honest Part)

Here is the part most explainers skip. Five reputable sources broadly agree the harness sits near the top, then disagree on almost everything below it. They flip the order of framework and runtime, split off a fourth term, and label single products two ways at once. The map below lays it out.

The sharpest split is the stacking order underneath the harness. Analytics Vidhya orders the layers framework, then runtime, then harness, putting the framework at the base as the thing you build with. Harrison Chase’s naming runs the other way: his stack puts the runtime at the base, the framework above it, and the harness on top. Same three words, inverted foundation.

Credal draws the line by responsibility. It calls the harness “the application-layer scaffolding that turns a model into an agent” and the runtime “an infrastructure-layer execution environment where the agent actually runs.” In its words, “the harness decides what should happen next; the runtime carries it out,” which sets the harness above the runtime as the application layer.

HuggingFace adds a fourth word and refuses to blur it. Its agent glossary defines the harness as “the execution layer inside the agent: it calls the model, handles its tool calls, decides when to stop.” It then separates “scaffold” as the behavior-defining layer the model reads: the system prompt, tool descriptions, parsing, and what carries across steps. Harness is the loop that runs; scaffold is what the model sees.

Why the Disagreement Exists

The vocabulary is only months old, and vendors define it to fit what they ship. A company with a strong runtime frames the runtime as the foundation. A company with a batteries-included product calls that a harness. The words are marketing surface as much as technical spec, and that is fine once you know it.

Chase said as much when he introduced the naming. He readily admits there is still “murkiness and overlap,” and asked openly for feedback. HuggingFace is just as candid, noting that “many of these terms don’t have universally accepted definitions yet, and different frameworks use the same word differently.” When the people defining the words tell you the definitions are unstable, believe them.

So the disagreement does not mean anyone got it wrong. It is a young field naming its parts in real time, with each namer standing in a slightly different spot. The practical response is to stop arguing about the labels and start asking what a given tool actually does for you.

A Practical Way to Tell Them Apart

Skip the labels and ask what the thing does for you. “Gives me building blocks to assemble” points to a framework. “Runs and scales my agent in production” points to a runtime. “Hands me a working agent today” points to a harness. Function beats terminology every time.

This function-first test cuts through the vendor framing. When a tool markets itself as all three, run the test on each capability on its own. Does it give you composable parts to wire up? That capability is framework work. Does it persist state and recover from a crash by itself? That is runtime work. Does it ship with a loop, tools, and memory already connected? That is harness work.

The test also handles the LangGraph problem. LangGraph offers primitives you compose, which is framework behavior, and it executes and persists agents, which is runtime behavior. Instead of forcing one label onto it, name the capability you are using in the moment. You lean on its framework side when you assemble, and its runtime side when you deploy.

You can run the same check on a product you already use. Claude Code hands you a working coding agent with tools and context management wired in, so you are leaning on a harness. Drop down to LangChain to build a custom agent from parts, and you are working at the framework layer. The label follows the function.

Which One Is Your Stack Missing?

Turn the question around. Instead of asking which label is correct, ask which job is unfilled. A framework with no durable runtime falls over under load. A harness with no evaluation loop drifts in silence. A runtime with no opinionated harness leaves you assembling the agent by hand. Find the empty layer.

Map your stack to the three jobs and the gap usually shows itself. If you have composable parts but nothing that persists state or recovers from failure, the runtime is your hole. If you have solid infrastructure but keep hand-wiring the loop, tools, and memory for every project, a harness is what you are missing.

The most common gap is the quiet one, the layer you do not notice until an agent starts failing in production. A harness can run beautifully and still drift, because a running loop tells you nothing about whether the agent is getting better or worse over time. That is the evaluation gap, and closing it is the heart of harness engineering.

So the opening question, framework, runtime, or harness, was never really a choice among three. Most production stacks use all three: a framework to build with, a runtime to run on, and a harness to tie it together. The useful question is which of those jobs your setup has not covered yet. Answer that, and the vocabulary stops mattering. For the layer next door, see how a harness compares with a framework; for the base definition, start with what an agent harness is; and for the protocol that connects tools, read agent harness vs MCP.