Agent Framework vs Agent Harness: What I Would Build On in 2026

The short answer

Build on your own harness unless a run must survive restarts, wait days on a human, or route work between several agents. Those three requirements are the framework route's home ground, and hand-building them is the most expensive version of this decision. Everything else - one agent, minutes-long runs, mistakes a retry can absorb - is loop-shaped work, and a framework charges you a learning tax and a monthly churn tax for features that work never touches. There is also a middle lane that did not exist in this form two years ago: SDK primitives (the Vercel AI SDK's ToolLoopAgent, the OpenAI Agents SDK) that hand you the plumbing and leave the loop yours. My default in 2026 is that middle lane's plumbing under my own loop. The rest of this post is the evidence, route by route.

Two earlier posts are the deep dives behind this one. If you want the loop itself, read the 200-line TypeScript harness post. If you want the buying discipline - name the feature, name the week - read my framework decision guide. This post is the comparison those two circle around: the whole current field, on one table, against the harness.

Two routes, defined by who owns the loop

A harness is everything around the model that makes an agent safe to run: the loop that calls the model, the tool registry, the context you assemble, the limits, the approval gates, the verification. On the harness route you write that machinery yourself, once, in code your team can read top to bottom. On the framework route you adopt that machinery as a library, with its own concepts - graphs, nodes, checkpointers, workflows, sessions - and your agent becomes configuration inside it.

The distinction that matters is not features. It is ownership. When a framework route agent misbehaves, the cause can live in your code, the model's output, or the layer between them that assembled the prompt for you. When a harness route agent misbehaves, the first two are the only candidates. Anthropic's own engineering guidance makes this point from the vendor side: in "Building effective agents", the company reports that the most successful implementations it saw used simple, composable patterns rather than complex frameworks, and warns that frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug". That is a model vendor telling you the abstraction has a price. It does not make frameworks wrong. It makes them a purchase, and purchases get compared. So let us compare.

The framework field in November 2026

The framework route is not one thing anymore. Here is the field as it stands this month, from each project's own documentation:

Read the durability column carefully, because it is where the marketing and the documentation part company. LangGraph's checkpointer is the real thing: its docs describe a snapshot of graph state saved at each super-step, and three durability modes - "exit", "async", and "sync" - that let you choose how much state a crash is allowed to lose. Mastra's workflows genuinely suspend and resume from snapshots. The OpenAI Agents SDK's sessions, by contrast, persist the conversation, not the run: if the process dies halfway through a five-tool sequence, you resume from the last persisted turn, not the last tool call. And the Claude Agent SDK is the interesting hybrid: not a framework you configure, but a finished harness you adopt - the same tools, agent loop, and context management that power Claude Code, programmable in TypeScript, sessions included. It is the harness route with someone else's harness.

What each route costs to own

Feature lists will not settle this, because both routes can eventually do everything on the list. Bills settle it. So here is the honest way I compare them: total engineer-days to build and to own, month by month, as the agent's shape changes. I built a small model of it. The constants are my estimates from shipping both routes, printed inside the widget so you can argue with them. The shape is what I am asking you to trust.

Two readings matter. First, at the default settings - one agent, runs that finish in minutes - the framework never catches up: you pay roughly six days to learn and wire it properly, then a day a month in upgrades and abstraction-debugging, for a machine that does what two days of loop code does. Second, drag the run length to days, or the agent count up, and the harness line bends hard: the day you need restart survival, you are not adding a feature, you are building a second system - checkpointing, resume semantics, idempotent replay - and the framework's tax suddenly reads as a discount. Neither route is cheaper. Each is cheaper somewhere, and the crossover is a property of your agent's shape, not of the tools' quality.

Head-to-head: the eight rounds that decide it

Four of these rounds deserve prose, because the table flattens them.

Debugging. This is the round I weight most heavily, because agents fail in production in ways demos never show. In my harness, when a run goes wrong I open one file: the messages the model received are the messages in the array, and the tool results are what the handlers returned. In a framework, my first hour on a bad run has repeatedly gone to a different question: which component assembled this prompt, and what did it leave out? Framework tracing genuinely helps once you have thousands of runs. Below that scale, it is a viewer for a problem you could have read directly.

