Every account gets the same core agent; roster capability is inferred; deal rooms use host/visitor seats
Zooly does not persist a user type. An account is not "a talent", "a brand", or "an agency". Every account receives the same core agent capabilities: Bouncer for inbound offers and Scout for outbound search. A person's role in a conversation is whatever seat they occupy in that room.
This is the model the rest of Z-Agent, onboarding, and the dashboard menus are built on. Identity and Representation covers the host/visitor confidentiality invariant; this page covers how accounts, rooms, and menus are organized.
People do not identify as Talent / Brand / Agency. A producer, a manager, a label, and an investor all bounced off those labels. Storing a type also cannot express hybrids. The product therefore stores capabilities and relationships, never identity categories.
| Concept | Stored as | Replaces |
|---|---|---|
| Default capabilities | account_service: bouncer and scout | account.who (TALENT / BRAND / AGENCY) |
| Conditional capability | roster, enabled when the account manages others | An AGENCY account type |
| Deal-room seats | participant keys host / visitor | talent / brand |
| Host memory branch | room.memory.host (Z_AGENT_HOST_BRANCH) | room.memory.talent |
| Persona agents | persona-host / persona-visitor | persona-talent / persona-brand |
| Home room kind | one account-level home room (service = agent) | talent-home |
| Setup goal | account-setup | talent-setup |
| Negotiation goal | negotiation | brand-offer |
| Prompt language | "the principal" / "the visitor" | "the talent" / "the brand" |
| Management menu | Agents panel & New agent | Roster rail / My talents / My brands |
"Talent" and "brand" still appear in product copy for inbound deals — that is the Bouncer use case, not an account type. In a Bouncer deal room the host is typically the person receiving offers and the visitor is typically the counterparty making them. The seats themselves are generic so the same room machinery can represent other pairings later.
Capability records live in account_service (unique on accountId +
serviceKey). Every new and migrated account receives bouncer and scout.
Settings remain capability-specific; Bouncer currently stores the offer floor
and below-threshold behavior there.
| Key | Job | What it unlocks |
|---|---|---|
bouncer | Handle inbound deals and offers | Deal conversations inbox, Z Link, deal-preference and terms settings |
scout | Outbound partner search capabilities | Outbound communications in unified Conversations inbox |
roster | Manage other people, brands, or IP | Connected agent management in the Agents panel, managed-account creation, roster aggregation of conversations |
Roster is the only conditional capability. The AI enables it when onboarding establishes that offers are managed for other people, brands, teams, or properties. The user can also add new connected agents anytime via + New agent in the Agents panel (which auto-enrolls the roster capability if needed).
GET / POST / PATCH /api/account/services list, enroll, and update
settings. GET /api/account includes the services array. Account PATCH does
not accept a who field — that column is gone.
The platform uses a single, unified dashboard for all user types:
<Agent Name> > <Section> > <Thread Title> (e.g. Your AI agent Z > Conversations > Nike and Jessica Kim). The root breadcrumb toggles the Agents panel./dashboard/agent/conversations) — Unified inbox for all inbound ("They came to you") and outbound ("Z reached out") deal negotiations./dashboard/settings/profile) — Available on connected member agents./dashboard/agent/links) — Public live and preview links with QR codes./dashboard/agent/z-simulate) — Rehearsal against your real agent. Type a brief or click let me invent one (Flash Lite writes a visitor-only inbound from durable memory). See Test agent./dashboard/agent/update) — Private internal guidance thread to instruct Z and refine agent behavior.?layout=split), view room attachments/links, inspect the active Offer view ("On the table"), or review the Agreement view draft with legal disclaimer acknowledgement and download.Every deal room has two participants:
host — the represented principal. The agent in this seat is their
agent. Durable account memory seeds here.visitor — the counterparty speaking to that agent. Their account is
bound for identity, claiming, and offers, but never seeded into the
room. See Identity and Representation.The public Z Link (/z/:slug) always belongs to the host account named by the
slug. Login decides who the visitor is — including when that visitor has their
their own private commercial history.
Visitor routes live under /api/z-agent/visitor/rooms/.... Opening a claimed
or guest deal room goes through openVisitorRoom.
Kind home replaced talent-home. Each account has one permanent account-level
home room for onboarding and ongoing agent conversation (Update Agent once
the agent is live). Distil still writes room memory; Arvist then promotes the
host sitting immediately so a new z-link sees the change. The room's service is
agent; Bouncer and Scout do not create separate home rooms.
Onboarding creates or resumes that room with goals.account-setup.
Interview turns skip Distil; claim runs the one promotion pass and
ensures both default capabilities exist.
Deal rooms keep kind deal. Their goal is negotiation (Offer-Gen still
fires when that goal flips to met, then AgreementAg drafts the legal text
from the resulting Offer).
Durable memory is one flat, free-form document per account. Identity, inbound
rules, outbound goals, and roster context can inform the same agent without
asking the user to reintroduce themselves. Capability settings that must be
physical and exact (for example, a minimum offer threshold) remain in
account_service.settings; they are not separate intelligent memories.
/onboarding begins with an open question:
What do you want your Zooly agent to help with?
Inbound offers, outbound search, and roster management are shown as suggested
answers, not checkboxes. The user can answer freely. The planner gathers both
inbound and outbound requirements in the same conversation. At finalization,
an AI classification asks one narrow question of the transcript: does this
account manage offers for others? A confident yes enrolls roster; otherwise
the account remains Bouncer + Scout.
Details: Agent Setup Onboarding.
who, AccountWho, or
talent/brand/agency as an account discriminator.host participant in ROOM_KIND_DEAL.talent / brand in new code. Scenarios, personas,
and participant keys are host / visitor. Brief files on disk are
host.md / visitor.md.