The documents the mediator reasons from, why they have no fixed shape, and the few parts that do

Two layers of memory

The system remembers at two ranges.

Room memory is the working document of one room: what has been learned in these conversations, where each negotiation stands, the planner's instructions to the agents. It lives and dies with the room.

Durable account memory follows a person across rooms. Rooms are permanent, so "closing" is no longer the trigger — instead, after ZGuard audits a quiet room, it kicks the Arvist, which promotes what is worth keeping from that sitting — who this person is, their standing rules, how they like to be spoken to — into the account's durable memory, which seeds every room that account is ever bound to so the planner never starts from zero. Rooms are permanent, so a seed at bind is not the last word: when that durable document changes later, AccUpdate merges it into the participant's branch of the still-open room before the next planner run. This is how a talent's terms, settled once in their permanent home room, are already known in a brand-new deal room — and stay current in rooms that were bound earlier — without the talent doing anything. Deals this account has actually closed are part of that document: the price it accepted, the deliverables, the usage rights it granted. A rate already agreed to is what anchors the next negotiation, so losing it means re-deriving the account's own commercial position from scratch every time.

Facts still belong on the account they describe. Recording that a deal closed with a named brand is the deal history of the account being promoted for; profiling that brand — its contacts, its budget, how it haggles — is not, and belongs on the brand's own document.

A room running a mock tape never promotes. Scripted fiction must not become standing knowledge on a real account, so the Arvist records a skipped run and leaves the durable document alone — the same spirit as suppressing push email from a scripted room.

flowchart LR Planner["Planner<br/>(the writer)"] -->|writes| Memory[("Room memory")] Guard["ZGuard<br/>(repairs)"] -->|corrects| Memory AccUpdate["AccUpdate<br/>(courier)"] -->|participant branch| Memory Memory -->|filtered| Personas["Persona agents"] Memory -->|in full| Planner Memory -->|"room goes quiet"| Guard Guard -->|"then kicks"| Arvist Arvist -->|promotes| Durable[("Durable account memory")] Durable -->|"seeds at bind"| NextRoom[("Next room's memory")] Durable -->|"when newer"| AccUpdate

One document, one writer

Within a room, everything the system knows lives in a single shared document, and the planner writes it. The agents that talk to people read a filtered view and can change nothing.

A single author avoids the failure mode where two conversations record contradictory things about the same fact, and it means there is exactly one place to look to understand why the system behaved as it did. There are two deliberate exceptions. The guard corrects the document when a quiet-room audit finds it does not match what actually happened — a proofreader, not a second author. AccUpdate brings standing account knowledge into one participant's branch when the durable document has changed — a courier, not a second author. Neither may steer, write guidance, or touch anything outside its lane, precisely so the single-writer property survives in spirit.

The planner is told to be generous: not just the transactional facts, but how the person talks, what they care about, what is going on in their life — because detail it skips is detail no agent will ever have. Everything the planner itself records must come from the transcript. A persona's own unsupported claim is an error to correct, not information to record, and a counterparty's reference to something off-screen ("the document in your inbox") is recorded as a claim, never as fact. Standing knowledge the system merged from the account's durable memory is the exception that is not contamination: it is announced in the transcript as a system line, and the planner is told never to delete or quarantine it as unsourced just because this sitting's messages did not mention it.

Why there is no fixed schema

The obvious design is a defined structure: preferences here, offers there, notes in a third place. We tried that and abandoned it.

Real conversations produce facts no schema anticipates. A talent mentions they are racing abroad every October and unavailable. That is not a preference, not an offer, and not a note — but it is decisive, because an otherwise perfect offer with an October timeline has to be pushed. With a fixed structure, either that fact is discarded or an engineer ships a migration for every new kind of thing a person might say.

So the document has no fixed shape. The planner decides how to organise it and reorganises it when something new does not fit. In practice it invents sensible structures on its own and keeps them stable across a conversation.

The cost is that nothing downstream can assume a particular field exists. We accepted that: the alternative is a system whose understanding of a person is capped by what was imagined in advance.

The four reserved parts

Exactly four parts of the document are fixed, because the rest of the product needs to know them. Everything else is the planner's to shape.

Goals

Every room declares its goals — for a talent-and-brand room: the talent's setup is complete, and the negotiation reaches an outcome. The planner keeps a small envelope per goal: what it is, who it is for, and a status — open, met, blocked, or abandoned.

Status is the one field code reads, and code acts the moment it flips. A goal turning "met" can trigger real effects: notifying a participant, or generating the formal offer document. That makes goals the hinge between the intelligent layer and the physical one — the planner judges, and the flip makes it real.

Two things took iteration to get right. First, a goal can end without succeeding: a rejected offer or a brand that walks away is marked abandoned, which is as final as met — the planner stops steering toward it and nothing fires on it. Second, a goal is about its substance, not the follow-up chores: things still needed from a participant afterwards (a signature, an address) do not hold a goal open — they become messages pushed to that participant instead.

The planner also creates goals of its own, under the same envelope, whenever it takes on an obligation — something it promised a participant, or something one participant is waiting on another for — and deletes them once resolved.

Guidance

The planner steers the personas by writing instructions addressed to each one: what to ask next, what to stop asking, what to press on, how to handle the situation the agent is walking into. An agent follows its guidance above its own general instructions — this is the planner's strongest lever.