Durability. This is the round the framework route wins outright, and it is not close. Restart survival done correctly means checkpointed state, resume that does not re-run completed steps, and side-effect tools that tolerate replay. LangGraph's documentation treats this as the core of the product, down to pending writes from nodes that finished before a failure. I have built the homemade version of this. It worked, and it was the least tested, most feared code in the system. If your runs cross human waits measured in days, buy this round. Do not build it.

Churn. Version trackers recorded the JavaScript LangGraph package at 1.4.21 in early October and at 1.7.3 by November 10: several minor releases in about a month, each a small chance that a default moved under your agent. The OpenAI Agents SDK ships at a similar pace, roughly a minor a month. None of this is malpractice; the field is young and moving. But it is a standing monthly cost that lands on the framework side of the ledger, and it compounds with team size, because every upgrade is reviewed by whoever owns the agent that quarter.

The platform bill. The libraries are free, and I want to be precise about that, because "frameworks cost money" is its own lazy claim. What costs money is the platform layer teams adopt with them. LangSmith, LangChain's tracing and deployment platform, is free for one seat with 5,000 traces a month; Plus is $39 per seat per month with 10,000 traces, and compute and storage meter on top ($1.50 per compute unit, $1.00 per storage unit, per the published pricing). A five-person team is $195 a month before usage. That can be worth every cent. It should still appear in the comparison, because the harness route's equivalent line is zero: your logs live in your stack, and the cost controls I put in every agent are plain numbers in your code either way.

Where the framework route genuinely wins

Three situations, stated as strongly as I can state them, because a comparison that cannot name the other side's best case is an advert.

First, runs that must not restart. An approval flow that waits two days, a research run that costs real money per attempt, a migration agent halfway through a customer's data: rerunning from the top is either impossible or irresponsible. Checkpoints plus idempotent tools are the correct engineering, and LangGraph or Mastra ship it today.

Second, genuinely multi-agent systems. Not one agent with many tools wearing a trench coat, but several agents with shared state and result-dependent routing. Graphs make those routes explicit and testable. In a loop, that routing becomes the worst code in the repo within a quarter.

Third, teams that need to inspect every run. Thousands of runs a day, support asking why this one customer got this answer: a trace tree you can click beats a log stream you grep. Frameworks wire this up; on the harness route you will wire it yourself, later, under pressure.

If your agent lives in one of those three situations today - not in a roadmap, today - the rest of this post is a formality. Take the framework route, and take it on purpose.

Where the harness route genuinely wins

The harness wins on the properties that matter every ordinary day. You can read the whole system. You can test it with a stub model and no API key, the way I tested the 200-line loop: turn limit fires, cost budget fires, the repeat-call guard fires, an unapproved write stays blocked. Your tool arguments are validated by schemas you wrote - the pattern in my Zod contract post - before a handler ever runs. Your dependency surface is a model adapter and your own code, so a bad week in someone else's release cycle is not your bad week.

It also wins the argument nobody puts in launch posts: most agents are small. One agent, a handful of tools, runs measured in minutes, inside a product whose team has other work. For that agent, the framework is the largest, least understood dependency in the repository, adopted to solve problems the agent does not have. Anthropic's guidance lands here again: add complexity only when it demonstrably improves outcomes. A loop you understand demonstrably works. That is the bar a framework has to clear, per agent, not per industry.

Five questions settle which side of this your agent is on. They are not the questions from my earlier decision post; those were about buying a feature. These are about shape and cost:

The stack I actually build on

Enough comparison. Here is my own default, the thing I reach for when a client or my own product needs an agent in TypeScript today.

I start with SDK plumbing and my own loop. Concretely: the Vercel AI SDK for provider handling, streaming, and tool-call parsing - I compared it head-to-head with TanStack AI in that post and it earns its place as plumbing - with ToolLoopAgent available when a sub-problem is genuinely loop-shaped and self-contained. But the agent's spine is mine: my messages, my registry, my limits, my approval gates, my verifier. That split is the whole strategy. The SDK absorbs the churn that is pure plumbing (provider quirks, parsing edge cases), and the parts that encode my product's decisions stay in code I control.

Two exceptions. When the agent's job is working in a codebase - reading files, editing, running commands, verifying with tests - I adopt the Claude Agent SDK instead of building the harness, because that harness already exists, is maintained by the team that knows the failure modes best, and its sessions and permissions are the parts I would otherwise spend weeks rebuilding. And when a client's requirement sheet says runs must resume after deploys and wait on humans for days, I start on LangGraph and do not apologize for it: that is the checkpointing round, and I have already told you who wins it.

