The Harness Is Becoming the Runtime

A long-running agent dies at the wrong moment. Not an exception you wrapped in a try/catch. The laptop sleeps, a deploy rolls the process, the container gets recycled, and the thing that was six hours into a job comes back knowing nothing.

The tool call that was halfway out the door either never fired or fired twice. The agent cannot tell you which. Whatever it had reasoned its way to is gone, and you are paying tokens to watch it rediscover it.

For a demo, you shrug and restart. For anything a business leans on, that is the whole problem.

The most important thing that happened to agents this year was not a smarter model. It was durability, and it is quietly moving inside the harness.

The year durability ate the agent stack

Durable execution is not new. It grew out of workflow orchestration, the idea that you record each step’s result in a log so a crashed process can replay deterministically and skip the work it already finished. That machinery ran quietly in the back office for years. In 2026 it walked straight into the agent loop, because an agent loop turns out to be the exact shape of problem durable execution was built for.

Restate said it cleanly back in June of last year: agents behave a lot like distributed systems, where “every tool call is a remote hop, every user interaction is a pause, every retry risks doing the same work twice.” Once you see an agent that way, the back-office plumbing stops looking like overkill and starts looking like the missing layer.

Then everyone shipped. AWS launched Lambda durable functions in December, with checkpointing, automatic recovery, and the ability to suspend a run for up to a year without paying for compute while it waits. Anthropic rebuilt its own agent hosting around a durable session log in Managed Agents. Cloudflare published Project Think, where a “fiber” is a durable function invocation registered in SQLite before it runs and recoverable on restart. And the money followed the pattern. Temporal raised $300 million at a $5 billion valuation in February, then a $550 million Series E that valued it at $12.55 billion in September, on a run rate north of $250 million and 1.9 trillion durable actions processed in a single month. Its CEO put the thesis in one line: “As agents take on more critical work across more systems, every additional step creates another place to fail.”

That is a lot of vendors agreeing on the same sentence. The interesting question for anyone actually building is not whether durability matters. It is where you put it.

Two ways to make an agent survive a crash

There are two honest answers, and they lead to very different codebases.

The first is to wrap the agent. You keep your agent framework and bolt a durable execution engine underneath it, so the engine journals every model call and every tool call as a step it can replay. This is the Temporal plus OpenAI Agents SDK pattern, the DBOS and Restate and Lambda pattern, the “code the happy path and let the engine handle the failures” pitch. You get infrastructure that a thousand non-agent workloads have already hardened.

The second is to make the harness itself durable. Instead of a general engine wrapping an agent-shaped hole, the durability primitives are agent-native from the start: conversations, checkpointed steps, replay policies per tool, an ownership tree for subagents, compaction as a background job. This is what Anthropic’s session log does, what Cloudflare’s fibers do, and what a new open-source project called Pi Durable does in a way a builder can actually read.

The split is not academic. If you wrap, durability is a service your agent talks to, with its own deployment, its own determinism rules, and its own mental model that does not quite match an open-ended loop. If the harness owns durability, the abstractions fit the agent, but you are standing on a younger foundation and you own more of the floor. I have argued before that the harness is the layer worth owning, because it is the only part of the stack the model vendor does not control. Durability is the moment that argument stops being philosophy and starts being an on-call rotation.

What Pi Durable actually hands a builder

Pi started as the opposite of a heavy framework. Armin Ronacher, who built Flask, described it as the coding agent he uses almost exclusively, with “the shortest system prompt of any agent that I’m aware of” and “only four tools: Read, Write, Edit, Bash.” The whole ethos was that you do not download a plugin, “you ask the agent to extend itself,” and the result is “software that is malleable like clay.” So it was a genuine surprise when the same shop, Earendil, shipped a durability layer on the first of October. The tell is that they kept it in a separate, experimental package, so the little coding agent stays little and the heavy machinery lives next door.

What that package gives you is worth walking through, because it is the clearest small version of the “durable harness” idea I have read. The entire source is about fifteen thousand lines without tests, deliberately small enough that an agent can read its own runtime.

• Every step is a task that checkpoints before it moves on. Model requests, tool calls, and compaction are all tasks. The post’s own line is that “every step of a run is a task that stores a checkpoint before it moves on.” After a crash, a new process finds the unfinished tasks and resumes each from its last checkpoint.
• Recovery is a policy, not a blind replay. A tool marked replay: "safe" gets rerun on recovery. Everything else is reported back to the model as interrupted, and the model decides what to do next. That is the part classical durable execution handles awkwardly, because a replayed prompt can produce a different tool call. Pi Durable treats the nondeterminism as a first-class case instead of pretending it away.
• Subagents are just conversations with an owner. There is no special subagent machinery. A subagent is a conversation owned by a tool call, so it survives a crash exactly like any other conversation, and aborting a parent cleans up everything below it.
• Storage is pluggable and portable. It ships memory, SQLite, and JSONL backends, and the SQLite and JSONL code avoids Node APIs on purpose, so the same harness runs on Bun or inside a Cloudflare Durable Object with a small adapter.
• Several humans can steer one agent. Clients get a current view and then incremental updates, and any client can redirect a running conversation or queue the next instruction. The harness going multiplayer is a shift I wrote about when the first fleet harnesses appeared, and durability is what makes it safe.

