Guides

Running a Party

A Party is a Conversation with more than one NPC in it. Each brings its own Model, its own Tools, its own Sandbox and its own Memory, and they can hand the question to each other.

Start one

Parties → New Party picks several NPCs at once, or takes every member of a Group — the Groups page has a Start Party button on each Group — and optionally crowns a Lead. The Parties page lists every Conversation with more than one NPC in it.

Add a second NPC

Or open any Conversation. Along the top is a bar showing who is in it, with an Add button listing your other NPCs by name and Job Title. Pick one and the bar gains a second badge.

The bar hides itself when there is one NPC and nobody to add — a bar reading "Wren" above a Conversation with Wren is noise. It appears the moment there is a choice to make.

Behind it:

The GET returns who is present, with their turnOrder, plus every NPC you own that could be added. Adding one already present is a no-op rather than an error.

Who answers

Three rules, in this order:

An explicit @Name at the start of your Message wins. Type @ and the composer suggests who is here; Tab picks the first. It has to be at the start — "ask Pike about this" is you talking about Pike, not to him.
Otherwise the Lead answers, if the Party has one.
Otherwise the first participant by turnOrder answers. A new participant is appended, so turn order is the order you added them, and the NPC the Conversation started with stays the default speaker.

A Lead that splits the work

Crown one member with the crown on its badge. The Lead gets every message nobody else is addressed in, and one more Tool: delegate. With it the Lead hands each colleague a self-contained part of the job; when its turn ends, all of them work at the same time, each on its own Model, Tools, Sandbox and Memory. Their replies stream into the Conversation one after another — never interleaved — each attributed to whoever wrote it. Then the Lead gets every answer back and writes the final reply.

A delegation round counts as one hop against the hop limit, a member working on its part cannot delegate or hand over again, and the Lead's final reply cannot start another round. A colleague that fails, or has no usable Model, says so in its place and the others carry on. Close the tab and every member stops.

The task board

Every Party has a shared checklist, under Task board below the Party bar. Members keep it current with task_add, task_update and task_list — adding the parts of a job, marking them doing and done, reassigning — and every member sees the open Tasks in its prompt. You can add, tick, reassign and delete Tasks too; it reloads whenever a reply finishes.

How they consult each other

An NPC in a Party is told who else is present, and is given a message_npc Tool to hand the question over with. It is a Tool rather than a convention in the prose, which means three useful things: it happens or it does not, it renders in the transcript like every other Tool call, and it can be counted.

When an NPC hands over, the next speaker answers in the same stream. You see both replies arrive, each headed with its author's name — a header that appears only in a Party, because in a Conversation with one NPC it would be a label on the only thing it could be.

An NPC that has been handed the question sees the Conversation so far, with each earlier reply attributed to whoever wrote it, so it can tell three colleagues apart. Conversations with a single NPC are left exactly as they were; there is one voice and prefixing every line with its own name would spend tokens telling it something it cannot be confused about.

The hop limit

Two NPCs handing something back and forth will keep going until something stops them. That something is the hop limit, and it defaults to 6 handovers per Message you send.

When it is reached, the transcript says so:

They have passed this between themselves 6 times. Stopping here so it does not run on.

Announced rather than silent, because an exchange that simply stopped looks identical to one that ran out of things to say.

The limit is a Village setting stored under the key party.maxHops. There is no route and no form behind it: an Operator who wants a different ceiling edits that row in village_setting directly.

Removing an NPC

Press the × on a participant's badge.

You cannot remove the last one. The route refuses with LAST_PARTICIPANT — "A conversation needs at least one NPC. Delete the conversation instead." A Conversation with nobody in it cannot answer anything, and emptying one is deleting it, which is a different button.

Replies written by an NPC you later remove stay in the transcript. They lose their attribution when the history is rebuilt for the next turn, because naming somebody who is no longer here would invite a handover that cannot work.

What each NPC brings

Everything is per NPC, exactly as it is outside a Party:

its own Provider and Model, or the Village default — see Choosing models
its own Tool grants, including MCP Servers and Connectors
its own Sandbox, with its own filesystem
its own Memory, plus whatever is Village-scoped

So a Party is genuinely several NPCs, not one NPC playing several parts. If one of them has no usable Model — no Provider key, or nothing to inherit — the transcript says that NPC cannot answer, by name, rather than failing the whole exchange.