Key takeaways
- An agent harness is everything around the model that turns reasoning into action.
- Component checklists no longer separate two options.
- Five runtime levers do: permission modes, approval gates, iteration budgets, state persistence, evaluation hooks.
- Synthesized from published work, not a bench test.
You have read the explainers. You can recite the component list. And you still cannot answer the question your team is actually asking, which is whether to adopt the harness everyone is talking about, build on an SDK, or keep the scripts that already work. That gap is not your fault. Almost every published treatment of the agent harness stops at anatomy, and anatomy tells you nothing about what the thing will do while you are not watching.
What is a harness in AI, in one pass
Databricks puts the definition plainly: an agent harness is the software infrastructure wrapping a language model so it can act on tasks instead of only responding to prompts, supplying the tools, memory, execution environments, and guardrails the work requires. The mechanism underneath that is a loop. The harness manages the loop between the model and the world outside it, handling context and executing the tools the model asks for. That loop is the whole product. The model never touches the outside world directly.
Which is also the answer to why it is called a harness. The word is doing its ordinary job here: something you strap around a powerful thing to point it at work and hold it inside a boundary. It is not an AI coinage, and no standards body defines it now that AI has borrowed it. Two vendors can both use the term correctly and mean different systems, so the label on the box tells you nothing you can compare.
That imprecision is not academic. Engineers keep asking, in public, how "agent harness", "code harness" and "agent SDK" actually differ from each other, and the honest answer is that the boundaries are contested rather than settled. Nobody has the authority to rule on it, which leaves you comparing runtime behavior instead of vocabulary. That turns out to be the better comparison anyway.
The harness is everything you can change
Here is the reading of the slogan that does some work. Addy Osmani defines the harness as every piece of code, configuration, and execution logic that isn't the model itself. Read that as an architecture diagram and it is a shrug. Read it as a scope statement and it is the point of the entire discipline: unless you are training, the harness is the complete set of things you are allowed to change.
Vivek Trivedy's framing at LangChain lands in the same place from the other side. Agent = Model + Harness, where the model holds the intelligence and the harness is what converts that intelligence into finished work. Which makes harness engineering the design discipline, not a plumbing task you hand to whoever has capacity. Databricks goes further and says harness design directly shapes agent performance, with context management, orchestration, and verification able to matter as much as the choice of underlying model.
Take that claim seriously but not literally. It is a directional argument from people who build this layer for a living, not a controlled comparison, and it has a hard floor. On a task the model simply cannot do, no amount of agentic engineering rescues it. What the claim gets right is the part you can act on: between two teams running the same model, the one with the better runtime ships and the other one keeps babysitting.
The component floor everyone already agrees on
Give the consensus its due, because it is correct as far as it goes. The recurring component set, as LangChain lays it out, is a durable filesystem for storage and context management, bash and code execution as the general-purpose tool, sandboxes for executing and verifying work, and memory plus search for continual learning. The standing problems that set exists to fight are context rot and long-horizon execution.
Two capabilities carry the long tasks specifically. Planning tools let an agent decompose an objective and track its own progress as it learns. Parallel delegation to subagents lets independent subtasks run with isolated context.
Now the limit of that floor, stated plainly, because the top results do not state it. A component list describes what a harness contains, never what it does when left alone. Two candidates can both check filesystem, sandbox, memory and subagents and still behave nothing alike on a Friday night run, because none of those four boxes says who approves a write, what stops a loop, or what survives a crash. That is why the definitional pages feel unhelpful the moment you are holding a real decision. They are measuring the part that no longer varies between serious options.
Five levers the README never shows you
Micheal Lanham's framing of the 2026 agent problem is the sharpest correction to that. The frameworks look similar from the outside, and the capability differences hide in places nobody puts in a README: permission modes, approval gates, iteration budgets, state persistence, and evaluation hooks. The boundary between an assistant and an agent, on this reading, sits in the runtime rather than the model. The load-bearing question is not whether the model can reason. It is what the harness is allowed to do between your turns.
Translate each lever into a question you can ask a candidate harness out loud, and watch how fast two "identical" options diverge.
What is the default permission mode? Not what modes exist. What happens when a junior engineer clones the repo and runs it without reading the config. Defaults are the setting most teams actually run.
Where does the approval gate fire? Before the plan, before each tool call, or before the write. A gate on the plan and a gate on the write are different products with the same feature name.
What caps the iteration budget? Turns, wall-clock, tokens, or nothing. "Nothing" is a real answer, and it is how a bad loop becomes a bill.
What survives a crash? If the process dies at minute forty, does the run resume from its last checkpoint or start over. This is the lever that decides whether long-running work is viable at all.
Where do evaluation hooks attach? Per tool call, per run, or nowhere. If nothing observes the run, you cannot tell a good agent from a lucky one.
Treat these five as a starting checklist you extend, not a closed taxonomy. The frame comes from one practitioner's essay rather than a survey, and it earns its place by being specific, not by being complete.
The lever table: what each choice costs you
| Lever | The choice you make | What it costs | What it prevents | Floor component it touches |
|---|---|---|---|---|
| Permission mode | Auto-approve reads, gate writes and network calls | Slower first hour, more prompts during setup | An agent editing files nobody asked it to touch | Filesystem, sandbox |
| Approval gate | Fire on the plan, then again on any irreversible action | A human in the loop on a run that could otherwise be unattended | A confident wrong plan executing to completion | Planning tools |
| Iteration budget | Hard cap on turns plus a wall-clock ceiling | Some legitimate long tasks get cut off mid-run | Silent loops that burn a day of tokens on one file | Bash and code execution |
| State persistence | Checkpoint after every completed step to durable storage | Write overhead, plus a real schema you have to maintain | Losing a long run's work to one crashed process | Filesystem, memory |
| Evaluation hooks | Log every tool call and its result, keep failed runs | Storage, and someone has to read the logs | Shipping an agent nobody can debug after it fails | Memory and search, subagents |
Use this as the structure for your own evaluation, not as the answer. The lever names come from published work; the rest of the table does not. The recommended choice in column two, the cost in column three, and the mapping onto the floor components in column five are all reasoned from how the mechanism behaves, not measured on a workload and not lifted from anyone's benchmark. Argue with the cells. Then fill it in for two real candidates, and the comparison stops being a vibe.
Where the named harnesses sit
The map first, since that is what most people come for. The open-source layer now holds LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, Google ADK, Pydantic AI, CrewAI, Strands Agents, Mastra, the Vercel AI SDK, and the Microsoft Agent Framework, all occupying roughly the same ground. Building agents used to be a patchwork of scripts and trial and error. It is now a field with ten credible entrants and no way to tell them apart from their feature pages.
On the Claude question specifically, Anthropic is direct: the Claude Agent SDK is a general-purpose agent harness, built for coding and for other tasks that require the model to use tools. So yes, a coding agent of that shape is a harness in the strict sense. Anthropic's own long-running-agent guidance is the natural place to look for agent harness best practices from a vendor that ships one, with the caveat that vendor guidance is scoped to vendor architecture.
GitHub is where the ecosystem is being catalogued. A community-maintained curated list of agent harnesses is public there, which tells you something real: the field is being indexed faster than it is being evaluated. An index is not a comparison, and nobody has published the comparison.
Two honest gaps, since this section maps the field rather than ranking it. Naming ten frameworks is not evaluating ten frameworks, and nothing above should be read as a ranking. And if you came looking for AWS's position, you will not find it here, because the harness axes on this page have not been applied to an AWS offering anywhere in public. Our own view of where the orchestration tooling is heading sits in a separate piece.
Why nobody can honestly tell you the best agent harness
You want a name. There isn't a defensible one, and here is the mechanical reason rather than a hedge.
The comparisons you can find enumerate frameworks. They list what each one supports, which is the component floor again, and the floor does not discriminate. None of them scores candidates on default permission mode, gate placement, iteration cap, crash recovery, or hook surface. Add the terminology problem on top: when practitioners cannot agree whether a harness, a code harness, and an agent SDK are the same category, two "harness comparisons" are not measuring the same object, and their rankings cannot be composed.
That is genuinely unsatisfying if you arrived wanting a verdict, so take the substitute. Pick your two real candidates. Answer the five lever questions for each, in writing, from the code rather than the docs. The differences will not be subtle, and you will have spent an afternoon instead of a quarter. That is the fastest defensible answer to "what is the best AI harness" that anyone can give you right now.
Building your own, and when not to
Most teams should not build one. Build when your constraint is a lever nobody exposes: you need approval gates on specific functions rather than tool categories, or your compliance posture requires that state persist somewhere the vendor cannot reach. Adopt when your constraint is capability, because the ecosystem is genuinely good at capability now.
If you are building, the order matters more than the stack, and the order follows the component floor. Start with the loop and exactly one tool, so you can see the harness handling context and executing calls on the model's behalf. Add the durable filesystem next, before you need it, because retrofitting context management onto a stateless loop means rewriting the loop. Put the sandbox in before you widen tool access, not after the first incident, since executing and verifying work is the job it exists for. Add memory and search when the agent starts repeating mistakes across runs, and planning tools plus subagents when a task stops fitting in one context window. Then set each of the five levers explicitly, including the ones where you are happy with the default, and write down why.
That last step is the one teams skip, and it has a signature failure. Nobody sets an iteration budget, because no default advertises itself as missing. Then a run gets stuck retrying a failing test at three in the morning, and you find out what unbounded means from a bill. Every lever left at its default is a decision you made without noticing. Our longer treatment of building agentic AI systems walks the same sequence with more of the surrounding architecture, and the minimal harness case argues the other side of the build question.
This sequence is derived from the published component descriptions above and the levers, not from a build someone walked end to end. Treat it as a build order to argue with, not a tutorial.
Agent harness best practices break when a second team starts building
Everything above assumes one team and one harness. The failure mode arrives with the second one.
Databricks names it agent sprawl, and prescribes shared harness infrastructure against it: centralized governance, shared evaluation, and observability across the agents an organization runs. Map that back to the levers and the mechanism is obvious. Sprawl is what you get when every team picks its own default permission mode, sets its own iteration cap or none, and nothing observes the aggregate. Five harnesses, five blast radiuses, one incident review where nobody can reconstruct what ran.
The broader pattern is the same one the levers point at. What slows agent deployment down is usually not model intelligence. It is how agents get built and run inside the organization, which is an organizational property rather than a technical one.
Concede the cost, because centralizing is not free. A shared harness slows the first team down to speed the fifth one up, and the first team will notice immediately while the fifth team's benefit stays invisible. Do it when you can see the third team coming, not the second.
How to tell your harness is working
Five checks, one per lever, all observable, none requiring an opinion.
Can you name the current default permission mode without opening a config file? Does a write action stop and wait for a human at the approval gate? Does a long run terminate on its own iteration budget rather than on your patience? Does state survive a restart, tested by actually killing the process? Do the evaluation hooks leave a failed run's artifact you can read tomorrow?
Five yeses means the thing is controllable, which is the whole claim these checks can make. None of them says the agent does the task well, and none of them touches the model. Controllability is a lower bar than quality, and it is the bar the harness is responsible for, since the harness is the part that isn't the model. Task quality needs evals against your own workload, which is a separate build and a separate page. If you are looking for proof your agent is good, do not stop here.
Where to start this week
Start with the harness you are already running, and start from what it is. The harness is every piece of code, configuration, and execution logic that isn't the model, which makes it the entire surface you are allowed to change. So change it on purpose. Answer the five lever questions for it, in writing, from the source rather than the README: what is the default permission mode, where does the approval gate fire, what caps the iteration budget, what survives a crash, and where do the evaluation hooks attach. One of them you will not be able to answer, and that gap is the work. It is also the cheapest available proof of the point this page keeps making, which is that the harness, not the model, is the part you can change.
Rifty exists for the readers whose gap turns out to be control rather than capability. Our position is that a harness should be legible, steerable, and reversible at every step, with control as a first-class feature rather than a setting, and nothing irreversible shipping without operator sign-off. That is a narrow bet and it is not for everyone. Rifty is by introduction only and built for operators who want function-level reversible control, so if what you need is a batteries-included framework you can install this afternoon, the open ecosystem is the right place to shop and you should go there first.
Either way, do the five questions before you shop. You cannot compare two harnesses on axes you have not written down.