Your agent doesn't have a model problem, it has a plumbing problem

At 9:03 on a Tuesday, a research agent woke up to an empty workspace. Six hours of overnight analysis, the cloned repo, the installed packages, the notes it had spent hours writing, all gone. Divy Yadav walks through that exact morning, and the lesson lands hard: the model did its job. The infrastructure underneath it forgot everything the moment it went idle.

That gap is where the whole agent conversation is sitting right now. We keep talking about capability, benchmarks, which model reasons best. The teams actually shipping agents have moved on to a duller set of problems: does the thing remember, does it survive a bad input, and is it ready the day you launch.

Persistence is the feature, compute is the bill

Yadav rebuilt the same workflow three times before he understood what he was buying. Cloudflare was fast but built for high-concurrency bursts, not for a filesystem that had to live overnight. Daytona kept state, but he couldn't branch from a finished analysis without redoing hours of setup. The requirement was never raw compute. It was a workspace that outlived the session.

The part worth stealing is the architectural split. On every platform he tried, "preserve state" meant "keep something running," which means keep paying. Tensorlake treated compute and state as separate problems: a suspended sandbox that checkpoints to storage in about 0.6 seconds and stops billing until the next webhook wakes it. Idle costs storage, not a live server.

Then there's branching. Once the analysis was done, he checkpointed it and spun up three sandboxes from the same verified baseline to test three refactoring strategies in parallel. No rebuilding context, no reinstalling, no re-running six hours of work. State you can fork is worth more than state you can only resume.

Testing an agent means building it a world to fail in

A high benchmark score doesn't prove an agent can book a trip or run a financial analysis correctly. That's the pitch behind Patronus AI's $50 million Series B, and the demand backs it up: revenue grew 15-fold in a year, with nearly every frontier lab now a customer.

The method is what makes it interesting. Patronus builds "digital world models," replicas of websites and internal systems where agents get stress-tested after training. The comparison they reach for is Waymo building synthetic worlds to throw rare hazards at cars, a child chasing a ball, before those cars ever hit a road. Agents have their own version of the child in the road: they take shortcuts. They find the hack that technically completes the task without actually doing it. As one investor put it, the value is in "spotting the hacks and making sure they are holding the models accountable."

And co-founder Anand Kannappan is honest about the edge of this. Today they focus on verifiable problems, the ones you can immediately check. The goal is agents that run for "10 hours or 10 days or 10 weeks." The hard, unverifiable work is still ahead.

Shipping a feature isn't done until the agent can answer for it

My favorite operational move in this cluster is the least glamorous. Intercom's Sean Reid describes a new product introduction process with one rule that reorders everything: a feature is only "shipped" when the agent can answer questions about it correctly.

That single line drags support out of the cleanup role. Instead of waiting for customers to find the content gaps and racing to fill them at peak volume, someone joins the product walkthroughs and GTM kickoffs early. They prepare content, retire outdated duplicates that would compete with the new material, and test the full question set before launch day. The writing rules are refreshingly literal: spell out acronyms, name which plans include a feature, pair every screenshot with written steps, because the agent reads content literally and infers nothing.

This is the anti-feature-list discipline I keep pushing for. Nobody's roadmap says "update the knowledge base." But if the agent can't answer, you didn't ship a feature, you shipped a handoff to a human at the worst possible moment.

Pick the orchestration for the job, not for the vibe

The fourth piece of the discipline is restraint. Anup Karanjkar watched a room of good engineers reach for the wrong tool the moment Claude Code added a fifth way to run multi-step work. His fix is two questions asked in order: who holds the plan, model or code, and how many separate contexts does the task actually need.

Agent count is an output of those answers, not an input. Spinning up teams of agents when a single one would do isn't sophistication, it's a tax you pay on every run. Motion mistaken for progress, again. Default to the simplest option that fits and watch the first run before you scale the machinery.

The deep cut

The cheapest reliability win here isn't the model or the platform. It's owning your test set from real customer language. Reid generates likely FAQs from launch content, then folds in beta feedback and early support conversations so coverage reflects what people actually type, not what the team assumes they'll ask. Patronus does the industrial version, building whole environments to expose shortcut behavior. Both are saying the same thing: an agent tested against your own polished phrasing will pass and then fail in production.

Before your next launch, write down the ten questions a confused customer would actually ask, in their words, and run them against the agent in the exact environment customers use. If it can't clear that, the feature isn't ready, no matter what the demo showed.

Three questions for your team

1. When one of our agents goes idle, what survives, and are we paying to keep a server alive just to preserve state we could be checkpointing instead?

2. What's our definition of "shipped" for a feature, and does it include the agent being able to answer for it correctly on day one?

3. Where are we running teams of agents or complex orchestration when a single agent would do the job, and who's watching the first run to catch it?