How Zero Noichi Built a Ten-Agent AI Werewolf Game

野市 零 / Zero Noichi shows what happens when ten AI agents share one werewolf game: the challenge is no longer generating a clever reply, but coordinating voices, roles, memory, timing, and conflict without making the conversation feel mechanical.

This article thanks 野市 零 / Zero Noichi for documenting the experiment in the original AI werewolf video. The video is presented as an entertainment experiment, but it also exposes the engineering problems behind a believable multi-agent application: how to make agents wait, interrupt, remember, deceive, and react as members of one shared world.

Collaboration disclosure: The original description references ZimaBoard 2, a creator coupon, affiliate links, and the software services used in the experiment. The creator is sharing his own implementation and intended use. Model versions, voice services, interfaces, hardware bundles, and compatibility may change after publication.

The result: A ZimaBoard 2 - Mini Home Server is not a replacement for a large inference cluster running ten frontier models at full speed. Its more realistic strength is acting as a compact, always-on control and service node for an AI application: coordinating prompts, game state, APIs, audio pipelines, logs, and network access while heavier model work is assigned to the service or compute path that fits it.

The useful way to read this project is as a layered system. The language model supplies decisions and dialogue, but an orchestration layer decides whose turn it is, a state layer decides what each character knows, a voice layer turns text into speech, and a presentation layer makes the result understandable to a viewer. Remove any one of those layers and ten “smart” agents quickly become ten disconnected chat windows.

The Hard Part Is Shared Reality, Not the Number of Agents

Adding a second model to a conversation is easy compared with adding a second model that must obey the same rules. In a werewolf game, every character needs a private role, a public history, a belief about other players, and a legal set of actions for the current phase. The application therefore needs one authoritative game state instead of allowing each model to invent its own version of events.

A robust design separates public and private state. The public state can include the current day, spoken claims, votes, and eliminated players. Private state can include a werewolf’s teammates, a seer’s result, or a character’s hidden suspicion. The orchestrator then builds a different context for each agent instead of broadcasting every secret to everyone.

This separation also makes debugging possible. If an agent makes a suspicious accusation, the developer can inspect the exact public transcript, private memory, role prompt, and model response that produced it. Without those boundaries, apparent “intelligence” may simply be an accidental leak of information from one prompt into another.

Character Prompts Need More Than a Personality Adjective

Calling one agent “confident” and another “quiet” is not enough to create a cast. A useful character definition combines a speaking style, a risk tolerance, a goal, a role-specific knowledge boundary, and a rule for how evidence changes belief. The character should sound different, but it should also make decisions for a reason that remains consistent across turns.

Each agent benefits from a structured profile: name, role, public persona, private objective, known facts, current suspicions, and a compact memory of prior events. The prompt can then ask for both an internal decision and a viewer-facing line, while the application stores only the fields needed for the next transition. This keeps the context readable as the game grows.

There is an important boundary here. A longer prompt does not automatically produce a deeper character. If every turn repeats the entire transcript and every instruction, latency and cost rise while the model still lacks a clear state transition. A smaller, curated memory often creates more consistent behavior than an unfiltered conversation dump.

Model Selection Changes the Rhythm of the Game

The video highlights the choice of LLM models as part of the experiment rather than treating “AI” as one interchangeable component. Moonshot Kimi K3 is named in the project as the language-model component, and that choice affects not only answer quality but also response length, latency, refusal behavior, language style, and the amount of context that can be carried between turns.

A practical architecture can assign different jobs to different models. A stronger model may handle a difficult private deduction, while a faster model produces short social reactions or narration. The important rule is to keep the game contract outside the model. The model can propose an action, but the server should validate whether that action is legal before applying it to the state.

Remote model APIs also change the privacy and reliability boundary. If the game sends private role information to an external service, that service becomes part of the trust model. Network failures, rate limits, and API changes can pause the game even when the local device is healthy. Caching prompts, retrying idempotent requests, and recording request IDs make the experiment easier to resume and explain.

Natural Conversation Requires a Turn-Taking Engine

Ten agents speaking in a fixed queue would sound like a conference call controlled by a spreadsheet. The more convincing behavior comes from an explicit turn-taking engine that knows when a character may speak, when an interruption is allowed, and when the table must move on to a vote or night action.

One useful pattern is a state machine with phases such as introduction, open discussion, targeted response, voting, night actions, and results. Within a discussion phase, the scheduler can choose the next speaker using a mix of fairness, relevance, suspicion, and controlled randomness. A character can request an interruption, but the engine decides whether the request is valid and how it affects the queue.

This is why “realistic voice” is more than text-to-speech. The system must decide when audio starts, whether a current utterance can be cut off, how a response is queued, and what happens if a voice request fails. A clean separation between text decisions and audio playback lets the game continue even when a voice provider is slow.

