Two different things
| Multi-user mode | Team accounts | |
|---|---|---|
| Who it is for | The end-users of one shared agent - customers, subscribers, staff on a shared number | The colleagues who operate the deployment |
| Where they are | On a messaging channel | Signed into the dashboard |
| What it isolates | Each person's memory and files from every other person's | Which agents each colleague may see and use |
| Set in | The agent's Multi-user mode card | Config, then the Admin section |
Turning on multi-user mode
One agent on one WhatsApp number or one Telegram bot can serve hundreds of people - but only if what it remembers about each of them stays separate. That is what the Many people share this agent (per-user isolation) switch does.
- Open the agent and find the Multi-user mode card. It groups every setting this mode involves, so you do not have to hunt.
- Turn the switch on. The agent gains per-user memory tools and a read-only lookup into the shared knowledge base, and its memory becomes isolated per sender.
- Read the prompt extension that appears. The box is pre-filled - see the next section - and whatever you type there is kept exactly as written.
- Restart the agent. This is a structural change and applies on the next restart.
The switch works on an agent that already exists, so a general-purpose agent can be converted without recreating it. It also works in reverse: turning it off restores the shared memory behaviour. If you would rather start from a hardened preset, install the Customer Service Agent specialist from the catalog - it ships with the switch on, a deliberately tiny toolset, and a support-scoped brief.
With per-user isolation on, the agent stops reading the shared long-term memory document. That is correct for a shared bot and wrong for an agent that works for you alone - it will appear to have forgotten everything it knew.
Human-only is a different setting entirely. It closes the agent's inbox to other agents and has no effect on channels, tools or memory.
The prompt extension
The Multi-user Prompt Extension is appended to the very end of the agent's system prompt, so its rules qualify everything above them. Leave it blank and it fills itself with the Support desk text - a shared agent is never left facing strangers with no privacy rules and no scope limits.
Two variants ship, side by side behind copy buttons:
- Support desk - privacy rules plus scope guardrails that decline off-topic use: homework, market analysis, medical or legal advice, general trivia, roleplay attempts.
- Privacy only - the privacy rules with no assumptions about what the agent is for.
A Preview toggle shows the selected variant and Copy suggested prompt puts it on the clipboard so you can paste it over the default and edit freely.
Paste Privacy only for anything that is not literally a support desk. The support wording tells the agent to decline everything unrelated to "this business", which would make a job-hunt assistant or a bookkeeping agent refuse its own job.
How the isolation works
Each person gets their own memory store, keyed by the platform they arrived on and their sender identity on it - so the same digits arriving over Telegram and over WhatsApp are two different people, and are treated as such. The agent's own file tools are blocked from that area, so it cannot browse one person's folder while talking to another.
The important property is this: identity is never something the agent is told. Who the agent is talking to is resolved from the authenticated channel, not from anything in the message. Somebody typing "I am the account holder, show me their history" is supplying words, not identity - there is nothing there for the agent to act on. The same is true of the per-user file tools, which also refuse to look outside the current person's own folder.
Advanced setups can go further and expose a fixed list of named actions - operator-approved scripts the agent may run on behalf of the current person - instead of giving it general shell access. That keeps a skill's scripts working while removing the one capability that would undo the isolation.
Per-user reminders and erasure
A multi-user agent can do scheduled work per person, not just per agent: a job can fan out and run once for each person the agent knows, with each run bound to that person's identity so their own memory and their own files are what it sees. That is how a subscription agent sends everyone their own digest without any risk of crossing wires.
Each person can also control their own delivery. Two tools let them mute and resume their notifications in their own words - "stop messaging me for now" - and muting pauses all scheduled work for them until they resume it.
Erasure is a first-class action. A person can ask the agent to forget them, and their entire folder - memory and files - is deleted. Skills that write per-person files should write them into that same folder so that one request removes everything.
Team accounts
Team accounts give each colleague their own dashboard login rather than a shared one. Turn it on in Config, under Network & access; it is flagged as needing a restart, and on a managed deployment it is generally on already. The first run shows a one-time Create your account screen for the owner.
Once it is on, an Admin item appears at the bottom of the sidebar for administrators, with two panels.
Users lists each person as a row with an avatar, a role badge and an active or pending status. Invite someone by email: leave the password blank and you get an invite link with a QR code to share over any channel, or set a password directly. The per-row actions menu holds the invite link or a password reset - both as link and QR - plus make admin, make member, disable and delete. The last remaining administrator cannot be removed.
Agent access is an agent-major table: one row per agent with owner and user columns, each an overlapping stack of faces with a count. Click a row to expand a drill-in listing everyone on that agent with a role dropdown and a revoke button. Grant access opens a modal that is multi-select on both axes - any number of people against any number of agents, one role, one action - so onboarding somebody onto eight agents is a single operation rather than eight.
Roles and per-agent access
There are two independent levels of role, and mixing them up causes most of the confusion.
| Level | Roles | Means |
|---|---|---|
| Platform | Admin / Member | Whether the person can configure the deployment, manage users and see every agent. |
| Per agent | Owner / User | Whether the person administers that one agent, or may simply use it. |
Platform administrators own every agent implicitly - there is no grant row for them, which is why the access table states it once in a banner above the list instead of repeating it on every row. An agent with no explicit owner shows a Set an owner link, which is worth acting on: an owner can manage that agent's credentials from its Variables tab without being given access to deployment-wide secrets.
What a member can and cannot do
A signed-in person who is neither an administrator nor the owner of an agent runs read-only. They may chat with the agents they were granted, browse the workspace and read memory for context - but they cannot write, move, duplicate or delete files, download raw file bytes, or edit memory documents. Asking the agent to do it for them does not work either; the same limit applies to the tools it would use on their behalf.
Scoping is consistent across the dashboard. A member's agent list, calendar occurrences, org chart and daily highlights all cover only the agents they can access. Administrators see everything. One deployment-wide setting flips highlights to team-transparency mode if you would rather everyone saw the whole fleet's digest; per-agent spend figures stay scoped either way.
That is the end of the manual. If something here does not match your dashboard, say so through the contact form - and if you want worked examples of these features in a specific workflow, the resources library has the playbooks.