Sharing, Access & Monetization

Open the agent detail page, click the Accesstab (visible to the owner), enter your teammate's email, and click Add operator. The email is also added to the platform login whitelist, so they can sign in with an email verification code. Their row shows Active if they already have a Trinity account, or Pending("Invited — no account yet") until their first login; each row also carries an off-by-default toggle that lets the agent message that person proactively. Sharing puts the agent on their Workspace roster as well. Click Remove on a row to revoke access at any time. See Agent Sharing.

Shared operators get interact-level access: they can chat with the agent, run tasks, and view its files and logs. They cannot modify the agent's configuration, credentials, schedules, or permissions, and they cannot delete or re-share it — those actions stay with the owner (and admins, who have full access to all agents). Every API endpoint checks ownership or sharing status before granting access. See Agent Sharing.

That's by design. Shared users see only their own chat messages with an agent — each person's conversation history is private to them. Only admins can see all messages. If your teammate needs the content of a past conversation, share it with them directly. See Agent Sharing.

The Accesstab manages Trinity operators — platform users (your teammates) who log into the Trinity UI and get interact-level access. The Sharingtab manages external clients — people without a Trinity account who reach the agent through Slack, Telegram, WhatsApp, voice calls, public links, or the Workspace, identified by verified email. The Sharing tab also holds the Restricted/Open access switch with pending access requests, the Public chat model and Additional instructionsthat apply only to outside audiences (public links, channels, paid chat — never your own chats or schedules), channel configuration, a read-only client roster, and the public links and file sharing panels. See Agent Sharing.

Trinity has four hierarchical roles: admin > creator > operator > user. Admins can create agents and manage every agent on the platform; creators can create agents and manage their own; operators cannot create agents but can work with agents assigned to them; users cannot create or manage agents but can chat with agents shared with them. Higher roles inherit all permissions of lower ones. See Roles and Permissions.

Creating agents requires the creator role or above. If a teammate needs to create agents, an admin can promote them: go to Settings → Access → User Management, find the user in the table, and pick a new role from the dropdown — the change takes effect on their next request. You cannot change your own role, and admins cannot demote themselves. See Roles and Permissions.

Each role has a limit on how many agents it can own: by default creators get 10, operators 3, and users 1 (admins are always unlimited). When you're at your limit, agent creation is rejected with HTTP 429 and a message of the form Agent quota exceeded. You have 10/10 agents. Delete an agent to create a new one. (code QUOTA_EXCEEDED, with your current count and limit). Admins can raise the per-role limits under Settings → Agent Quotas (enter 0for unlimited). Redeploying an agent you already own doesn't count against your quota, and system agents are excluded from the count. See Agent Quotas.

The role comes from their email whitelist entry: each whitelisted email carries a default role that is assigned on first login, and it falls back to the basic userrole if none was set. Adding someone through an agent's Access tab or approving their access request whitelists them as a user— a chat-only grant that never silently promotes anyone. An admin can promote them afterwards via Settings → Access → User Management. See Roles and Permissions.

Not unless you explicitly allow it — public self-signup is off by default, and the email whitelist stays the real access gate. The unauthenticated access-request endpoint returns 403 and tells the person to ask an administrator to whitelist their email. An admin can opt in via the PUBLIC_ACCESS_REQUESTS_ENABLED environment variable or the matching system setting; when enabled, self-signups are auto-whitelisted with the basic user role. See Roles and Permissions.

When an agent is in Restrictedmode and an unknown user with a verified email messages it — from any channel — they see "Your access request is pending approval" and a request appears under the Restricted/Open switch in the agent's Sharing tab. Click Approve to add their email to the share list, which admits them on every channel at once; click Denyto reject silently (the agent's existence is not confirmed). If the request came in over Telegram, Slack, or WhatsApp, Trinity automatically messages the requester on that same channel to confirm access; a delivery failure never rolls back the approval. See Access Control.

