If reconnecting to a five-minute agent run repeats tool calls and compute charges, SSE versus WebSockets is not the main architectural decision. Resumability is.
The same issue appears across agent coordination, search systems, software migrations, and local tooling. Capability is only part of the result. Reliable architecture must preserve state, contain failure costs, and make change recoverable.
Judge a system by what happens after interruption, not only by what it can do when everything works.
The Expensive Part of a Disconnect Is Repeated Work
Both SSE and WebSockets are ephemeral. Neither makes an agent run durable by itself.
After a disconnect, replaying five minutes of work may repeat tool calls and compute charges. Buffering every token in Redis could support recovery, but it creates a write-heavy path for failures that may be uncommon.
A resumable execution log addresses the underlying problem. It records what completed, what can safely run again, and the correct offset for restarting. Transport moves data. Logs, offsets, and explicit replay semantics make execution recoverable.
Simple Transport Cannot Provide Durability
SSE remains a sensible choice for request-initiated, one-direction text streaming. Anthropic, OpenAI, and Google use variants of this plain-text pattern. MCP’s Streamable HTTP retained text/event-stream inside POST responses, while HTTP/2 multiplexing weakens the old objection about six connections per domain.
Production configuration still matters. Nginx buffering can batch an SSE response that should appear live. SSE also carries UTF-8 text rather than native binary frames. Bidirectional audio may fit WebRTC or WebSockets better.
There is no universal transport winner. Simplicity is useful when it matches the communication pattern, but recovery must be designed separately.
The Same Test Applies Beyond Streaming
Claude Code sessions can discover and message other sessions across cmux panes, worktrees, and remote machines. In one demonstrated workflow, a production-monitoring session remained intact while another implemented fixes and opened a pull request. Codex and Claude Code also reportedly exchanged progress reports through a socket.
Persistent, inspectable workers allow explicit handoffs without discarding working context. They do not prove correct behavior when a worker stalls, disconnects, sends an incomplete handoff, or reports completion incorrectly.
Search systems present a related trade-off. In Govscape’s benchmark of 500,000 pages and 10,000 queries, Apache Lucene delivered 418 queries per second with a 2.8 GB index. SQLite FTS5 delivered 11 queries per second with a 14 GB index.
Those measurements favor Lucene as a search engine. Embedded search may still reduce network distance and synchronization between separate systems. Turso and ParadeDB pursue another compromise by placing Tantivy, a Lucene-class library, inside the database. Engine performance and operational coordination are different questions.
Migration strategy exposes the same distinction. Facebook replaced layers over years while keeping existing code running. Bun reportedly added more than one million lines in 11 days using Claude Fable 5 and up to 64 concurrent instances, but the Rust build remained Canary.
A fast merged port is not equivalent to a trusted default release. Gradual replacement carries a different cost, but it preserves a running system while each layer changes. The architectural question is where migration risk sits and how safely the organization can recover from a bad change.
Self-hosting also changes dependencies rather than necessarily removing them. Harper, Activepieces, and Meily appear to make the clearest case among ten presented projects because they replace bounded habits. Several younger tools still require hosted models, external transcription, personal API keys, or substantial setup. The label alone does not establish independence, offline operation, or low operational cost.
A Working Demo Starts the Reliability Question
Persistent agents, simple streaming, embedded search, concurrent rewrites, and self-hosted tools can enable useful workflows. Demonstrated capability is not production readiness.
A demo establishes that a workflow is possible. Production engineering begins by deciding what survives when that workflow disconnects, retries, migrates, or fails halfway through.