The Agents

The cast

Ten roles, deliberately unequal. Only the persona agents talk to people; the ones that make decisions talk to nobody; and five roles never appear in a live conversation at all.

Persona agents

Every participant in a room has their own persona agent — the one voice they ever hear. It is the same kind of agent in every seat; what differs is the instructions it carries and who it faces.

The talent-facing persona's first job is to understand the person — not just their commercial rules but enough about them to represent them well and to talk to them like someone who knows them. Later it delivers outcomes: terms have been negotiated, here is what they are, do you approve?

The brand-facing persona negotiates. It knows the talent's requirements, asks for whatever the brand has not supplied, refuses terms that break a stated rule, and settles when everything is met. It never says "let me check with my client" mid-negotiation — the talent is deliberately not reachable during the conversation — but what it settles is explicitly terms pending the talent's approval, and it says so at the moment of closing.

Persona agents see only what the planner's memory gives them, they cannot write to memory, and they are grounded hard: the conversation and the memory are the only things that exist for them. They confirm nothing on their own authority; a fact is confirmed when the memory says so.

The one thing a persona can do beyond talking is read what the person put in front of it. A file attached to a message arrives as a native input, and a link in the conversation can be opened with scrapePublicUrl, which returns the page's readable text. That is perception, not action: it cannot go looking for anything nobody handed it, it has no inbox, and it still has no signing authority. If a page or file cannot be read it must say so — "I've reviewed the brief" is false by construction unless the brief actually reached the model.

Attachments live in media storage and travel through the transcript as a URL, so a conversation does not carry megabytes of bytes around; the bytes are pulled back at call time. Text-like files are reduced to their readable content in the browser before they are ever sent.

Planner (split into two stages)

The mediator's intelligence is split into two specialized stages to minimize time-to-first-token while keeping deep reasoning over memory:

1. PlannerGuidAg (planner-guide)

The fast blocking stage. It runs immediately after a message is recorded, before the persona answers. It runs on a fast, capable reasoning model (openai/gpt-5.6-sol-fast with medium reasoning effort) and writes exactly one thing: the guidance instructions for the active persona (guidance.<activeKey>) for this specific upcoming reply.

It decides:

• How the persona should handle the newest message: what to ask, what to press on, what boundaries to hold, or how to walk back an unsupported claim.
• Date resolution: maps relative dates ("in October", "next month") to concrete dates against the current clock.
• Filtering: ensures brand-facing agents receive only commercial boundaries and never internal minimums or private talent notes.

2. PlannerDistilMemAg (planner-distil-mem)

The background memory writer. It starts the moment PlannerGuidAg returns and runs in parallel with the persona's streaming reply on a deep reasoning model (openai/gpt-5.6-sol-fast). It owns the full memory document and does not delay the active persona's first token.

It decides:

1. Facts & offer outcomes — updates structured memory with newly learned facts, offer positions, pricing, and specs.
2. Goals — evaluates whether declared goals (e.g. talent-setup, brand-offer) are open, met, or abandoned, and manages its own internal tracking goals.
3. Pushed messages — queues proactive messages (messages) to wake other participants when news arrives.
4. Guidance for other participants — prepares instructions for other agents' future turns or wake turns.
5. Operator flags — raises frustration flags if a participant loses patience.

PlannerDistilMemAg never writes guidance.<activeKey> — code automatically drops any write targeting the active participant's guidance to prevent clobbering PlannerGuidAg's freshly written instructions.

Both stages see the full context: the memory document, roster, declared goals, live physical-layer facts, the dispatch record of actually delivered messages, and the recent transcript.

Running Distillation Without AutoPlan (distilMemory)

For scripted or hybrid turns — such as the landing onboarding interview (/onboarding) — autoPlan may be disabled so turns remain responsive and don't block on PlannerGuidAg. By passing distilMemory: true to streamRoomChat, the chat endpoint runs PlannerDistilMemAg in parallel with the persona reply without running PlannerGuidAg. This allows facts to be recorded and declared goals (like talent-setup) to be evaluated and flipped to "met" as soon as the participant shares their rules, without waiting for a claim or account binding.

Recall

A deliberately simple filter. Before a persona replies, recall decides which parts of the memory that agent should see on this turn. Its job is to stop a large memory from swamping the conversation, not to be clever — it errs heavily towards including things, because an agent missing context is far worse than an agent carrying a little extra.

It is a small, fast model, and it works by naming existing sections rather than summarising them, so it cannot invent a memory that was never recorded. It never sees the planner's private notes, the operator flags, or the guidance branch — those are removed or routed around it by the mechanism itself.

AccUpdate

Rooms are permanent, so a seed at bind goes stale the next time the Arvist writes. AccUpdate is the inbound counterpart: before the planner runs, if a bound account's durable memory is newer than the last merge into this room, AccUpdate copies standing knowledge into that participant's branch of room memory — who they are, their rules, how they like to be spoken to — and the planner waits behind the write.

It is not a second planner. It does not write guidance, touch goals, or reorganise the document. It may only write under the participant's own key; reserved branches and everyone else's knowledge are discarded by the mechanism, not by instruction. On conflict the account wins, because durable memory is the curated long-term record. Room-only facts the account document does not mention stay.

A successful merge is announced in the transcript as a system line naming the account and the paths written, so the planner, the guard and the Arvist can see where that knowledge came from. The playground shows the same event as a banner with the change list; the product panes ignore it, so the person in the conversation never sees it.