Guidance is keyed per participant, and delivery is done by code, not judgement: each persona receives exactly its own entry, in full, on every turn, and never sees anyone else's.

Guidance is split cleanly between the two planner stages:

  • PlannerGuidAg exclusively writes guidance.<activeKey> for the participant who just sent a message, immediately before that persona answers.
  • PlannerDistilMemAg may write guidance for other participants (e.g. for an upcoming wake or future turn), but any update targeting the active participant's guidance branch is automatically dropped by code (dropActiveGuidanceUpdates) so it cannot clobber PlannerGuidAg's fresh instructions.

Guidance is also transient: an empty string clears an entry once it has been acted on, so no agent follows a stale instruction.

Flags

The planner's channel to human operators. If a participant is losing patience — repeated asks that keep getting deflected, sarcasm about talking to a machine, an outright request for a human — the planner raises a frustration flag with a level and a one-line justification from the transcript. Flags are visible to operators, invisible to every agent, and change nothing in any conversation. The planner keeps them honest: escalate when it worsens, delete when the tone genuinely recovers, because a stale flag is noise operators learn to ignore.

The planner's private notes

The planner's own working thinking — strategy across the next few exchanges, unconfirmed hunches, per-brand negotiation patterns, what it would do differently. Never shown to any agent, and removed before the context filter can even see it (see the privacy boundary below). This is where unconfirmed thinking lives; only what the transcript actually supports gets promoted to the facts.

What is not in memory: the physical layer

Some truths are deliberately kept out of memory and shown to the agents live instead.

When a participant is bound to a real account, the account's facts are appended to the agent's instructions at call time — always current, never duplicated into a document that could go stale. When a negotiation produces a formal offer, the memory holds a reference and the planner is shown the offer's real status live; the terms themselves live only in the offer document that Offer-Gen produced. And every planner and guard run receives the dispatch record — the system's ground-truth list of messages actually delivered to participants — because the one thing an intelligence must never be allowed to remember wrongly is what it has and has not done. The rule of thumb: memory holds understanding, the physical layer holds records, and records are projected in rather than copied.

Account-memory merges are announced

A silent merge looks like unsourced contamination to a planner told that everything must come from the transcript. So after AccUpdate writes, the room stores an assistant-role message on that participant's pane carrying the account's name and the paths that changed. The transcript renderer turns that into a line of the form SYSTEM [account-memory merge]: standing knowledge about the account merged into the participant's branch (paths: …). The planner, the guard and the Arvist all read it. The playground shows a banner — "Updates from durable memory about the account" — with the same collapsible change list used for planner writes. Product panes ignore the part, so the person in the conversation never sees it.

The merge itself is a locked write: the room's memory is re-read under a transaction lock, the path updates are applied to whatever is there now, and only then is the document stored. A concurrent planner cannot be clobbered by a precomputed snapshot, and the planner does not start until the merge has landed.

Changes are targeted, not rewrites

When the planner updates memory, it names the specific parts that changed rather than returning a fresh copy of the whole document.

This is a reliability decision. A model asked to rewrite a large document will occasionally drop something unrelated on the way past, and that loss is silent — the talent's October blackout simply stops existing, and nobody finds out until an offer is mishandled. A targeted change cannot damage a part it did not name.

It also makes the history readable: every change is recorded as what changed, when, in response to which message, and what the memory looked like before and after.

Sessions: what the planner re-reads

Conversations accumulate, but understanding does not need to be re-derived. The transcript is partitioned into sessions — a session starts when the planner reaches out unprompted, or when a participant returns after a long pause — and the planner reads only the current session. Everything earlier was already reviewed by the planner runs that followed each turn and distilled into memory, so the trimmed transcript simply tells the planner to trust the memory for anything before this sitting.

This mirrors how a human assistant works: they remember the relationship, not every word of every past meeting. It is also what keeps cost flat — without it, each planner run re-reads the whole history and the cost of a room grows with the square of its length.

The privacy boundary

The planner's private notes must never reach a conversational agent. The reason is concrete: a note like "this brand is clearly desperate and will pay more than they claim" is exactly the kind of thing that is useful to the planner and damaging if it reaches the agent negotiating with that brand.

We first tried instructing the filter to withhold them. It did not hold. The filter is also told to be generous, generosity won, and internal notes reached the brand-facing agent.

The boundary is now enforced structurally: private notes, flags, and the guidance branch are all removed before the filter ever sees the document, so they are not available to be selected, and no instruction can override it. Guidance is then re-attached by code — each agent gets exactly its own.

The general principle is worth stating plainly, because it applies well beyond this feature: a confidentiality guarantee should not depend on a model's judgement. If it matters, it belongs in the mechanism, not in a prompt.

Auditability

Because there is one writer and changes are targeted, the system can answer after the fact:

  • What did the agent know at the moment it said that?
  • What changed in the system's understanding, and which message caused it?
  • Which standing knowledge was merged from durable memory, and from which account?
  • Which instruction was the agent following?
  • When was a goal judged met or abandoned, and on what basis?
  • What did each step cost? Every model call is recorded with its tokens and its actual billed price.

For a system acting on someone's commercial interests, being able to reconstruct why it did what it did is not a nice-to-have.