There are two operations here. Starting a run may create effects. Subscribing to its progress should only observe that run. A dropped stream is evidence about delivery to the browser, not about the state of the refund. The browser must keep a stable run ID and reconnect to an observation endpoint. Retrying the original start request needs its own client request ID and idempotent run-creation contract. It should return the same run when that request was already accepted, not create a fresh agent plan.

Persist important run events in an ordered per-run log: proposed action, approval requested or granted, tool submitted, provider outcome observed, and terminal run state. Give each event a stable sequence or cursor. SSE supports event id and reconnection with Last-Event-ID in the HTML standard. The standard carries the cursor, but the application must implement durable storage and replay. A client can ignore already applied event IDs and request later events. Auth is checked again on each subscription, including replay, because yesterday's access does not authorize today's private transcript.

Be careful with what an event says. “Refund submitted” is not “refund succeeded.” The operation ledger owns the external effect state, and the event stream is a view of it. A model's token stream or intermediate narration cannot certify a payment. If an event was delivered but the browser did not acknowledge or render it before disconnect, replay can show it again. The UI should apply events idempotently, rather than relying on exactly-once network delivery.

The hard crash is between provider commit and our event-log write. A new stream subscriber may see no success event even though the refund happened. Do not run the action to fill the apparent gap. Reconcile the durable operation ID with the provider, append the verified outcome, and then continue dependent work. This is the same uncertain-effect boundary as any external action, but a reconnect makes it visible in the UI. An event log records what our runtime knows, not a magical atomic transaction with the provider.

If the browser was offline past the replay window, return a cursor expired or equivalent response and a current run snapshot. The snapshot identifies the latest confirmed operation and run states, plus the event-log coverage boundary. Do not invent the missing sequence of token deltas or claim the user watched them. If a full audit is required, retain the necessary state under its own policy, distinct from a short-lived presentation stream. The UI can show “The run continued while you were offline” and the verified result.

What if an old browser tab reconnects after the user loses refund access? It may be allowed to see a limited run status, or it may be denied altogether under the current policy. It must not receive the private event history just because it knows a cursor. Test duplicate start requests, reconnect immediately after submission, replay overlap, cursor expiry, permission revocation, and the provider-commit-before-log crash. A reliable stream makes observation resumable. It does not make a refund retriable.