Wet Flame logo

Wet Flame

A contemplative game of debate

// technical design

How Wet Flame is built

A walkthrough of the design decisions behind a multi-agent group chat built on top of language models. Written for engineers curious about the implementation.

Next.jsTypeScriptClaude APIMulti-agentRedisRailway

// system overview

user

browser

Next.js API

session + routing

A
B

parallel agents

01 / game loop

Simplicity as a design constraint

The game loop is intentionally minimal. Each character is instantiated with a pre-defined backstory, personality profile, and ideological bias. These feed directly into the system prompt along with the full chat history on every request.

No long-term memory, no tool use, no retrieval — just context engineering. The constraint proved generative: keeping the conversation window finite forces both the characters and the player to stay present.

The game ends when the conversation reaches a certain size. Adding persistent memory or multi-session continuity didn't seem to add anything to the core contemplative experience — and it would have added a lot of surface area.

02 / group chat

Agent turn-taking in a shared conversation

Most LLM applications are one user, one agent. Wet Flame is a group chat: one user, two agents, shared context. Defining agent behavior in that structure takes more thought than it might seem.

Every user message causes at least one character to respond, but usually both. The agents are prompted to make a social judgment: is this message addressed to me? Is my perspective relevant here? If you address a character by name, the other may choose to stay silent.

// turn routing

"What do you both think?"

A: respondsB: responds

"Kira, how do you see this?"

A: respondsB: may skip

"I disagree with everything."

A: respondsB: responds

03 / parallelism

A latency trade-off with a coherence cost

Both character prompts are executed in parallel. Running them sequentially would double the perceived latency — and since each LLM call can take a few seconds, that cost compounds quickly.

// parallel vs sequential

parallel

agent A
≈ 3s total
agent B

sequential

agent A
agent B
≈ 6s total

The trade-off: the second character to respond cannot directly address what the first character said in that same round. Both agents see the same prior context — just not each other's current response. In practice, this is less jarring than it sounds. The characters feel independent, which is arguably the right texture for the experience.

// built by

I'm Alan, a software engineer exploring what kinds of experiences are possible at the intersection of language models and human meaning-making. I'm also looking for my next role.

linkedin →