Notice what this default is not. It is not "never use frameworks". It is a default with named exceptions, which is what a route decision should be. The failure I see in the wild is not the wrong route. It is the unchosen one: the framework adopted because a tutorial opened with it, or the loop still running a workload it outgrew a year ago.

Before you commit: six checks

Whichever route the picker and the simulator pointed you at, run these six checks on the real agent before you call the decision made. They are route-agnostic, and in my experience they predict regret better than any feature matrix:

1. Name the feature and the week. If you chose a framework, you can name the feature you are buying and the week you would miss it. If you chose a harness, you can name what you are deliberately not building yet.
2. Kill the process mid-run. Do it, do not theorize about it. Watch whether the run reruns, resumes, or corrupts, and confirm that is the behavior your users were promised.
3. Put an idempotency key on every side-effect tool. Any route that can resume can replay. A checkpoint never stopped a double charge; a key derived from the run and the step does.
4. Log the exact request sent to the model. Every run, no exceptions. When a route assembles prompts for you, log the assembled result, not the template you believe produced it.
5. Limits as numbers in code. Maximum turns, maximum spend per run, a repeated-call guard. Checked where you can point at them, not inherited from defaults you never read.
6. Write down the exit signal. The condition that would make you switch routes: a run that starts waiting days, a second agent, churn eating a day a month. Decided now, it is a tripwire. Decided later, it is an argument.

The same six, in a checklist that keeps your progress in this browser:

My verdict

For most teams building agents in 2026, I would build on the harness route - specifically, your own loop over SDK plumbing - and I would treat a graph framework as a targeted purchase for the day durability or multi-agent routing becomes a requirement you can point at, not a fear you can imagine. That is the same destination my earlier posts reached from other directions, and this head-to-head is why I still land there after comparing the whole field: the framework route's real advantages are narrow, deep, and decisive inside their territory, and its costs are broad, shallow, and charged every single month outside it.

The verdict flips under three conditions, and I will state them as plainly as the pick. Flip to a framework when runs must survive restarts and human waits measured in days. Flip when several agents share state and route work by results. Flip when your team must inspect any of thousands of runs on demand. Inside those conditions, LangGraph is my framework pick for its checkpointing depth, Mastra when the team wants the workflow engine and memory in one TypeScript-native box, and the Claude Agent SDK whenever the job is Claude Code's job, whatever route you call that.

If you are wiring an agent into a Next.js and NestJS product and want the route chosen on your workload rather than on a launch post, tell me about the project. The route decision is usually the cheapest week of the build and the most expensive one to get wrong.

FAQ

What is the difference between an agent framework and an agent harness?

The framework gives you someone else's loop, state model, and runtime: you configure agents, tools, and graphs inside it. A harness is the same machinery written by you around your own loop: your messages array, your tool registry, your limits. The difference is who owns the runtime, and who pays when it needs to change.

Which agent framework should a TypeScript team pick in 2026?

If durability is the requirement, LangGraph has the most complete checkpointing story in the field, with durability modes you can tune per run. If you want a TypeScript-native framework with workflows and memory in one box, Mastra is the closer fit. If you only need agent primitives, the Vercel AI SDK's ToolLoopAgent or the OpenAI Agents SDK will feel lighter than either.

Is LangGraph worth it for a single agent?

Usually not. A single agent that runs for minutes and can be rerun on failure gets nothing from a graph runtime except its learning curve. LangGraph starts paying when a run must survive restarts, wait on humans, or route work between several agents, and cannot simply be rerun from the top when it fails.

What does the framework route actually cost?

The libraries are free. The bills are your time (learning the model, upgrading through fast release cycles), any platform you adopt (LangSmith Plus is $39 per seat per month, with usage billed on top), and the model tokens both routes pay. A harness replaces the platform and learning bills with your own build and upkeep time.

Can I start with a harness and move to a framework later?

Yes, if you shape the harness for it: tools as plain objects with schemas and handlers, the model behind one interface, limits and approvals as separate functions, and idempotent writes. Migration then means replacing the loop, which is days of work. I detailed the full path in my framework decision post.

When is the Claude Agent SDK the right choice?

When the agent's job looks like Claude Code's job: reading and editing files, running commands, working in a repo or a filesystem. You are adopting a finished harness rather than building one, sessions and permissions included, in exchange for building on Anthropic's models and its commercial terms.