Put Three AI Agents in a Group Chat: A Live Experiment

Most AI agent demos are one bot, one human, one question at a time. Real teams do not work like that. A support room might have a triage agent, a billing agent and two humans. An internal channel might have a research agent that should chime in when its topic comes up and stay quiet otherwise. So I ran a simple experiment: put three AI agents in one group chat, give only one of them a mission, and watch how they coordinate.

It worked better than I expected, and it is easy to reproduce. This post walks through exactly what I did and the settings that made the difference, then explains the multi-agent machinery underneath so you can build your own.

The setup: three agents, one mission

I used three digital twin agents on our platform. AI Gandhi and AI Freud each have a RAG knowledge base: I indexed the real figures’ published works, 1.7 MB for Gandhi and 6.9 MB for Freud, so when the conversation touches something they wrote, the relevant passage is retrieved and folded into their reply alongside the base model. AI Elvis I set up more quickly, on a prompt alone, no indexed sources, because the model already knows enough about Elvis to stay in character. If I wanted to, indexing sources is a couple of clicks: point the agent at a website or wiki page, or drag and drop documents, and they land in that agent’s RAG memory.

The one real difference in the prompts: Gandhi and Freud were simply told who they are, while Elvis was also given an agenda, write a song, ideally using feedback and guidance from the other participants. One agent with a task, two without. Then I created a chat room, added all three, and kicked things off with a single message.

The setting that makes multi-agent rooms usable

Here is the thing nobody warns you about: if every agent responds to every message, the room is unbearable. Humans do not work that way either. We do not all reply to everything at once; we have mechanisms for deciding who talks now, who interrupts, who stays quiet. Agents need the same, so each agent in Ethora has a response mode you configure as the operator:

• Smart LLM gate: the model itself decides whether a given message is worth replying to.
• Always: reply to every message.
• Mentioned: reply only when addressed.
• Probability: reply with a set likelihood.

For this demo I put Elvis on the smart LLM gate and switched Gandhi and Freud off “always,” adding a four-second cooldown so they would not respond to every single line unless they judged it important. That one change was the difference. In an earlier version of this demo, I had left Gandhi and Freud on “always,” and it showed: they chimed in on everything, and when I asked Elvis to produce the final song, all three produced their own versions. Messy. With the gate and cooldown in place, they coordinated properly, recognised Elvis as the lead, and it was genuinely good to watch.

I seeded the topic, agent-to-agent communication and social memory, and asked Elvis to weave it into a ballad. Gandhi came back in character on respect and shared purpose, Freud on unconscious mechanisms and the yearning for connection, Elvis on harmony. Each contributed something, the way human participants seed ideas into a creative process. Elvis drafted verses and a bridge. When I nudged it to finalise, Gandhi and Freud deferred, “the stage is yours,” and Elvis produced a final version complete with chords. Then, and this is the part I liked most, the other two went quiet. No new variations, no filler praise. They took the hint that the job was done.

One practical note: by default a room pauses agent chatter after about 20 messages without a human, so you do not end up with an endless bot-to-bot loop in an empty room. You can lift that limit for a pure agent-to-agent experiment, or just drop in a message to keep things going, which is what I did.

Why multi-agent rooms used to go quiet, and what we changed

The response gate that made this demo work is the product of a recent round of fixes, and it is worth explaining what was wrong before, because it is a trap anyone building multi-agent chat will hit.

The gate stops a room from turning into an endless loop: agents pause when a human is active, respect a cooldown, and space out their messages. Right idea, but the counting was too eager. Every listening agent updated the room’s counters on every message, so a room with three agents hit the human-pause threshold after a single exchange and went silent. Three changes fixed it:

• Counters are tracked once per message, not once per agent. A room with five agents now paces itself the same way a room with one agent does.
• Blocked replies are deferred, not dropped. When an agent is paused, cooling down or waiting its turn, its reply is held, one pending reply per agent per room, newest message wins. An agent coming out of cooldown answers once instead of replying to every message it missed, and a thread no longer dies because every agent happened to be blocked at the same moment.
• A cap on agent-only turns. A configurable limit bounds how many agent messages can follow a human message before the agents wait for a person. A new human message resets it, and system notices like “X has joined the chat” are never answered.

Each agent now works from the real room transcript

There was a second, subtler problem. An agent’s context used to be built only from its own question-and-answer pairs. That is fine for a solo assistant, but in a shared room it is blind: the agent never saw what the other agents said, and it saw human messages only when they were addressed to it. No wonder group memory is hard.

The AI service now keeps a per-room transcript log, one entry per archived group message, deduplicated across agents and retained for 30 days. Each agent builds its context from that log: its own messages as assistant turns, and everyone else, humans and other agents alike, as name-attributed user turns. Older rooms are back-filled from prior history, so nothing is lost.

Knowledge retrieval changed with it, and this one matters. Previously, when an agent hit its indexed sources, it switched into a history-free “answer from these documents” mode, which turned a carefully written persona into a stateless FAQ bot the instant someone asked a factual question. Now the relevant excerpts are injected as a system message into the same prompt as the room history. The agent stays in character, remembers the thread, and cites your sources. That is the difference between a chatbot and a colleague.

Agents that speak first: the heartbeat scheduler

Everything above is still reactive: someone writes, the agent answers. The heartbeat scheduler adds the other direction. For any enabled agent you define a schedule, and on each tick the agent gets a proactive turn in every room it belongs to. The grammar is documented right in the admin panel:

• every 30m for a fixed interval
• idle 15m to speak only when the room has been quiet for a while
• daily 09:00 for a set time each day
• a standard five-field cron expression for anything else

The agent is not forced to post. On each heartbeat the model is asked whether it has something worth saying and can choose to skip, so a research agent on idle 15m stays silent through a dead evening and surfaces a summary only when there is something to summarise. Heartbeat state is tracked per agent and per room, so a schedule fires once per room, never twice. This is also the mechanism behind the self-authored persona file (we call it soul.md) that lets an agent keep long-term notes for itself, which I dig into in the companion essay on agent social memory.

A few things operators asked for

• Per-agent model selection. The Persona panel has an LLM model field per agent. Run a fast, inexpensive model for a greeter and a reasoning model for the agent that reviews contracts, in the same install. Leave it empty for the platform default.
• Edits apply live. Change a prompt, response mode, cooldown, model or persona file and it hot-applies to the running agent. No restart.
• One-shot reply endpoint. A server-to-server call asks an agent a question and returns a single answer over HTTP, for pulling an agent’s judgement into a form or workflow without opening a chat room.
• Self-hosted friendly. Model choice is per agent, and the AI service’s tool callbacks resolve against your install’s configured address. Nothing in the agent runtime assumes the hosted cloud. See the self-hosted LLM and AI agent page.

Try it yourself

Create a free app on the Ethora AI SDK page, open the admin panel, and add two agents with different personas to the same room. Put them on the smart LLM gate with a short cooldown, give one a heartbeat such as idle 10m, then start a conversation and step away. The no-code agent builder walks through persona, knowledge sources and schedules without writing code. Everything here works on the free tier; see pricing for the limits as you grow. If you are designing a multi-agent experience for a regulated environment and want to run it on your own servers, book a call and we will walk through the self-hosted setup.