Server-Sent Events (SSE)

SSE establishes a single, long-lived HTTP connection from the client to the server. The server uses this persistent connection to push a continuous stream of text-based events to the client. This is in contrast to bidirectional protocols like WebSockets and is ideal for scenarios like live notifications, dashboard updates, or stock tickers where the primary data flow is server-to-client.

• Protocol: Standard HTTP/1.1 or HTTP/2.
• Direction: Server → Client only.
• Connection Life: Remains open until explicitly closed by the client or server.

The data stream follows a simple, standardized text/event-stream MIME type format. Each message in the stream consists of one or more field-value pairs separated by newlines. The core fields are:

• data: The payload of the event. Multiple consecutive data: lines are concatenated.
• event: An optional string identifying the event type, allowing clients to listen for specific events.
• id: An optional message ID, enabling automatic client reconnection with the Last-Event-ID header.
• retry: An optional number (milliseconds) suggesting a reconnection delay to the client.

A message is terminated by a blank line.

SSE has built-in mechanisms for resilience. The client's EventSource API automatically attempts to reconnect if the stream is closed, using an exponential backoff strategy. The protocol supports state recovery through the id field. When reconnecting, the client sends the last received event ID in the Last-Event-ID HTTP header, allowing the server to resume the stream from the correct point. This provides a robust foundation for maintaining real-time feeds over unstable networks.

Clients connect using the native EventSource JavaScript interface, requiring no additional libraries. This simplifies development and reduces bundle size. The API exposes a straightforward event-driven model:

javascriptCopy
const eventSource = new EventSource('/updates-stream');
eventSource.onmessage = (e) => console.log('Data:', e.data);
eventSource.addEventListener('stockUpdate', (e) => console.log('Stock:', e.data));

• Low Overhead: No handshake protocol beyond the initial HTTP request.
• Built-in Parsing: The browser handles parsing the event stream format.
• CORS-Compatible: Respects standard HTTP Cross-Origin Resource Sharing policies.

SSE occupies a specific niche in the real-time communication spectrum.

• vs. WebSockets: WebSockets are full-duplex (bidirectional) over a custom protocol, suited for interactive applications like chat. SSE is simplex (server-push) over HTTP, simpler and often more efficient for pure data broadcasts.
• vs. HTTP Long Polling: Long polling emulates server push by holding a client request open until data is available, then requiring a new request. SSE uses a true persistent connection, eliminating the latency and overhead of repeated request/response cycles.

Use SSE when: You need efficient, low-latency server-to-client updates without client-to-server messaging.

Within AI agent systems and External System Connectors, SSE is a critical protocol for delivering real-time, asynchronous events from backend services to agent runtime environments. Common use cases include:

• Tool Execution Status: Streaming the progress and final results of a long-running API call or database query invoked by an agent.
• Event-Driven Triggers: Pushing external system events (e.g., a new database record, a completed CI/CD job) to an agent to initiate a new reasoning loop.
• Observability Streams: Sending real-time telemetry, log events, or performance metrics from the agent's execution environment to a monitoring dashboard.

It enables agents to react to the world without inefficient polling, aligning with event-driven integration patterns.

A feature of the HTTP/2 protocol that allows multiple bidirectional streams of data to be multiplexed over a single TCP connection. This enables efficient, concurrent real-time communication and is a foundational technology for protocols like gRPC. For AI agents, it allows for efficient transmission of large payloads or continuous data feeds without the overhead of multiple connections. Core concepts:

• Multiplexing: Multiple request/response streams share one connection, eliminating head-of-line blocking.
• Server Push: The server can proactively send resources to the client.
• Binary Framing: Data is transmitted in binary format, improving parsing efficiency over HTTP/1.1's text-based format.

A client-side stub generated from a Protocol Buffer service definition that enables an application to make remote procedure calls (RPCs) over HTTP/2. It uses efficient binary serialization and is ideal for high-performance, type-safe communication between microservices or AI agents and backend systems. Key attributes:

• Interface Definition Language (IDL): Services and messages are defined in .proto files.
• Strong Typing: Compile-time type safety across multiple programming languages.
• Streaming Support: Supports unary, server-streaming, client-streaming, and bidirectional streaming RPCs, offering more structured alternatives to raw SSE streams.

A software component that reacts to events from a source system and triggers an action or publishes data to a target system. This is a higher-level architectural pattern that often utilizes technologies like SSE, Webhooks, or message queues. For AI agent tool-calling, a connector might listen to an SSE stream from a database and automatically invoke an agent's reasoning function. Common sources and targets include:

• Sources: Database change streams (CDC), message queues (Kafka, RabbitMQ), or SaaS platform events.
• Targets: API endpoints, other message queues, or directly invoking an agent's tool-calling interface.
• Pattern: Follows the Publish-Subscribe or Event-Carried State Transfer models.