How to build realtime agentic applications

A hands-on introduction to WebSockets

Apr 30, 2025

Image by Aleksejs Bergmanis (source: pexels)

When you’re building applications, the classic HTTP request-response model is hard to beat.

Client sends a request, server sends a response. It’s simple, solid, and honestly, it covers 99.99% of what I need as an ML engineer.

But real-time, dynamic systems? Especially ones with interactive agents? That’s where HTTP starts to feel a little ... slow.

Some projects just need more. They need fast, low-latency, two-way communication; less like passing notes in class, more like having a real conversation. Think multiplayer games, real-time simulations, collaborative environments, etc.

That’s when HTTP starts getting in the way …

And that’s where WebSockets come in 👇

HTTP vs WebSocket Connection (source: https://www.wallarm.com/what/websocket-vs-http-how-are-these-2-different)

Instead of the usual one-way back-and-forth, WebSockets open up a persistent, two-way connection between the client and server. No more opening and closing connections every time you need something: just a steady, always-on stream of data.

For the agentic application we wanted to build, this is exactly the kind of communication we needed.

In this post, I’ll walk you through how we’re using WebSockets in PhiloAgents, my opne-source course with

Paul Iusztin

, where we’ll show you how to build a videogame agent simulation using MongoDB, LangGraph, Groq and Opik.

This article builds on the theory and code covered in previous ones, so be sure to check them out if you haven’t already!
Lesson 1: AI Agents inside a videogame
Lesson 2: A hands-on introduction to Agentic RAG
Lesson 3: A breakdown of memory in Agentic Systems

Ready? Let’s go! 👇

Connecting the Game UI and the Agentic Backend

Before we jump into the code, let’s first get clear on what we’re building. To set up WebSocket communication, we need two main parts:

The Client
The Server

In our setup, the Game UI will implement the client (that's the WebSocket Service you see in the diagram), and it’ll communicate with the server, which is exposed through the FastAPI application. Let’s begin with the client.

WebSocket Client (Phaser)

Like I was saying, the client will be set up inside the Phaser code (that’s the JavaScript framework we used to build the Game UI).

You can check out the full WebSocketApiService implementation in the repo, but here, I’m just going to zoom in on some specific methods.

Starting the connection

let’s begin with the connect method. This method is what opens the line between the Game UI and the Agentic Backend, making real-time, two-way data exchange possible.

Sending data and handling responses

This class also handles sending data (meaning the messages you send to one of the philoagents) and processing incoming messages. You’ll notice we’re binding the handleMessage method to be used whenever a new message comes in from the server.

Closing the connection

Finally, we have a method to disconnect the client from the server and end the communication.

And that’s pretty much how you build a WebSocket client, my friend! Now, let’s move on to something a little more in our wheelhouse as ML Engineers: FastAPI.

WebSocket Server (FastAPI)

To be honest, PhiloAgents was the first project where I actually had to put the WebSocket protocol into practice; and you know what really surprised me?

How ridiculously easy it is to create a WebSocket endpoint in FastAPI. Seriously, it’s crazy simple.

All you have to do is decorate your function with @app.websocket, set the path (usually starting with something like /ws), and boom: you're good to go!

Below, you can see how PhiloAgents handles incoming messages from Phaser using the /ws/chat endpoint.

The WebSocket server we set up takes the incoming message and sends it over to the LangGraph workflow (running in streaming mode). Then, it streams each chunk of the response back through the WebSocket channel.

So, whenever you chat with a Philosopher, the Game UI will be receiving a stream of messages like this.

From there, the DialogueManager steps in. It stitches all the chunks together, formats the response, and gets everything nice and clean to display in the simulation.

Pretty neat right? 😎

And that’s everything for today! I hope you enjoyed this hyper-practical introduction to WebSockets. If you come up with any cool use cases to test out this protocol, definitely let me know - I’d love to hear about them!

Honestly, this is one of the first projects I’ve seen that uses WebSockets for agentic applications, so it’d be awesome to build even more end-to-end examples around it.

What do you think? 🤔

Oh, and if you prefer learning through video instead of reading, I’ve also got a YouTube video where I cover FastAPI and WebSockets — feel free to check it out!