Server-Sent Events and Streaming Data for Agents

Server-Sent Events (SSE) allow a server to push updates to a connected client over a single HTTP connection. Stock prices refresh. Notification counts tick up. Live sports scores update without page reloads. It is an efficient pattern for real-time data. But most AI agents cannot consume SSE streams, and content delivered exclusively through SSE is invisible to them.

How SSE works

SSE uses a standard HTTP connection with a text/event-stream content type. The server keeps the connection open and sends data as named events:

GET /stream/prices HTTP/1.1
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: price-update
data: {"product": "WK-2045", "price": 49.99, "currency": "GBP"}

event: price-update
data: {"product": "WK-2046", "price": 59.99, "currency": "GBP"}

On the client side, the browser uses the EventSource API to listen for events and update the page:

const source = new EventSource('/stream/prices');
source.addEventListener('price-update', (event) => {
  const data = JSON.parse(event.data);
  updatePriceDisplay(data.product, data.price);
});

The agent compatibility problem

Most AI agents fall into two categories:

HTML-parsing agents fetch a page, read the HTML, and extract information from the static DOM. They never establish an SSE connection because they do not execute JavaScript. The EventSource listener never runs, and the price updates never arrive.

Browser-based agents (using tools like Playwright or Puppeteer) do execute JavaScript and can receive SSE events. But there is a timing issue: the agent loads the page, waits for it to stabilise, reads the content, and moves on. If the SSE data arrives after the agent has already read the page, or if the agent closes the connection before the next event, the data is missed.

In both cases, the agent sees whatever was in the initial HTML response. If the product price was rendered server-side as £49.99 and then updated via SSE to £44.99 (a flash sale, say), the agent reports £49.99. The real-time update never reaches it.

When this matters

The impact depends on how critical the streamed data is:

High impact: Live pricing, stock availability, auction bids, time-sensitive offers. If the SSE-delivered data is the authoritative current value, agents will report stale information.

Medium impact: Notification counts, live chat indicators, user presence. These affect user experience but typically do not change the core content an agent needs.

Low impact: Decorative updates, subtle animations, background refreshes. Agents do not care about these.

Providing fallbacks for agents

The solution is straightforward: make sure every piece of critical information is available without SSE.

Render initial values server-side. The HTML response should contain the current price, availability, and status before any SSE connection is established:

<span id="price" data-product="WK-2045">£49.99</span>
<!-- SSE will update this to the live price, but the initial value is correct at render time -->

Provide a REST API alongside SSE. If agents or other automated clients need current data, offer a standard HTTP endpoint:

GET /api/products/WK-2045/price
Content-Type: application/json

{
  "product": "WK-2045",
  "price": 49.99,
  "currency": "GBP",
  "updated_at": "2026-03-17T14:30:00Z"
}

This follows the broader principle that agents generally prefer APIs over web interfaces because APIs return structured, predictable data without requiring JavaScript execution.

Include the data in structured markup. Add the current values to your JSON-LD structured data, which agents can read regardless of whether SSE is working:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Keyboard",
  "offers": {
    "@type": "Offer",
    "price": "49.99",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  }
}
</script>

SSE vs WebSocket for agent compatibility

SSE and WebSockets both deliver real-time data, but SSE is simpler: it is one-directional (server to client), uses standard HTTP, and reconnects automatically. WebSockets are bidirectional and require a protocol upgrade. Neither is well-supported by most agents, but SSE is slightly more accessible because it runs over plain HTTP.

The takeaway is the same for both: do not rely on real-time streaming as the only source of critical content. Always provide a static or API-based fallback that agents can access.