Why AI Agents Will Force Us to Replace REST APIs with Bidirectional Event Streams

The Stateless Trap

For the last two decades, REST (Representational State Transfer) has been the undisputed king of web integration. It is clean, stateless, and incredibly easy for humans to reason about. A human clicks a button, a frontend client sends an HTTP GET request, a server processes it, and a JSON payload is returned. Transaction complete.

This synchronous, request-response cycle works beautifully when the client is a human who expects immediate, static feedback. But we are rapidly transitioning to a world where the dominant clients on the web are not humans—they are autonomous, long-running AI agents.

When an AI agent interacts with a system, it does not just make a single, isolated request. It plans, monitors, orchestrates, and reacts. If you try to force these multi-step, dynamic workflows through a standard REST API, the entire architectural paradigm begins to buckle under the pressure. Every tick of the system clock reveals another bottleneck in our stateless infrastructure.

To build a world where agents can collaborate seamlessly with software, we need to abandon our reliance on REST and embrace bidirectional, event-driven streams.

The Problem with Polling and Timeouts

Imagine an AI agent tasked with setting up a complex marketing campaign. The agent needs to generate three copy variants using a tool like the prompt generator, compile them into a draft, wait for a compliance API to scan the text, upload assets to a cloud bucket, and finally publish the campaign.

In a traditional REST world, this workflow is a nightmare to manage:

1. The Timeout Dilemma: If the agent triggers a long-running compliance scan via a POST request, the connection will likely time out before the scan completes. REST is not built for asynchronous tasks that take minutes to resolve.
2. The Polling Tax: To circumvent timeouts, the agent is forced to constantly poll an endpoint (e.g., GET /scans/123/status) every few seconds. This wastes immense server resources, spikes database reads, and introduces unnecessary latency.
3. State Synchronisation Failure: If something changes on the server side—say, a human manager manually pauses the campaign mid-run—the agent has no way of knowing unless it happens to poll the exact right endpoint at the right time.

We are trying to build real-time, intelligent loops on top of a protocol designed for static document retrieval. It is the architectural equivalent of trying to play a real-time multiplayer video game over post cards.

Switching to Bidirectional Streams

If we want agents to be truly effective, they need a continuous, low-latency connection to the systems they control. They need to live in a world of shared state, where updates are pushed instantly in both directions. This means moving away from HTTP REST and toward technologies like WebSockets, gRPC, and Server-Sent Events (SSE).

In an event-driven setup, the relationship between the agent and the application changes entirely:

• Instant Reactivity: When a database record changes, the server pushes an event directly to the agent's active connection. The agent can immediately adjust its planning loop without waiting for the next polling cycle.
• Streaming Intermediates: As models like those from OpenAI generate thoughts and planned actions, they can stream their internal state token-by-token directly to the backend. The host system can validate or block actions while the agent is still formulating them, rather than waiting for a completed block of JSON. For integration questions about streaming models, developers can consult the OpenAI Support portal.
• Collaborative State Machines: Instead of stateless requests, the agent and the application share a live, state-synchronised session. If a human intervenes in a UI built with tools like Figma Weave, the agent's internal context is updated in real time.

Designing APIs for Non-Human Clients

As backend engineers, we must change how we design our application interfaces. When we build APIs today, we write documentation assuming a human developer will read it and write a rigid client integration.

When we build for agents, we must assume the client is dynamic, capable of reasoning, and constantly active. This requires a shift in how we structure our data:

1. Schema-First Event Registries: Agents need strict, machine-readable definitions of all events they can emit and receive (using tools like AsyncAPI, JSON Schema, or Protobuf). This allows the agent to dynamically inspect the event catalog and understand how to interact with your system on the fly.
2. Rich Context Payloads: When pushing an event to an agent, do not just send an ID. Send the context. An event like "order.disputed" should contain enough rich metadata for the agent to initiate a resolution workflow without needing to query five other endpoints just to gather basic details.
3. Idempotency by Default: Because event streams can occasionally drop and reconnect, agents will inevitably retry actions. Every event-driven interface must be rigorously designed with idempotency keys to prevent agents from accidentally executing duplicate transactions.

The Real-Time Agent Mesh

We are moving toward a future where software is not just a tool we click on, but an active participant we collaborate with. A static, REST-based web is too slow, too fragile, and too silent for this new reality.

By moving to bidirectional event streams, we unlock the true potential of agentic workflows. We allow AI agents to act as real-time microservices that plug directly into our application state loops, reacting to events the millisecond they happen. It is time to turn off the constant polling, stop waiting for HTTP responses, and let the stream run.