Mastering Turn-Taking in AI Group Chat: How Two Characters Share One Thread

Building a seamless AI group chat experience where two characters share a single conversation thread presents unique challenges. Simply placing multiple AI personalities into one chat window can quickly devolve into a chaotic "press conference" or frustrating misfires. At AmorLink.ai, we've developed a sophisticated turn-taking logic to manage these interactions effectively. This post delves into the decision-making process behind our system, highlighting why most of the logic deliberately avoids model calls and how we tackled the complex context management.

The Challenge of Multi-Character Conversations

While one-on-one chats with a language model follow a predictable pattern—user sends, model replies—introducing a second AI character raises a critical question: when the user speaks, who answers? Early attempts at multi-character rooms often defaulted to having everyone respond to every message. This approach, however, leads to redundant, lengthy outputs and doubles inference costs and latency. Another common, yet flawed, strategy is random selection. This quickly shatters the illusion of coherent conversation when the wrong AI character responds to a direct question.

The core insight is that turn-taking isn't a monolithic problem. It's a series of smaller, manageable issues, most of which can be resolved with simple logic. Only a minority of situations genuinely require the nuanced judgment of a language model. Therefore, our policy is structured as a decision ladder, prioritizing the cheapest and most deterministic solutions first, reserving the AI for the most complex cases.

The Five-Rung Decision Ladder

Our turn-taking logic employs a five-rung ladder. The first rule that matches dictates the response. This approach minimizes AI usage and ensures efficiency.

1. Exactly one member named: If a message explicitly names one character (e.g., "Iris, what do you think?"), that character responds exclusively.
2. Both named / room addressed: When both characters are named or the room is addressed generally (e.g., "You two," "everyone"), both characters should respond. In these cases, the character who spoke least recently initiates the reply, helping to balance conversational floor time naturally.
3. Short message after a reply: If a message is very short (under 25 characters or three words) and immediately follows another character's turn, it's treated as a continuation of that exchange. The last speaker continues, preventing jarring interruptions.
4. LLM director: For genuinely ambiguous messages—full sentences without names or clear context—a lightweight AI call is made. This micro-call uses a prompt designed for classification, asking the model to determine the appropriate responder and whether the other character should "chime in." This call is heavily constrained with low maxTokens, temperature: 0, and a strict timeoutMs.
5. Anything else / director died: If all previous rungs fail, or if the AI director times out or returns an invalid response, the least-recent speaker responds. This ensures the conversation always progresses, even in failure scenarios.

Rungs 1, 2, 3, and 5 are purely string operations, costing virtually nothing. The model is only invoked for the genuinely ambiguous cases in rung 4.

Handling Context and Naming

Accurate name detection is crucial. We employ Unicode-aware boundary checks to prevent partial matches (e.g., matching "Iris" within "irises"). For general room addressing, we use conservative patterns to avoid hijacking unrelated statements.

The most significant challenge was managing the context for each AI character. A chat model has a single assistant identity. To simulate distinct characters, each AI receives a personalized view of the conversation history. Their own previous messages appear as assistant role messages, while messages from the other character and the user are presented as user role messages, prefixed with their name. This structure allows the AI to understand the flow as if it were a single interlocutor with different speaking personas.

Sequential Generation for Cohesion

When generating replies for multiple characters, processing them sequentially rather than in parallel is key. After Character A's reply is generated, it's included in Character B's context before Character B's response is generated. This ensures Character B is aware of and can react to Character A's exact words, fostering a more natural and interactive dialogue. Generating in parallel would lead to both characters responding to the user simultaneously, ignoring each other and recreating the "press conference" problem.

Guardrails for AI Behavior

To prevent AIs from speaking out of character or generating dialogue for the other AI, strict instructions are embedded in the prompts. These include explicit directives to only speak as the assigned character and to never write the other character's dialogue, actions, or thoughts. Lines from other participants are clearly delineated, and the AI is instructed not to prefix its own replies with its name, which helps avoid redundant naming in the UI.

Limitations and Future Directions

While our current system is robust for two-character conversations, the director prompt is specifically tailored for this scenario. Scaling to larger group rooms (e.g., four characters) would necessitate a different approach for rung 4, likely involving ranked scoring rather than a binary responder selection. We have not yet implemented this, but it represents a potential area for future development.

Group chat functionality with two companions sharing a single thread is now live on AmorLink.ai, offering a more dynamic and engaging AI interaction.

turn-taking group chat two characters share