It's a single per-agent switch under "Who can chat with this agent?" on the Sharing tab. Restricted(the default) means only the owner, admins, and explicitly approved emails can chat — everyone else generates a pending access request. Open means anyone with a verified email can chat immediately. Email verification is not a separate switch on that tab: both positions of the control require a verified email (it writes require_email: true either way), and turning verification off entirely (require_email: false) is possible only through the access-policy API (PUT /api/agents/{name}/access-policy). The fleet-wide default that newly created agents start with lives under Settings → Generaland applies at creation time only — existing agents are never rewritten. See Access Control.

Sharing grants a Trinity account holder interact access through the logged-in UI. A public link is a shareable URL that lets anyone chat with the agent without logging in — optionally with email verification, rate limits, and a custom welcome message. Public-link conversations persist across page refreshes, and logged-in Trinity users get a history dropdown to resume past sessions. Create links under Sharing → Distribution → Public links on the agent detail page. See Public Links.

Yes. Each public link card carries a Slack row with a Connect Slackbutton (owner or admin only). If the platform's Slack workspace is already connected, Trinity creates a Slack channel named after the agent, binds the agent to it, and makes the agent the DM default when it is the first agent bound in that workspace. If no workspace is connected yet, the button opens Slack's authorization page — the platform Slack app must be configured under Settings → Integrations → Slack first, otherwise the button reports that Slack is not configured. Once connected, the row shows the workspace name and who connected it, with an enable/disable toggle and Disconnect Slack; the Slack conversation follows the same access rules as the link itself. See Public Links.

The Workspace at /workspaceis the signed-in chat app for the people you share agents with — and for you. It ships in every build (the old /portalpath redirects there), and it is the one surface where a conversation keeps the agent's working memory between turns, where every (you, agent) pair has a pinned Mainchat plus as many named chats as you like, and where several agents can work one thread together. Platform users open it from the nav — it opens in its own browser tab, and your platform session is your Workspace session; external clients sign in with a 6-digit email code, get no platform account, and see only the agents shared with their address. Clicking an agent opens the chat you were last in with it — Main when there is no other. See Workspace.

Type @and the other agent's name in an existing one-to-one chat. The Workspace opens a room containing both agents and posts your message there, leaving the original chat untouched. Inside a room, + Add agent(or mentioning an agent that isn't yet a participant) recruits it — only a person can do that, never another agent — and @ keeps working there while the / playbook picker is not offered in rooms. An @namethat isn't one of your agents stays plain text. Multi-agent chat is part of the open-source platform — it used to be an enterprise capability, and against an older backend that lacks it the picker is single-select and mentions stay ordinary text. See Workspace.

Clicking an agent opens the conversation, not a report about it. A band under the header of every chat with that agent shows its tasks in the last 7 days (a fixed window), the share completed, the share that succeeded first try, a Helpful / Not helpfultally, and a small activity chart. Everything else sits in the rail's Infotab: name and description with health and availability as separate facts, the client's own chats with unread counts, What it can do capability cards that pre-fill the composer, and the reports addressed to them. Beyond Info, a client gets Files (files exchanged in the chat) and Canvas (only canvases the agent published to its roster); the Work and Loops tabs, the model dropdown, and voice calls are platform-user-only, and a client never sees loop runs it couldn't open. Nothing configures — no schedules, skills, logs, costs, or model details — and the live updates a client receives are scoped to the agents on their roster. Because it reads from stored data, a stopped agent still renders. See Workspace.

The rail's Canvas tab shows one canvas at a time; pick another from the chips above it, where a pinned canvas carries 📌 and comes first, and once an agent has more than six a Search canvases…box filters by title or id. The header states two facts — Updated 2h ago · agent last ran 40m ago— so you can judge freshness yourself, and PDFprints the open canvas through your browser's own print dialog. The agent's owner (or an admin), signed in as a platform user, also gets Manage: each row shows its age, a pin toggle and Delete, and a checkbox per row feeds Delete selectedwith one confirmation naming the count; everyone else — including every external client — has a read-only panel. The canvas you have open travels with each message you send from that chat, so add a column to this names the right one; it is context, not permission. Sharing a canvas by link is done from the agent's Canvas tab on Agent Detail, not from the rail (next question). See Workspace.

