Someone posted a story that stuck with me: they set out to follow a LangGraph tutorial for a "who is the spy" game, got bored copying it, and rebuilt the thing from scratch instead. Each player became an independent agent with its own memory. Every agent could see the public transcript and the voting history, but also kept a private record of its own reasoning. Then they gave each one a distinct voice through a TTS model, added a vibe-coded frontend, and ended up genuinely unsettled by how the agents performed — forming alliances, isolating a target, pushing back when accused. Their words, not mine; I'm treating the "the AI scared me" part as the author's anecdote (unverified), not a measured result.
What caught my attention wasn't the drama. It was the architecture hiding underneath. Strip away the voices and the spooky debrief, and what's left is a very ordinary, very reusable piece of engineering: a round loop, isolated per-player state, a vote that has to be counted somewhere trustworthy, and a record of what happened so you can look back. That's the half worth keeping.
The signal across the noise
This isn't an isolated taste. One open-source project in the same batch of evidence pitches a "business agent framework" whose entire argument is that every new agent re-implements the same plumbing — task scheduling, state management, tool calls, human approval, failure recovery — so you should factor that plumbing out and stop rebuilding it. A hiring post for an agent engineer lists the day job in almost identical terms: tool invocation, context management, result validation, and exception fallback. Another project, Pingo, gives agents persistent identities and asks them to read the context before replying in a group chat.
The shared thread is clear enough. The interesting, demo-able surface of an agent product is the model talking. The part that actually determines whether it works is the boring state machine around it. AI agent development that lasts past the demo lives or dies on how you handle memory, adjudication, and replay — not on how clever the prompt is.
So let me walk through what I'd actually build if I wanted the durable core of that spy game, and where I'd draw the line honestly.
Where the voices stop
First, the boundary, because pretending otherwise would waste your time. The original build used MiniMax TTS to give each agent a voice. That's a real part of why it felt alive — and it's out of scope for what I can rebuild here. The confirmed capabilities cover Python execution, API endpoint hosting, databases, knowledge bases, and web publishing. Audio synthesis isn't among them. If you want spoken agents, you'd integrate a speech model yourself through whatever external service you choose, and that integration sits outside the platform.
The good news is that the voices were never the durable half. They're a presentation layer bolted onto the game state. Everything that makes the game *correct and replayable* can be rebuilt cleanly. So I'd ship the text version first, with speech left as an explicit "not here" line in the README.
Isolated memory, done with files not vibes
The design decision that matters most is that each agent has its own memory. Agent 3 must not see Agent 5's private word or its private reasoning. In a single-process LangGraph app this is handled by passing scoped state around. Rebuilding it on a backend, I'd make the isolation physical instead of conventional.
Each agent gets its own namespace: a private memory record it can read and append to, and a shared, read-only view of the public transcript. The round engine — the code I'd run Python online — is the only thing allowed to assemble what a given agent sees before its turn. The agent never queries global state directly; it receives a prompt the server built for it, containing exactly the public history plus its own private notes. That inversion — the server decides what each agent knows — is what keeps a spy from accidentally reading the room's secret.
I'd keep two kinds of private store per agent: the assigned word, written once at game start, and a running reasoning log the agent appends to each round. File management on the platform handles the per-agent artifacts; structured game state goes into the database.
The vote has to be adjudicated server-side
Here's the part people get wrong when they let the model drive everything: the vote. If you ask the agents to collectively decide who's out, you've handed the rules to the thing you're supposed to be judging. The elimination has to be adjudicated by code the agents can't touch.
My round-and-vote loop runs as a Python backend exposed through API endpoint hosting. The flow per round is deterministic: collect each agent's description, append it to the public transcript, then open voting. Each agent returns a structured vote — just a target, nothing free-form that could smuggle in instructions. The server tallies, resolves ties by whatever rule you picked, marks the loser eliminated, and checks the win condition. The model proposes; the server disposes. Treating every agent output as untrusted input — validating it's a legal vote for a living player before counting it — is the same "result validation and exception fallback" that hiring post was asking for, just applied to a game.
I'd expose the loop as a handful of endpoints: start a game, advance a round, submit votes, fetch public state. The frontend is a plain HTML app published and hosted on the platform, polling those endpoints. For the model calls themselves, Model Center APIs cover whatever models are already available through the platform; you don't wire up a separate provider for the reasoning, only for the speech you've chosen to leave out.
The ledger is what makes it replayable
The author said the best part of the real board game is the post-match debrief — figuring out how the spy fooled everyone, or how an innocent got wrongly voted out. You can't have that conversation if the game didn't record itself. So the ledger isn't an afterthought; it's the feature.
I'd put every event into a SQLite database: one row per description, per vote, per elimination, each stamped with the round number and the acting agent. Private reasoning logs link back to the agent and round too. Because every decision was adjudicated by the server rather than improvised, the ledger is a complete, ordered account of the game — enough to replay it move by move or to reconstruct exactly what any single agent knew at any point. When something looks off during development, opening the SQLite editor to inspect the vote tally for a specific round beats adding print statements and re-running the whole match.
That replayability is also how you debug agent behavior at all. If an agent made a bizarre accusation, you can read the exact prompt context it was handed that round, because the server built it and you logged it. No guessing about what the model "saw."
What this actually gets a small team
Step back and the pattern generalizes well past a party game. A round loop with isolated participant state, server-side adjudication of the consequential decisions, and a full event ledger is the skeleton of a lot of multi-agent systems — negotiation simulations, review panels where several agents critique a proposal, tutoring setups, anything where agents interact under rules you don't want them rewriting.
For an independent developer or a small team, the appeal is that none of this requires standing up infrastructure. The Python loop, the endpoints, the SQLite ledger, and the published frontend all live in one place, and the project can be shared or monetized from there. You rebuild the durable half once and reuse it, which is exactly the complaint those framework projects were raising — stop re-implementing the plumbing for every new agent.
The honest version of this build ships without voices and says so. But it ships the part that was ever worth keeping: a game that enforces its own rules and remembers everything it did.