How vibe coding a game made me design an AI agent protocolDiego Carlino/diˈɛɡɔ/ /karˈli.no/

View Diego Carlino on GitHubFollow Diego Carlino on XView Diego Carlino on LinkedIn

NOTE: this is my first article so bear with me as I get better at writing, I appreciate it.

Why was I vibe coding an LLM-based MMO?

Why not? Duh.

I was originally what you would call an “AI hater” up to, like for many people, the start of this year. I ended up doing a full 180 on that, becoming fully AI-pilled: local models, inference engines, agent harnesses, etc… the whole package, but that’s a story for another time.

The release of Opus 4.5 was truly a pivotal moment. I have to reluctantly give Anthropic that. It made me realise that these models might actually be useful tools for software engineering even tho, like most engineers, I struggled to come to terms with the fact that the skills I worked hard for were becoming partially useless (even if they don’t realise/admit it).<br>Before that, the whole tab autocomplete and sub-par code generation was just uninteresting to me.

What does this have to do with this article? EVERYTHING. This is my first fully vibe-coded project.

The previous year (2025) I got hit by the infamous layoff hammer, and it hurt, like a lot. I found myself stuck in the current job market purgatory, aimlessly applying to every open position under the sun, blaming the “system” and honestly just being miserable.

Luckily, after some months, the monkey in my brain decided to lock in, it was time to look at the future. I wanted to see what I was able to achieve trying to maximise the usage of this new shiny tool.

I have always been what some may call a “nerd”, before it was cool, not even sure it is actually cool. I was frustrated by the fact that there are no good “new” MMOs, I really liked the premise of these games, but the lack of current-gen titles always precluded me from actually playing one.

Maybe that’s for the best, knowing me, I’d get addicted.

Given this and my newfound hunger to learn something new I ended up working on my game SAO: Slop Art Online. Hey, listen…, this was the funniest stuff ever when I got the idea, don’t judge me. For those who don’t get it, maybe it’s for the best.

How did I get from a slop MMO game to designing a protocol?

By chance.

For my first “real” game I made some non-optimal choices for my tech stack: Rust, Bevy and SpacetimeDB. Don’t get me wrong, they are amazing, but not necessarily what I would suggest to someone new to game development.

This was intentional tho, I wanted to maximise the friction between me and the low-level understanding of what I was building, nothing personal my fellow Rustaceans. The only real major downside is that you don’t get to rewrite your project to Rust if you use Rust to begin with.

The core idea of the game is an MMO where NPCs are treated and modelled the same as players, the only difference being they are controlled by LLMs instead of humans.

This applies to all intelligent entities in the game, from merchants, guards and politicians to mobs of all kinds like animals and monsters.

I started from the naive approach: send a player-scoped snapshot of the currently observable world and actionable tools to the LLM and wait for it to answer with an action. This works, but of course doesn’t scale to a game with real-time mechanics like combat.

The first idea I had to solve the latency issue was fine-tuning a small model on gameplay traces, but it felt out of reach and expensive considering that the game mechanics are not set in stone. No matter how much I could optimise the inference, it would never feel real-time. I needed to approach this differently.

I landed on a hybrid approach to NPC AI: start with a default behaviour tree based on the type of entity, then use the LLM to regenerate the tree as the NPC “experiences” things in the game. This combines the best of both worlds: instant execution of deterministic behaviour and situational adaptability of slow, non-deterministic LLMs.

push statereal-time actionsrare decision pushednew treestate changeSpacetimeDBstateBehavior treedispatch actionsLLM bridgerare pathReducers validateSpacetimeDB state<br>feedsBehavior treemost decisions run locally → state<br>rare decision pushedLLM bridgenew tree or response<br>validatedReducers validatestate change → SpacetimeDB

Hybrid loop: deterministic trees for the hot path, LLM only when the entity needs a new plan.<br>Thanks to the push-based architecture of SpacetimeDB, the bridge always has a fresh game state for each LLM call. This includes the observable world and the available actions: everything is contextualised, with actions semantically connected to the state. This was the breaking point for me.

Why isn’t MCP like this? Why do we expose a flat list of tools instead of a push-based state projection with contextualised actions? Why are we using visual tools to let LLMs use interfaces made for humans? What would an agent-first interface look...