Voice Adds Social Cues—and New Failure Modes

Spoken dialogue changes how viewers judge the agents. Pauses, acknowledgements, interruptions, and differences in vocal identity make a short response feel like part of a live table. The video uses Fish Audio for the voice layer, which serves a structural purpose: it turns state transitions into events that a human can follow in real time.

Audio can also expose bugs that text hides. A delayed synthesis request may cause a character to speak after the game has already moved to another phase. A long generated answer can block the queue and make quieter agents disappear. The application should therefore attach every audio clip to a game event and phase, so stale clips can be discarded instead of played out of context.

Voice identity also needs a consistency policy. If a character’s voice changes between turns, viewers may interpret a technical failure as a new character. Keeping voice assignment in configuration, rather than inside the model prompt, makes the presentation layer predictable and easier to replace.

The Game Loop Needs a Server-Side Source of Truth

During the live game, the system must coordinate more than chat messages. It needs to know who is alive, which phase is active, which actions are still legal, what each character has heard, and when a result becomes official. Those facts belong to the application layer, not to an agent’s free-form response.

A good event record might include the phase, speaker, visible text, private action, model used, request status, and resulting state version. That structure supports replay: the developer can rerun the presentation from the same events without asking every model to regenerate the entire game. It also makes it easier to compare two model configurations under the same scenario.

Replay is especially valuable for a project that looks spontaneous. If a character wins because of a compelling deduction, the developer can ask whether the outcome came from the role design, a lucky model response, a leaked secret, or a scheduling quirk. Observability turns an entertaining demo into a system that can actually be improved.

Where ZimaBoard 2 Fits in the Architecture

ZimaBoard 2 makes the most sense at the always-on edge of this system. That positioning is consistent with the broader ZimaBoard 2 local AI assistant setup: the board can host the coordinator, a small database, dashboards, webhook services, audio queues, or containerized support components while connecting them reliably to external model and voice APIs. That role benefits from low power, a compact footprint, and network connectivity more than from a large number of CPU cores.

Whether the board can run a specific model locally depends on model size, quantization, memory, acceleration, and the latency the experience requires. That is why the separate Zero Noichi ZimaBoard 2 and AMD MI50 build is a useful comparison: additional GPU compute changes the inference path, while the board can still provide the stable host and service layer. The safe planning rule is to separate orchestration from inference: design the application so the state engine remains useful even if the model endpoint moves between a local service, another machine, or a hosted API.

Direct storage and expansion can also support logs, prompt versions, cached audio, and game replays. Those files are not the model itself, but they are the evidence needed to understand how the system behaved. A small server that keeps the project reproducible may be more valuable than a faster device that only produces an impressive one-time demo.

What the Live Result Reveals About Multi-Agent AI

The appeal of the experiment is that the agents appear to have social intent: they interrupt, defend themselves, suspect one another, and coordinate around incomplete information. Technically, those behaviors emerge from the interaction between role prompts, private context, state transitions, and the scheduler. No single model response explains the whole experience.

That distinction matters for anyone building a local AI application. More agents do not automatically mean more intelligence. They increase coordination cost, context management, failure surface, and observability requirements. A smaller group with clean state boundaries can produce a more believable result than a larger group that forgets its rules.

The project also shows why latency is a product decision. A slow but thoughtful answer may be acceptable during a turn-based deduction, while the same delay feels broken during a short acknowledgement or interruption. The scheduler should therefore match model effort and voice length to the importance of the event instead of giving every message the same treatment.

How to Recreate the Idea Without Copying the Whole Production

Start with three agents and one simple hidden-role rule. Build the event log, state machine, and private/public context separation before adding voice. Once the text-only loop can replay a complete round without leaking information, add a single voice provider and measure where the interaction actually feels slow.

Next, make the configuration explicit. Store character profiles, role rules, model routes, voice assignments, and retry policies outside the prompt text. This turns a one-off demonstration into a system that can be tuned without rewriting every agent. It also gives the hardware node a clear job: keep services, configuration, and evidence together while the inference backend remains replaceable. The same separation is useful in a broader local AI server build, where the runtime and the supporting services may evolve at different speeds.

Finally, test failure instead of only testing the happy path. Stop one model request, delay one audio clip, remove a player, restart the coordinator, and replay the same event log. A convincing multi-agent application is not defined only by its best conversation; it is defined by whether the system can recover without changing the rules halfway through the game.

For a compact home-server platform that can host the orchestration and supporting services, explore ZimaBoard 2 - Mini Home Server for Your Big Idea. To compare ideas with other builders, join the ZimaSpace Discord community.