A streamed answer is a sequence of events, not just a string arriving slowly. When the browser reconnects, the client needs to know whether to resume, reload the final answer or begin a new request. Without explicit identities, it is easy to duplicate text, tool actions or entire assistant turns.
The contract to define first
Assign a stable conversation turn and event sequence to the operation. Define whether partial output is resumable and how long replay data is retained. The server should separate generation state from the network connection where the architecture allows it. A reconnect should observe the original operation rather than silently launching another one.
A worked scenario
Suppose an answer has emitted five events before a mobile connection drops. A resume request can state the last accepted event identity. The server either returns subsequent events or explains that the replay window expired and serves the durable final result. The UI must not append the first five events twice.
An implementation and review sequence
- Identify the turn independently of the connection
- Choose replay retention and final-result persistence
- Specify cancel versus disconnect semantics
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| A client receives the same event twice | The UI applies it once |
| Replay history expired | Load the durable result or explain recovery |
| User cancels after a tool commit | Report the committed action accurately |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Durable replay adds storage and cleanup work. For short answers, replacing the partial display with the final persisted result can be simpler than supporting arbitrary event replay.
Use the result to make a decision
The practical output is straightforward: define event IDs and resume semantics with a disconnect trace. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Build a product AI agent around operations it is allowed to perform.
LLM structured output validation
LLM fallback routing for production apps
References and current platform requirements
MCP specification and tool contracts
Google Cloud: AI security and safety for MCP
Platform capabilities, programme terms and access conditions can change. Check the linked primary references against the version and account you actually use; the patterns above do not establish a provider approval, certification or universal compatibility guarantee.
Discuss the workflow
Bring one workflow, its systems, and the actions requiring human approval.
Explore the relevant AptixLabs service
How should an AI chat resume after a disconnect?
A streamed answer is a sequence of events, not just a string arriving slowly. Durable replay adds storage and cleanup work.
Which failure cases should be included in the review?
Include these explicit cases: A client receives the same event twice: the UI applies it once; Replay history expired: load the durable result or explain recovery; User cancels after a tool commit: report the committed action accurately.