On the agent's Canvas tab on Agent Detail, Sharemints a link, and you choose who it reaches — the narrower option is preselected. People who already have access (the default) requires signing in, and only people who can already see the agent see the canvas; Anyone with the linkneeds no sign-in at all, and the dialog says so plainly because it reaches further than the canvas did before. A shared canvas stays current — whoever opens the link sees it as the agent updates it, with the last-updated time shown — and Revoke turns a link off; anyone holding it is told it was turned off rather than getting a broken page. Only the agent's owner or an admin can share, pin, or delete, and creating or revoking a link is recorded in the audit log. See Agent Canvas; what a canvas is and who sees which audience is in the Advanced Features FAQ.

Three ways to give someone access, for three audiences. A public linkis a single anonymous chat URL for one agent — no sign-in, no saved history, one agent per link. Sharing gives another Trinity operator interact-level access to an agent through the logged-in admin UI. The Workspaceis a signed-in app where a named external client verifies their email, picks among the agents shared with them, holds multiple saved conversations that keep their memory between turns, reads each agent's Info tab and the reports addressed to them, and exchanges files — a client workspace, not an anonymous URL and not the operator UI. Both it and the multi-agent rooms within it ship in every build. See Workspace.

A client session slides: it renews while the person uses the Workspace, ends after an idle window, and never outlives a hard cap — by default 7 idle days and 30 days in total. When it times out the sign-in form says Your session timed out, and signing in again returns them to where they were. Admins see the policy under Settings → Retention → Workspace sessions; changing the numbers requires an entitlement. Platform users have no separate Workspace session — their platform login is the Workspace login. See Workspace.

The button at the bottom of the Workspace sidebar signs you out. For a platform user it reads Sign out of Trinity, because the Workspace session isthe platform session — ending one ends the other. For an external client it is a plain Sign out. Identity never switches on its own: when a client's session expires on a browser that also holds an operator login, the sign-in form offers Continue as user@example.com as an explicit click rather than quietly carrying on as the operator. See Workspace.

A client's turns run on the model you set as the Public chat model on the agent's Sharing tab, falling back to the platform default; clients get no model control of their own. Platform users on a Claude-runtime agent do get a dropdown beside Send — Agent's default (…) plus three plain-language tiers, Most capable, Balanced — fast and smart, and Fastest— remembered per agent on their account. If the agent can't complete a turn on a chosen model, the reply says so and the choice reverts to the agent's default. See Workspace and Agent Sharing.

Yes. When the agent publishes a report with an audience_email— an address it is shared with, checked against its roster — the report becomes a deliverable: it appears in that person's Workspace under Info → Reports, and as a Delivered here card at the end of the chat whose turn produced it (the agent passes its execution_idand Trinity resolves the chat, so it can never post into a conversation it wasn't part of). Unaddressed reports never appear in the Workspace. Each deliverable carries Useful / Not what I needed; the second opens an optional comment box, one rating per person applies (clicking the other option corrects it), and a negative rating also raises a heads-up in your operator queue. The agent learns tallies only — never the words and never who rated it; operators read comments in full. See Agent Reports.

Yes. An agent addresses an approval or question to one person it is shared with by setting addressed_to_emailon the queue item; an address that isn't on its roster turns the item into an ordinary operator ask rather than being refused. The client sees it above the composer of the chat it belongs to — an ask raised outside any chat (by a scheduled run, say) attaches to their Mainchat with that agent — and the sidebar counts open asks separately from unread replies. Answering there records the decision exactly as an operator's would, including waking the agent when that setting is on, and the item stays visible to operators in the queue. The ask's context block is never shown to the client, and revoking the share hides the ask. See Approvals.

