I opened #3531 to track the concrete implementation problem, but I wanted to raise the broader product/contract question here because I do not think this is an edge case.

Today, v2 connect appears to replay history plus the currently active run, then complete when that run ends, or complete immediately if no run is active. In other words, it behaves like a one-run stream, not a durable thread-follow stream.

That is a serious limitation for an important class of agent systems where runs are not always initiated by the currently connected client. These systems commonly:

• continue operating in the background
• emit periodic heartbeats or status runs
• run on schedulers or cron
• react to external triggers and server-side automation

For those systems, connect is not just "replay the current run". It needs to mean "stay attached to this thread and keep surfacing AG-UI events/state as the thread evolves over time."

Without that behavior, a thread detail view can connect successfully, observe one run, and then silently stop reflecting reality even though the same thread continues evolving on the server.

The contract that seems needed here is:

• connect stays attached to the thread until the client disconnects
• future runs on that thread continue surfacing AG-UI events/state
• RUN_FINISHED and RUN_ERROR mark run lifecycle boundaries, not stream termination

So the core question for maintainers is: is durable thread-follow semantics the intended design for connect?

If yes, then issue #3531 is the concrete implementation gap and I think it should be treated as first-class support for long-lived/background agents. If no, it would be helpful to understand what the intended primitive is for building thread views that remain accurate as future server-initiated runs happen.