Cloudflare evidently agreed with the direction, because it shipped a hosted PiHarness in its Agents SDK the very next day, running the whole thing inside a Durable Object. A major platform building hosting for an experimental framework within twenty-four hours is not a coincidence. It is a bet on where this is going.

If your reflex is LangChain, read this first

Here is the decision most teams are actually facing, and it is the reason I wanted to write this. You need a custom, long-running agent for real work, something closer to pro-code than a no-code canvas. Your reflex is to reach for LangChain and LangGraph, because that is the default and the ecosystem is enormous. Before you do, understand what its durability actually is.

LangGraph persists a thread’s graph state as checkpoints, with Postgres, SQLite, or in-memory backends. That buys you conversation continuity, human-in-the-loop via interrupt and resume, and recovery between nodes. What it is not is a journal of every individual model and tool call. It snapshots state at the boundaries of a super-step, so a failure in the middle of a step is not the thing the checkpointer is built to make seamless. For many apps that is completely fine. For a six-hour agent with side effects, the gap is exactly where the pain lives, which is why so many teams end up pairing LangGraph with a separate workflow engine and inheriting two mental models at once.

So the real choice is not “framework or no framework.” It is three postures.

• Wrap LangGraph in a durable engine when you already run Temporal or DBOS, your org has the operational muscle for it, and you want battle-tested versioning, scaling, and observability more than you want a tight conceptual fit. This is the safe enterprise answer and often the correct one.
• Own a durable harness when the agent is the product, when you want the control plane to be something you can read in an afternoon, and when you need to embed it somewhere specific like a Durable Object. You trade maturity for fit and for the ability to change behavior without fighting an engine that was designed for payment workflows.
• Stay with plain LangGraph checkpoints when your runs are short, your tools are idempotent, and a crash means a cheap restart. Not every agent needs to survive a deploy. One of the better counterpoints of the year is literally titled “You Don’t Need Temporal Yet,” and it is right more often than the vendor decks admit.

The instinct I keep coming back to is the one from stealing the contract, not the catalog. The thing worth taking from Pi Durable is not the package. It is the contract underneath it, that a durable harness exposes tasks, replay policies, and an ownership tree as named, inspectable things. You can hold that contract in your head whether you build on Pi, extend LangGraph, or write your own. The framework is a dependency. The contract is the design.

The part I won’t pretend away

Owning the durable harness is not a free lunch, and the honest case for the other side is strong.

When you wrap your agent in Temporal or Lambda, you inherit a decade of solved problems: workflow versioning, horizontal scale, a mature observability story, and an operations team somewhere that already knows how to run it. When you own the harness, you inherit all of that as homework. Pi Durable is explicit that it is experimental and the API might still change. It is TypeScript only, its built-in execution environment is Node only, and its storage is single-owner, one process at a time. Crash safety depends on tool authors correctly marking which tools are safe to replay, which means a careless replay: "safe" on something that charges a credit card is a foot-gun you built yourself.

And durability is not the two things people keep hoping it is. It is not exactly-once execution. External side effects still need idempotency keys or receipts, and no framework changes that. It is also not memory. A durable log does not give the model unlimited context, so compaction strategy still matters as much as it ever did. The clearest write-up of the launch, from stacktoheap, lands on “visible state is committed state,” which is the right mental model and also a reminder that the hosting team still owns supervision, isolation, backups, and version compatibility no matter whose harness you pick.

There is even a fair question about whether you need a never-ending agent at all. On the Pi Durable thread, which cleared more than five hundred points, the sharpest comment just asked what people actually use infinitely-running agents for. The good answers exist, background coding jobs, multi-hour investigations, on-call and monitoring agents, an assistant per customer where spawning one costs effectively nothing. But if you cannot name yours, you do not have a durability problem yet. You have a demo, and a demo can restart.

Where this leaves you

The pattern underneath all of it is that the harness is slowly absorbing what the workflow engine used to do. The model is a rental you do not control and should not try to. The harness is the part you keep, and this year it grew a spine. Durability is no longer a service you call. It is becoming a property of the runtime your agent lives in.

So the question is not whether your agents will be durable. It is whose durability you will be standing on when one of them wakes up at hour seven and has to figure out what it already did. Pick that on purpose, while it is still a design decision and not an incident.

---

The companion read is You’re Renting the Model. Own the Harness., where I argued the harness is the one layer the model vendor can’t take back. This is that argument a year later, after the harness learned to survive a crash.

I write about AI-assisted development, enterprise architecture, and building in regulated environments. If you are deciding where to put durability in your own agent stack, I would like to compare notes. Find me on X @orestesgarcia or LinkedIn /in/setsero.