Disclosure: Oleh Hebel founded Interface Report and runs Oleh Hebel & Co and Ship Index Grow, projects related to product design and AI education. No sponsor paid for or reviewed this article.
Direct answer: TanStack AI 1.0 stabilizes its core APIs while its new harness remains experimental. Product teams should define and test recovery states, persisted approvals and external outcomes before promising uninterrupted agent work.
The approval is on screen. The connection drops. When the customer returns, the conversation looks familiar—but can they tell whether the action is still waiting, already happened, or needs checking?
That moment deserves a place in the product brief. A beautifully streamed answer is only one part of an agent experience. The return journey matters just as much: a person should be able to recover their understanding of the work without accidentally repeating it.
TanStack's October 23, 2026 announcement of TanStack AI 1.0 makes this question timely. The maintainers distinguish stable core APIs from a new experimental agent harness. The harness packages remain on 0.x, and their APIs can change in a minor release. That distinction is essential for anyone turning a working demo into a product roadmap.
Read the stability boundary before the feature list
According to the release announcement, stable client and server packages should be upgraded together; experimental harness packages stay separate. The announcement describes sessions, approvals and reconnecting to running work, with durable storage required for restart recovery. These are the project's documented capabilities and conditions, not results of Interface Report testing.
My product recommendation is to list the exact lifecycle your application intends to support. A browser reload, a dropped network connection and a server restart are different events. Write down what the customer should see after each one, and which record can establish what actually happened. This turns an attractive capability label into a reviewable product promise.
A team can adopt stable pieces while evaluating experimental ones in a bounded workflow. What matters is that its release decision names that boundary. A single version number on a slide should not obscure which dependencies, data formats and recovery paths the application actually uses.
A saved conversation is not the whole job
The 1.0 migration guide requires applications to supply a stable thread identifier. It also calls out saved-data changes: some older records will not load as-is, and pending interrupts from before interrupt bindings existed cannot resume. The guide's completion checks include loading a saved chat after a page reload.
Those migration details have a human consequence. Imagine a hypothetical design studio where an agent prepares an asset and waits for permission to publish it. Restoring the conversation's text would be insufficient if the application lost the relationship between the prepared asset and the approval request. The returning user needs the specific proposal, its current status and the available next step.
This is a scenario to test, not a reported defect in TanStack. I would review persistence through a customer's questions: Which conversation am I in? Is this the same proposed change? Did anyone approve it? Has the external destination confirmed completion? A product that can answer those questions has a clearer recovery experience than one that merely redraws the transcript.
Design the return screen around evidence
My proposed return screen would show the last confirmed state before offering another action. For a publication workflow, that could include the draft version, the destination and a receipt from the publishing service if one exists. If the application cannot establish the external result, it should say so and provide a way to check it.
That uncertainty deserves its own state. A disconnected client does not, by itself, tell the customer whether a remote action succeeded. Treating uncertainty as a generic failure invites people to retry. Treating it as success invites them to leave unfinished work behind. The interface should help them inspect the evidence before choosing either path.
I would also distinguish reconnecting from starting over. A resume control should explain which existing work it rejoins. A new-run control should explain that it creates another attempt. These are editorial design recommendations for an application built on an agent toolkit, not descriptions of TanStack's default interface.
Recovery has limits worth putting in the plan
The harness introduction explicitly warns that its APIs are experimental and recommends pinning the installed version. Separately, the deployment documentation identifies a current limit: a harnessAgent child's in-memory wait does not resume on another host or after a crash. Teams should read the current limits for their chosen design rather than generalize from a basic example.
The practical implication is to keep a written recovery contract beside the workflow design. For every dependency, record what can be reconstructed, what requires a fresh decision and what an operator must investigate. An unresolved child task might lead to a different customer message from a task still awaiting approval. The product should not flatten both into a reassuring spinner.
For founders, this is also a scope decision. A narrow workflow with a clear recovery path may be more useful than an ambitious background agent whose return states nobody owns. Choose an initial promise your team can explain and verify, then expand it with evidence.
Run the interruption review before launch
For a pilot, I would start with three situations: disconnect before the user decides; disconnect after the decision but before the screen updates; restart the server while work is pending. Add the documented child-agent limitation if the implementation uses that path. Use a controlled environment and actions whose outcomes can be inspected.
Have a designer and an engineer independently describe the state after each interruption. Then compare their descriptions with the stored records and the external system. If they disagree about whether work is waiting or complete, the application needs a clearer contract. Track duplicate attempts and the effort needed to resolve uncertainty alongside successful recovery.
TanStack AI 1.0 offers a fresh occasion to make these decisions explicitly. The release establishes an API boundary; your team still owns the experience surrounding it. The strongest agent product is one a person can return to, understand and safely continue—even after the impressive first answer has disappeared from view.
Reporting note: Primary sources checked October 24, 2026. Vendor observations are attributed; examples and proposed evaluation criteria are editorial analysis. No hands-on testing is claimed.
Related reading
- Undo is the feature agent products still lack
- Agent harness portability is becoming infrastructure
- Your AI agent may need fewer agents