Product Update
How a Team Shares One AI Agent: Roles, Assignment, Escalation and Who Gets Told
The multi-agent detour
A lot of platform marketing is about agents delegating to agents — a leader that routes, a swarm that collaborates, a pipeline of fixed tasks. It is genuinely interesting engineering. For a business that wants its customers answered on its website, WhatsApp, Telegram and the phone, it is not the bottleneck.
The bottleneck is people. One agent handles the conversations it can. The rest reach a human, and the only questions that matter are which human, how soon, and whether anybody noticed.
One workspace, three roles
A workspace has members, and a member is an owner, an admin, or a member. Invitations, role changes and removal are all in the console. Isolation between workspaces is enforced twice — row-level security for the console, and an explicit tenant filter in the runtime that answers customers — with automated assertions covering both paths rather than one.
Somebody joining the workspace shows up in the notifications feed, as does an API key being created. Both are the kind of thing you want to learn on the day rather than during an audit.
A conversation can be somebody's job
Any conversation in the shared inbox can be assigned to a member of the workspace. That is a deliberate act with a deliberate meaning, and it is not the same as a human taking over:
- Assignment says whose job this is. You can assign a thread before anybody has replied, and it does not silence the agent — a thread can be assigned to somebody to watch while the agent still handles it.
- Takeover is a teammate actually replying. That is what silences the agent, and it is read back out of the messages rather than kept as a separate switch, so there is never a window where a person and the agent are both answering.
- No assignee is a real answer. Clearing it puts the thread back in the shared pool, which is how a team hands work around when somebody goes to lunch.
The assignee is verified against the workspace's member list on the server. A user id arriving from a browser is not evidence of anything, and without that check a conversation could be assigned to somebody outside the workspace who would then find it sitting in their queue.
Escalation is the routing you configure
The agent decides when to involve a person, using triggers you set per agent: hand over when it cannot answer, hand over when the customer asks for a person or is upset, or neither.
Turning a trigger off removes the escalation tool from the agent. It is not a line in the prompt asking nicely — there is nothing to call, so the behaviour cannot happen. When the agent does hand over it says so to the customer, and the reasoning it wrote about why stays internal.
Routing, honestly
There is no rules engine that sends billing questions to one teammate and shipping questions to another. Routing here is three steps: the agent escalates on the triggers you set, the conversation lands in one shared inbox, and a person assigns it.
That is a shared queue with assignment, not a skills-based contact centre. There are no SLA timers, no shift rotas, no round-robin, no overflow rules. For a team small enough to see the whole queue on one screen, that is the correct amount of machinery, and we would rather write this paragraph than draw a routing diagram we do not have.
Who gets told, without watching for it
Everything the platform knows about a workspace lands in one feed, with a bell in the top bar and a page of its own. The entries a team lives on:
- Conversations that need a person — the path for the majority of workspaces, who have wired neither a webhook nor a helpdesk.
- Campaigns finishing, and separately, campaigns finishing badly.
- Documents that could not be indexed, with the reason. A source that silently failed to index is a question the agent will answer wrongly for months.
- A webhook we switched off after five consecutive failures.
- WhatsApp account health and template verdicts — approvals, rejections with Meta's own reason, quality dropping, and the number being flagged.
- Somebody joining the workspace, and an API key being created.
If your team already lives somewhere else, signed outbound webhooks carry five events to any HTTPS endpoint you control, chosen per endpoint: a lead, an escalation, a resolution, a finished call and a finished campaign.
What the team is actually working in
The inbox updates live, and the unread badge follows you across the console rather than only appearing on the inbox page. A teammate can reply with photos, video, audio and documents. Saved replies cover the sentences somebody writes forty times a week, with the customer's name filled in at the moment of insertion. Internal notes stay internal.
On WhatsApp, when the 24-hour window has closed the composer is replaced by an explanation rather than a text box, with a countdown through the final hour — so a teammate learns before writing a paragraph, not after.
What this post is not about
There are no team execution modes on this platform. No coordinate, route, collaborate or tasks; no leader agent delegating to member agents; no node graph and no drag-and-drop canvas. An agent is configured in a tabbed settings screen — instructions, knowledge, tools, channels — and the coordination happens between the people who own it.
If you are looking for agent-to-agent orchestration, we do not have it. What we do have is one agent that four people can run together without stepping on each other.
Get started
Invite your team, set escalation triggers on each agent, and give the notifications feed a week before deciding you need a webhook. Most teams find the bell is enough.
No credit card required • Trial includes 25 voice minutes and 200 chat replies
FAQ
Frequently Asked Questions
Can several people work the same AI agent inbox?
+
Does assigning a conversation stop the agent from replying?
+
Is there skills-based routing to send certain topics to certain people?
+
Does ThinnestAI support multi-agent teams that delegate to each other?
+
Docs