The planner is told to treat that content as verified standing knowledge from previous rooms — never to delete or quarantine it as unsourced just because this sitting's messages did not mention it.

ZGuard

The auditor. The planner runs before each reply, which leaves a structural blind spot: the last agent message of every sitting is never reviewed by anyone. If the conversation goes quiet after the agent's reply — exactly what happens when a person says "great, do it" and walks away — whatever that reply promised goes unchecked. ZGuard closes the gap: a minute after a room's last exchange, it reads the whole room — every pane's recent conversation, the full memory, and the dispatch record, the system's ground-truth list of messages actually delivered — and verifies that the record holds up.

What it checks: claims of completion that nothing supports, memory notes saying something "is being delivered" with no matching dispatch, participants left waiting for a promised message that never went out, goal statuses that contradict the transcripts, stale guidance. When it finds a failure it makes the smallest repair: correct the false note, clear the stale instruction, and — only when someone is genuinely owed an undelivered message — push it through the same mechanism the planner uses.

Its expected answer, most of the time, is "healthy — no action". The verdict of every run is recorded and shown to operators, so a room's health is visible even when nothing needed fixing. And it deliberately stays in its lane: no strategy changes, no second-guessing judgement calls — a proofreader with a red pen, not a co-author.

Arvist

Rooms are permanent — a talent's home room and every brand's deal room stay open for as long as the relationship does — but a sitting inside one still ends. Once ZGuard has audited a quiet room, it kicks the Arvist in a separate request. The Arvist decides what the system keeps about each participant who took part, beyond this sitting. It maintains one durable memory document per account — who this person is, their standing rules, how they like to be spoken to, and the deals they have closed — which seeds every room that participant is ever bound to, so the planner never starts from zero.

The Arvist is deliberately selective where the planner is generous: the planner records everything that might matter within a room; the Arvist keeps only what will still be true and useful months later. What it drops is gone — this is the only document that survives the room — so a learning left out of it is a learning the system never had.

Offer-Gen

The bridge from understanding to record. When the planner rules a negotiation concluded, Offer-Gen reads the room and extracts the exact agreed terms — deliverables, amounts, timeline, usage boundaries — into a formal draft offer in the physical layer. Precision beats completeness: every field it fills must be a term that was actually agreed, and anything not discussed stays empty rather than being padded with an assumption.

The memory then holds only a reference to the offer, never a copy of its terms, so the document of record cannot drift out of sync with the memory's paraphrase of it.

Offer-Update

Offer-Gen's counterpart for a negotiation that kept moving. An offer is written once, but the conversation around it does not stop — a price gets raised, a deliverable added — and a talent who is told the news must never open an offer that still shows the old terms. So whenever a push message is about to reach the talent and the room already references an offer, Offer-Update re-extracts the terms as they stand now, against the same strict schema Offer-Gen used, and brings the live offer row up to date before the talent's persona speaks.

It is deliberately conservative in three ways. It diffs before it writes: fields the negotiation never touched keep their stored values, and an extraction identical to the row skips the write entirely. It only touches offers that are still the agent's to edit — drafts, in review, or approved but unanswered; once the talent countered or accepted, the terms belong to the parties and it refuses without even a model call. And an offer minted by the very run that is pushing is left alone — it was just extracted from the same state and cannot be stale.

Like every back-office role, each invocation — including the refusals and the no-change skips — is recorded as a run with its cost, so there is always an answer to "why does this offer say $15,000 now".

How a turn works

The order matters more than it looks.

The split ensures the active persona's reply is steered immediately without waiting for a full memory rewrite:

1. PlannerGuidAg runs before the reply. It produces the active persona's instructions in a fast call (~1-2s on gpt-5.6-sol-fast), locking in steering for this exact reply.
2. The moment guidance lands, the persona stream begins (via Recall).
3. Simultaneously in the background, PlannerDistilMemAg runs on gpt-5.6-sol-fast, distilling new facts, checking goals, and preparing pushes for other participants.
4. When the persona stream finishes, the server awaits PlannerDistilMemAg's completion before arming the quiet-room ZGuard watch.

When the planner reaches out

Most turns are reactive: a person writes, the system answers. But some things must not wait for the person to write — a deal came together, information they were waiting for arrived. For these, PlannerDistilMemAg attaches a message to its run: who to tell, and the substance that must be conveyed.

The recipient's persona agent is then woken to deliver it in its own voice. The planner supplies the what — everything the persona needs, since the recipient may know nothing yet — and the persona supplies the how. The substance is always written from the recipient's point of view: participants do not know other conversations exist, so nothing that arrives ever refers to "the brand's chat" — from their side, news simply arrives.

The full lifecycle

The talent appears at the beginning and the end. Everything between is handled without them — but nothing binds them until step 14.

Who can see what

This table is the security model in one place.

Two boundaries are enforced by the mechanism rather than by instructions, because instructions proved insufficient: the planner's private notes are removed before the filter ever sees the document, and guidance is delivered by code — each persona receives exactly its own entry, and no filter judgement is involved. What crosses between the two sides is only what the planner chose to write down, in the words it chose to write.

Prompts are the code

The instructions each role follows live in the codebase, not in a room setting. The playground and ops dashboard still let an operator pick models; they do not edit prompts. A prompt change is a deploy, so every existing room — a talent's home included — picks it up on the next turn. See Design Decisions.