Yes, per client. Chat sends are limited per client per agent — 20 per minute and 300 per hour by default — and file sends per client at 20 per minute and 100 per hour, each answered with a 429 that names the reason (Too many messages to this agent., Too many uploads.); admins tune them with PORTAL_CHAT_BURST_LIMIT / PORTAL_CHAT_HOURLY_LIMIT and PORTAL_UPLOAD_BURST_LIMIT / PORTAL_UPLOAD_HOURLY_LIMITon the backend. Files are capped at 25 MB each and 20 per drop, turns on one chat are serialized (a second message while one runs is refused), and sign-in codes carry brute-force protection. The agent's own execution timeout and parallel capacity apply on top. See Workspace and the single-server guide.

Yes, with a Portal delegateMCP key. An admin mints it (human-only, via the scope choice on the create-key form); it reaches exactly one route — exchanging an end user's email for a Workspace session — so a trusted backend can act as that person and embed Workspace conversations in your own product, and every other path refuses it. The exchange endpoint requires an entitlement. See Authentication.

Use tags and saved views. Tag agents from the agent detail page (or via API/MCP — POST /api/agents/{name}/tags/{tag} adds one, tag_agent is the MCP tool); tags show as colored badges on agent tiles and drive the shared Dashboard filters that apply across the Timeline, Grid, and List views and persist across navigation. On the Grid view, dept-<name> and reports-to-<agent>tags draw the org overlay — department zones and reporting lines — and those two families can only be set by people, never by agent-scoped keys. For filter combinations you use often, create a System View— a saved filter of tags plus other criteria that persists across sessions. See Tags and Organization.

Yes. Trinity ships a mobile-optimized PWA at /m (for example http://your-domain.com/m) — install it via Add to Home Screen for a native-app feel. It has three tabs: Agents (list, chat, toggle autonomy, send tasks), Ops(answer the operator queue and acknowledge alerts — for an approval you tap an option, optionally add a note, then press an explicit Send, so nothing goes out on a single tap), and System (fleet health as Total / Running / Stopped / High Ctx counts, plus the fleet-level actions — Emergency Stop, Fleet Restart, Pause Schedules, Resume Schedules — each confirmed in a bottom sheet). It's built for quick interactions like answering an agent's question or flipping autonomy on and off. See Mobile Admin.

Yes, via per-request payments using the Nevermined x402 protocol. In the agent's payment settings, enter your Nevermined API key, Agent ID, and Plan ID, then enable payments — the agent gets a paid endpoint at POST /api/paid/{agent_name}/chat. Callers without payment credentials receive HTTP 402 with payment instructions, buy credits on the Nevermined checkout page, and retry with a payment-signature header; Trinity verifies the payment, deducts credits, and routes the message to the agent. See Nevermined x402 Payments.

Pricing lives in your Nevermined plan (which defines credit pricing and allocation — one plan per agent); on the Trinity side you set how many credits each chat request burns (credits_per_request, default 1, minimum 1). For testing, configure the agent with the sandbox environment (the default), which runs on the Base Sepolia testnet; switch to the liveenvironment for real payments on Base mainnet. Anyone can check an agent's payment requirements without authentication via GET /api/paid/{agent_name}/info. See Nevermined x402 Payments.

Payment history is available per agent via GET /api/nevermined/agents/{name}/payments, or through the get_nevermined_paymentsMCP tool. If a payment settles incorrectly, admins can list failed settlements and retry them manually — settlement failures are never retried automatically. See Nevermined x402 Payments.

First enable file sharing in the agent's Sharing tab (a restart mounts the publish volume). The agent then drops a file into /home/developer/public/ and calls the share_fileMCP tool, which returns a signed download URL valid for 7 days — it works anywhere a link works, including phone in-app browsers: images, audio, video, and PDF open inline and stream, HTML and SVG are always delivered as a download, and ?download=1 forces a download for any file. Limits: 50 MB per file, 500 MB per agent across active shares, and executables are blocked. The signed URL is the only credential a download needs, so revoke it if it reaches the wrong hands: active shares appear in the File Sharing panel with size, expiry, and download count, and Revoke kills a link immediately (downloads then return 410 Gone). See Agent Files.