Workspaces & roles

A workspace is your organisation inside Amomic-AI. The console calls it an organization: the menu at the top left, Create organization, Leave organization and the Organization ID all refer to your workspace. It owns your agents, knowledge bases, channel connections, conversations, tickets, contacts, API keys, and the subscription that pays for all of it. Everything you build lives in exactly one workspace, and a person can belong to more than one. See More than one workspace.

Two things make the workspace worth understanding on its own: it is the billing boundary, and it is the isolation boundary.

The isolation boundary #

Every read and write the platform performs is filtered by workspace before anything else is evaluated. There is no sharing setting, no "make this knowledge base public", and no cross-workspace agent. Concretely:

• An agent, a knowledge base, or a published version belongs to one workspace and cannot be copied to another from the product.
• A WhatsApp Business number connected to one workspace cannot be connected to a second — the attempt is refused with "This WhatsApp number is already connected to another workspace."
• A phone number provisioned for a workspace answers only that workspace's deployments.
• An API key reads and writes only its own workspace's data. There is no key that spans two.

If your company needs a hard separation — production versus a partner brand, or two subsidiaries that must not see each other's customers — two workspaces is the mechanism. There is no lighter-weight partition inside one.

The billing boundary #

The plan, the seat count, and the usage meters are all properties of the workspace, not of a person. Your plan sets hard caps on how many agents, knowledge bases, deployments, and team seats you can create; creating past a cap is refused with a message naming the limit. Limits and plans has the numbers.

Three consequences worth knowing before they surprise you:

• Currency is fixed at creation. A workspace bills in INR or USD, chosen when it is created, and it cannot be changed afterwards — a balance holding real credit cannot be revalued, and a subscription cannot be moved between payment providers. The currency also decides who processes payments and who charges tax. See your workspace currency. Billing in the other currency means a second workspace, with the isolation that implies.
• Pending invites consume seats. The Members tab counts active members plus outstanding invitations against the seat limit, so an invite that was never accepted still blocks the next one. Revoke it; an expired invite keeps counting until someone does.
• A suspended workspace stops working, for everyone. If a plan payment is still unpaid 3 days after it failed, the console collapses to the billing page and everything that serves your customers stops. Web chat shows visitors a neutral "isn't available" line, incoming WhatsApp messages are saved but not answered, no WhatsApp message or call goes out, incoming calls hear an out-of-service line rather than your agent, campaigns, call-backs and reminders are held, and developer API keys return 403 workspace_suspended. Billing keeps working. Only an owner can clear it, by paying the invoice; everything then resumes on its own. See When a payment fails.

The three roles #

There are exactly three: owner, admin, and member. They are ranked, and every permission check is "this rank or above" — so an owner passes every admin check without needing a second role.

There is exactly one owner per workspace, created when the workspace is created. Ownership moves by transfer, not by promotion.

What a member actually experiences #

Member is a genuine working role, not a read-only spectator seat. A member can handle the whole support day: go available for live handoffs, take over chats and calls, read every conversation in the inbox, claim an unassigned ticket, reply on it, add internal notes, escalate something they cannot resolve, and use the AI copilot on tickets they have claimed.

What they cannot do is change how the product behaves. The write controls on Knowledge are removed from their view rather than shown as disabled buttons, and Campaigns, Channels and Developers are not in their sidebar at all. Agents is still in the sidebar, but the agent list and the agent pages don't load for a member: opening, testing and editing agents are admin work.

Three member-specific rules in ticketing are worth stating because they surprise people:

• A member must claim a ticket before working it. The composer says Claim this ticket before working on it. until they do.
• A member cannot assign a ticket to someone else, only to themselves.
• A member sees active tickets. Resolved and closed queues are an admin view.

What admin adds #

Admin is the "configures the product" role. Everything that changes what customers experience — the agent's instructions, what it knows, what it can do, which number it answers on — is admin and above, as is everything that hands out credentials.

Two admin powers deserve deliberate thought before you grant them:

• API keys. An admin can mint a key that sends WhatsApp messages and places calls on behalf of the whole workspace. The console says so on the page: "API keys can send messages and place calls on behalf of this whole workspace, so only owners and admins can manage them."
• Deployments. An admin can point a live phone number at a different agent. The change is auditable and reversible, but it takes effect on the next call.

What owner adds #

Owner adds money and succession: changing plan, paying, adding credits, editing tax details, cancelling, and transferring ownership. That is the entire delta. An owner is not a "super admin" with extra product powers — an admin can already configure everything.

