The report came in the way the worst ones do: after a crash, from someone who had done nothing wrong.
I had a lot of sessions open. However, when I came back, my computer had crashed. Upon returning... those sessions did not resume properly. That's the first problem. The second problem is that when I tried to run the session resume command, it basically said that many sessions were not indexable. Can you fix the short ID thingy and let them get indexed so I can properly resume them?
The agent that picked it up did not start by reading the failing sessions. There was nothing wrong with them. It started with one line: "I'll dig into the agents-cli sessions indexer to find why short_id comes back NULL."
That is the whole problem in a sentence. The sessions were on disk. The reasoning inside them was intact. But their short IDs had come back NULL, so the indexer could not record them, so the resume command could not locate them, so a crash turned hours of work into files nobody could reach. The intelligence was fine. The address was gone.
An agent you can't find is an agent you don't have. Not slower, not degraded — gone, with its work sitting on a disk you can no longer point at.
The three primitives
When you run one agent, none of this is visible. There is a single session and you are looking at it. The moment you run a fleet, three things that used to be free become engineering problems, and they have to be solved before the model's reasoning matters at all.
Identity. Every session needs a stable, collision-free ID — the short ID that must never come back NULL. Without it, the session has no name to be called by.
Index. Every session needs a record that lets you find it later without rescanning the whole corpus. Without it, "which session was that" becomes a linear search over everything you have ever run.
Resumption. Every session needs a durable checkpoint you can rehydrate after a crash. Without it, a dropped connection or a dead laptop is a total loss, not a pause.
These are not features you add later. They are the substrate the reasoning sits on. Break the first one and the other two fall with it.
In a single-agent world, all three are free
The reason addressing feels like a non-problem is that for most of the last few years it was one. A chat window is a fleet of size one. You never had to name the session because there was only ever the session. You never had to index it because it was already on your screen. You never had to engineer resumption because closing the tab and reopening it was the whole recovery story.
That world quietly inverts the moment you have more than a handful of agents running at once.
Three things that were free are now three systems you build and keep working. That inversion is the entire job, and it is invisible until the day a crash makes you go looking for a session by name.
The two longest sessions weren't about intelligence
That crash report is not an anomaly. It is the shape of what actually consumes engineering time once a fleet exists.
We keep a deterministic mine of our own agent-session corpus — 1,337 sessions as of this writing. Rank them by sustained debugging effort, and the sessions that rise to the top this week are not about making an agent smarter. They are about not losing one:
Under it, the same theme repeats: "Fix session resume with batch selection in factory UI" ran 386 messages. "Fix Remote Session IDs" was the top-ranked debugging session of the week at 345. "Debug user data routing and storage in agents CLI," 297. "Fix leg menu bar bin app and locate storage path," 262.
Roughly half of our longest debugging sessions this week were the same problem wearing different clothes: not making an agent think better, but making sure we could still find it, route it, and reopen it afterward. The two longest, 864 and 386 messages, were both addressing. The model was never the bottleneck. The ledger of where everything lived was.
Why addressing gets hard fast
The reason this bites early is volume. You do not need a large user base to blow past the point where scrolling is a strategy.
Over the last thirty days on our fleet, the median user ran 93 sessions. The top-decile user ran 388. A single agent ran 334 sessions in that window. At those counts, "just scroll up to the one you want" is not a plan. The session you need is somewhere in a stack of hundreds, and the only way to reach it is by address: a stable ID, an index that resolves it, a checkpoint that reopens it.
Notice the honest part of that chart. These are small absolute numbers. This is an early fleet, not a hyperscaler. And the wall still shows up — which makes the point sharper, not softer. If addressing becomes load-bearing at a few hundred sessions per user, it is not a problem you scale into eventually. It is one you hit almost immediately, and then live with forever.
It isn't only us
The tell that this is structural, and not a quirk of our stack, is that the whole industry walked into the same wall in the first half of 2026 and started building the same three primitives.
Durable execution went mainstream. The OpenAI Agents SDK shipped a Temporal integration to general availability in March 2026, pitched as durable execution "with a single configuration change, no workflow DSL" — checkpointing so a crashed run resumes instead of restarting. An April 2026 update to the same SDK leaned into externalized agent state and snapshotting, with the state explicitly rehydrated into a fresh container. Microsoft positioned its Durable Task for AI agents, updated April 2026, as checkpointing and coordination infrastructure that agent frameworks plug into. Three different labs, one quarter, the same conclusion: an agent's state has to live somewhere it can be found and reopened.
The research caught up too. O'Reilly Radar's "Why Multi-Agent Systems Need Memory Engineering" argues most failures in multi-agent systems trace to memory and state chaos, not model quality. Work on state-store architecture maps the tradeoff every fleet eventually meets: a centralized store bottlenecks past N agents, a distributed one scales but makes consistency painful, and production ends up hybrid.
One external number is worth keeping separate from ours, because it is theirs, not a Rush figure: for long-running agents, one analysis found that systems without state persistence carry a 90% higher risk of total task failure from timeouts and infrastructure outages. Different fleet, different methodology. The direction is the same one our crash report pointed at.
One week, one fleet
Here is the caveat this piece owes you. Everything above our T3 citations is one week on one fleet, ours, and it is survivorship. These are the bugs big enough to spawn 200-to-800-message sessions; the quiet successes never showed up in the ranking. It does not prove that addressing is the universal hardest problem in agent engineering. It proves that addressing is our bottleneck at our scale, and that the rest of the industry hit the same wall in the same quarter.
That is a narrower claim, and a more useful one. The failure mode is not exotic. It is a NULL where an ID should be, found only after a crash, on a fleet small enough that nobody expected to need addressing yet.
What you actually build
Step back and the division of labor is clear. Intelligence is the part you rent. It arrives from a model lab, it gets cheaper every quarter, and you do not own a line of it. Addressing is the part nobody can rent you, because it is not a model at all. It is the ledger of your own fleet: which sessions exist, what they are named, where they live, and how to reopen the one that mattered.
You can buy a smarter agent tomorrow. You cannot buy back the session that came home to a crashed laptop with a NULL where its short ID should have been. That work is only as durable as the addressing underneath it, and the addressing is on you.
The teams that win the agent era will not be the ones with the smartest agent. Everyone rents from the same labs. They will be the ones who never lose one — who can name every session, find it in a stack of hundreds, and reopen it after the machine dies. That is not a model capability. It is an agent OS doing the unglamorous work underneath, the same harness that made the judgment loop legible in the first place, now making sure the loop can be found again after it stops.
Build the intelligence to be borrowed. Build the addressing to be kept.
First-party evidence here comes from our own agent-session store and fleet insights (/insights, range=30d), generated 2026-08-03: the crash report, the session-length ranking across a 1,337-session corpus, and the 30-day volume figures of p50 93, p90 388, and one agent at 334. It is one week on one fleet and is survivorship by construction. External figures are attributed inline and belong to their sources, not to Rush; the 90% total-failure figure is Indium's, not ours. Durable-execution timeline: OpenAI Agents SDK with Temporal (GA March 2026) and state rehydration (April 2026); Microsoft Durable Task for AI agents (April 2026). Related reading on why fleets need memory engineering: O'Reilly Radar and mem0. See also Agents Are Eating the Org Chart and What Is a Multi-Agent System.
