Overview

How Zooly uses an AI mediator to handle inbound deals on a principal's behalf

Accounts do not have a stored user type. Every account gets Bouncer (inbound offers) and Scout (outbound search), while Roster is enabled only when the person manages offers for others. A conversation uses generic host / visitor seats. The seats and mediator are deliberately not talent-specific. See Capabilities, Seats, and Derived Role.

The problem

A creator with an audience gets approached constantly. Most approaches are noise: wrong category, no budget, missing the details needed to judge them at all. The few good ones are easy to lose, because a brand that waits a week for a reply moves on.

Handling this properly is a job. A human agent knows the principal's boundaries, answers counterparties quickly, pushes back on bad terms, and only involves the principal when something is worth their attention. That works, and it does not scale: good agents are expensive, they represent a limited roster, and they are not available at 2am when an offer lands from another timezone.

Zooly's answer is an AI mediator that does the same job. It learns what the principal wants once, then represents them continuously — evaluating offers, negotiating within a mandate, and bringing them only what matters.

The shape of the solution

Everything happens inside a room. A room holds a set of participants — today, typically a host (the represented principal) and a visitor (the counterparty) — and the central rule is that participants never speak to each other. Each participant has their own private conversation with their own AI agent, and a mediator sits between all of them.

Nothing passes between the conversations except what the planner decides should pass. That single constraint is what makes the system work:

Confidentiality. The visitor never learns the host's real floor, how eager they are, or what they said about the visitor's category. A human agent would never reveal these; the structure here makes it impossible rather than a matter of discretion.

Availability. The host does not need to be reachable for the system to act on their behalf. Their preferences were captured earlier and are applied whenever an offer arrives. And when something happens that a participant should hear about — a deal came together, information they were waiting for arrived — the planner reaches out to them rather than waiting for them to ask.

Consistency. A stated rule is applied the same way every time. An offer below the floor is declined at 2am exactly as it would be at noon.

The two-participant host-and-visitor room is the first product built on this, but nothing in the design assumes two. A room can hold one participant (a host doing setup in their home room), or more, with the same rules: everyone talks only to their own agent, and the planner carries what matters between them.

Two layers: understanding and record

The system deliberately keeps two kinds of state, and treats them differently.

The intelligent layer is the mediator's understanding: a free-form memory document the planner writes as conversations progress. It holds what the host wants, where each negotiation stands, and the human detail that makes an agent sound like it knows the person. It is opaque by design — organised however the planner finds useful.

The physical layer is the record: real accounts, and real offer documents with exact amounts that the two sides Approve and pay against. Nothing in the intelligent layer is binding; when a negotiation concludes, a dedicated agent extracts the agreed terms into a formal draft offer, and that document — not the memory — is what the deal ultimately rests on. Both sides Approve on that page (brand first is thanks only; talent Approve is accept). The brand then pays in Send Payment. A second specialist, AgreementAg, turns the Offer into lawyer-reviewable prose. It never sees the chat.

The boundary matters because it answers "what is actually true": memory is the system's working belief; the physical layer is the ground truth. Facts from the physical layer (who the account is, what an offer's real status is) are shown to the agents live rather than copied into memory, so they can never be stale.

What each side experiences

The host has a conversation once, in plain language, about what they want: which kinds of partnership interest them, which categories are an automatic no, what an offer must spell out before it is worth reading, what they charge, when they are unavailable. Later, they hear from their agent only when something has actually happened — most usefully, when terms have been negotiated and need their approval on the written Offer. After they Approve, the brand pays in the product (Send Payment) — not in chat.

The visitor has a normal commercial conversation with what behaves like the host's agent. It answers immediately, knows the principal's requirements, asks for what is missing, pushes back on terms that do not work, and can settle terms without going away to "check with the client". When a formal offer exists, they Approve on the document (acknowledgement first, not pay), then after the talent Approves they open Send Payment in the product.

Both agents are instructed to talk like busy humans: short replies, one question at a time, and no echoing back what the person just said — the formal agreement at the end is where terms get restated, not the chat.

In the product, both of these are permanent, ongoing conversations rather than one-off negotiations: the account has one home room and one durable memory shared by its agent capabilities, and each conversation a visitor starts through the host's link stays open forever — reachable again from a link, an email, or the picker of their past conversations with that host. A visitor doesn't even need an account to start talking; they are asked to sign in only when the agent actually needs to move the deal. Rooms in the Product covers how that attaches to real accounts.

Why more than one AI

It would be simpler to have a single AI hold both conversations. We deliberately did not, because one model doing everything creates two problems that have no good fix: it can leak what it knows from one conversation into the other, and it has no stable memory of the host beyond whatever happens to be in front of it.

Instead the work is split across roles with different jobs and different access. Only the persona agents talk to people. Each persona reads the whole visible room memory and replies, and it owns the room's goals and pushes. PlannerDistilMemAg writes only the room's memory (facts and preferences) in the background after the reply. AccUpdate brings standing account knowledge into a room when the durable memory has changed since that room last saw it. A guard, ZGuard, audits every room once it goes quiet: it verifies the record is truthful — nothing claimed as done that never happened, nobody left waiting for a message that was never sent — and repairs what does not hold up. Four back-office roles handle what outlives a conversation: the Arvist curates what the system keeps about a person long-term (immediately after Distil on Update Agent; after a quiet sit on other rooms), Offer-Gen turns a concluded negotiation into a formal offer document, Offer-Update keeps that document in sync when the negotiation moves on after it was written, and AgreementAg turns the current Offer into a lawyer-reviewable draft without reading the chat. The next page describes them.

What this is not

This is not an autonomous system that commits the principal to contracts. A deal's stage is the written offer in the product, not a chat agreement. Agents may settle terms in conversation and may record a principal's chat yes as an instruction — "here is what I negotiated, do you want these terms?" — but nothing is a booking until the talent Approves that document. A principal who first hears of a deal as a done deal was never given a choice. See Deals move through explicit physical stages. Once that document is booked, it stays frozen in its conversation; a later campaign or a wanted change is a new room for the same pair.

Bouncer handles offers that arrive. Scout handles outbound discovery and is enabled by default alongside Bouncer; that agent is still a preview. Roster management is conditional for anyone who represents more than themselves.