WebSocket Connections: Can Agents Use Them?

WebSockets enable real-time, bidirectional communication between browsers and servers. They power live chat, collaborative editing, multiplayer games, and real-time dashboards. For human users, they create responsive, dynamic experiences. For AI agents, they create a wall of inaccessible content.

Why agents struggle with WebSockets

WebSocket connections require a protocol upgrade from HTTP. The client sends an Upgrade header, the server responds with 101 Switching Protocols, and the connection switches from HTTP to the WebSocket protocol. Here is the handshake:

GET /ws/chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

HTML-parsing agents never initiate this handshake. They make standard HTTP requests and read the response. The WebSocket endpoint looks like a normal URL, but returning HTML from it is not its purpose.

Browser-based agents (Playwright, Puppeteer) can technically use WebSockets because they run a full browser. But most agent frameworks do not include logic to interact with WebSocket messages. The agent loads the page, sees the JavaScript that establishes the WebSocket connection, and might even let that connection open. But it does not know how to read or respond to WebSocket messages as part of its browsing task.

Content that disappears

Several common features rely entirely on WebSockets for content delivery:

Live chat widgets. The chat history and current conversation are streamed over WebSocket. An agent visiting the page sees the chat container, but the messages inside are empty because they never arrived via the initial HTML.

Collaborative documents. Tools like Notion, Google Docs, and Figma use WebSockets for real-time collaboration. The document content loads through the WebSocket connection, not from the initial HTTP response. An agent sees a loading screen or an empty canvas.

Real-time dashboards. Analytics dashboards, monitoring tools, and trading platforms stream data via WebSockets. Without the connection, the agent sees charts with no data.

Live event feeds. Sports scores, auction updates, and social media feeds that update in real-time over WebSockets are invisible to agents that cannot connect.

Providing HTTP fallbacks

The principle is simple: every piece of content that matters should be accessible via standard HTTP, either in the initial page load or through a REST API.

Render the initial state server-side. A chat application can render the most recent messages in the HTML, then use WebSockets for live updates:

<div id="chat-messages">
  <div class="message">
    <span class="author">Support</span>
    <p>Hello! How can we help you today?</p>
    <time datetime="2026-03-19T10:00:00Z">10:00</time>
  </div>
  <!-- WebSocket updates append here -->
</div>

Offer REST endpoints for the same data. If your WebSocket delivers pricing data, expose it through a standard API as well:

GET /api/dashboard/metrics
Accept: application/json

{
  "active_users": 1247,
  "revenue_today": 8432.50,
  "updated_at": "2026-03-19T14:30:00Z"
}

Agents can poll this endpoint on a reasonable interval instead of maintaining a persistent WebSocket connection. The pattern aligns with how agents prefer APIs over web interfaces for data access.

Use structured data for key information. Even if the detailed, real-time data requires a WebSocket, surface the essential information in your page's structured markup. An agent that cannot read your live stock ticker can still get the company's basic financial details from JSON-LD.

Sites that rely too heavily on WebSockets

Some patterns create particular problems:

Single-page applications that load all content via WebSocket. The initial HTML is a shell with a JavaScript bundle. All page content arrives through the WebSocket after connection. Agents see the shell and nothing else.

Authentication flows over WebSocket. Some sites use WebSocket for token exchange or session management. If the agent cannot complete this flow, it cannot access any authenticated content, even if it has valid credentials.

Search results streamed via WebSocket. A search function that sends results through WebSocket rather than returning them in an HTTP response is unusable for most agents.

The practical position

WebSockets are excellent for real-time interactivity. Keep using them for live features that benefit from bidirectional communication. But treat WebSocket-delivered content as an enhancement, not the only source. Server-render the initial state, provide REST APIs for data access, and include key information in structured data. This keeps your site functional for both human visitors and the growing number of agents trying to access it.