Transferring ownership is a swap, not a copy. The dialog says so: They get full control of billing and the workspace, and you drop to admin. Only they can hand it back. The workspace never has two owners and never has none. Transfer ownership has the steps.

Inviting teammates #

Owners and admins invite people from Settings → Members with an email address and a role, Member or Admin. We email the invitation, and the console shows the link once so you can share it another way too. Invitations expire after 72 hours, and pending invites count against your plan's seats. Your team has the full how-to, including what the person you invite sees.

API keys are workspace credentials #

This is the single most important thing to understand about programmatic access, and it is a deliberate design choice rather than a missing feature.

An API key authenticates the workspace, not a user and not an agent. There is no per-user key, no per-agent key, and no per-origin key. A key does not inherit the role of whoever created it, and actions taken with it are not attributed to a person.

Scopes are the only partition. A key carries a set of the eleven accepted scopes, granted at creation, and that set is the whole of its authority:

The other two, appointments:read and appointments:write, appear in the create dialog but unlock no route today, so don't tick them.

In the create dialog, Read conversations and Read agents start ticked; untick what you don't need. A key's scopes can't be changed after it is created: to widen or narrow one, create a new key and revoke the old one. Scopes has the full endpoint matrix, including the fact that reading a ticket requires tickets:write because there is no read-only ticket scope.

Practical consequences of workspace-scoping:

• Give each system its own key. Not because the keys differ in power by default, but because separate keys are separately revocable and separately visible in the request log. Your order service and your CRM sync should not share one.
• Grant the narrowest scope set that works. A key that only needs to send order updates gets messages:send and nothing else. It then cannot read a single conversation even if it is stolen.
• Never put a key in front-end code. /api/v1 sends no CORS headers precisely so that this fails loudly rather than working until someone reads your bundle.
• Rotate with Roll, not Revoke. Rolling issues a replacement and keeps the old key working for 24 hours, which is enough to redeploy. Revoking kills it within seconds.

The full mechanics — the one-time reveal, the amk_live_ / amk_test_ split, and the six distinct causes of a 401 — are in Authentication.

Who should be what #

Some opinionated defaults that hold up in most teams.

Owner: one person, usually whoever owns the budget. Not the most technical person, and not a shared account. The owner is who your renewal fails on and who has to act at 9 a.m. on a Monday when a payment bounces. Transfer it when that person changes jobs rather than sharing their login.

Admin: the two or three people who build the product. Whoever writes the agent's instructions, curates the knowledge, and owns the integration. Keep this list short — an admin can repoint a live phone number and mint a key that sends messages to your entire customer list.

Member: everyone else, including most of the support team. A member can do all the day-to-day work and cannot accidentally change what an agent says to twenty thousand customers. Support agents, analysts, and anyone who mainly reads should be members.

Two failure modes to avoid:

• Making everyone an admin so nobody is blocked. The most common reason a live agent changed unexpectedly is that seven people could change it.
• Making the only technical person a member. They will be blocked on every knowledge fix and you will end up sharing an admin login, which is worse than the grant you were avoiding.

More than one workspace #

One person can belong to several workspaces at once, with a different role in each: an owner of their own business and a member of a client's, for example. Memberships are independent of each other.

Each browser tab works in one workspace. The organization menu at the top left lists every workspace you belong to. Choosing one moves that tab only. Another tab can stay in a different workspace, and everything you do in a tab (replies, settings, deployments, API keys) happens in that tab's workspace. Use the arrow beside a workspace in the menu to open it in a new tab. A new tab opens in the workspace you used last.

Invitations reach you inside the console too. An invitation to another workspace still arrives by email. If you are signed in, it also shows as a banner and under Invitations in the organization menu, where you can accept or decline it. Accepting opens the new workspace in that tab. Your role in the workspaces you already belong to doesn't change. An invitation to a workspace you are already in can't be sent; change a role on the Members tab instead.

Create another workspace from Create organization at the bottom of the organization menu. It gets its own plan, currency, team and channels.

Open a link in a specific workspace by adding ?org=<Organization ID> to a console URL. The tab switches to that workspace and the parameter is removed.

Leave a workspace from Settings → Organization → Leave organization. Any role can leave. The workspace disappears from your organization menu, any open tab on it moves to your next workspace, and your other workspaces are not affected. The only owner of a workspace can't leave it. Transfer ownership first. There is no control to delete a workspace in the console.

Also on the Settings page #

Beyond Members, Settings holds the workspace's name, country, time zone and Organization ID, the switch for remembering customers between conversations, the India-only Compliance tab, your own profile and phone verification, and your notifications. Settings covers every tab, including which notification emails are actually sent.

Next #