Organizations and regions
Organizations
An organization is a workspace. It owns its agents, phone numbers, documents, credit and members - nothing is shared with another organization.
One account can own or belong to several and switch between them. Use separate organizations for genuinely separate businesses, and environments plus folders to separate work inside one.
Members and roles
Invite people by email and give them a role. Roles decide what a member can do - read, build, publish, run calls, manage the organization - so a teammate iterating on prompts does not also have to be able to change its numbers or payment details.
Six roles come with every organization:
| Role | What it can do |
|---|---|
| Owner | Everything. Only an Owner can make someone an Owner or manage another Owner, and an organization always keeps at least one. |
| Admin | Everything except managing Owners: build and publish agents, manage members, roles, API keys, numbers, tools and settings, and top up credit. |
| Developer | Build, publish and run agents, edit the knowledge base, and see what an agent is built from. |
| Operator | Run agents and read the administrative records. Cannot change an agent. |
| Analyst | Read agents, the knowledge base and the administrative records. Changes nothing. |
| Viewer | Read agents, their sessions and analytics. |
Developer, Operator and Analyst can all read the organization's shared resources: its phone numbers, tools, campaigns, do-not-call list, integrations, automations and webhook endpoints. An agent is built out of those, so a role that can build agents but cannot see its own tools would not be able to do the job it exists for. Changing them stays with Owner and Admin.
The administrative records - the member list, the audit trail, API keys and API request logs - are readable by Owner, Admin, Operator and Analyst, but not by Developer or Viewer. Any member can see the organization's credit balance and usage.
A member can only grant permissions they hold themselves, whether by inviting someone, changing a role or creating a scoped API key.
You can also define your own roles from the same permission set when none of the six is the shape you want. The permissions are listed under Authentication.
Regions
Each organization is created in a region, which is where its data lives. The region is chosen at creation and is immutable afterwards: moving data between jurisdictions is not something that should happen silently, so it does not happen at all.
If you need an organization in a different region, create one there. The same account can hold both and switch between them.
Model providers process conversation content on their own infrastructure, which may be outside your region. If that matters for your compliance posture, use your own keys with a provider and endpoint you have chosen.
Environments
Every organization has three environments: Development, Staging and Production. They organise what you are building apart from what your callers are already using.
The intended flow:
- A new agent is created in Development. You build and test it there.
- When it is ready, you promote it to Staging or Production from the agent's menu. Promotion moves the agent - it leaves the environment it was in and now lives in the target. To keep iterating while a promoted version runs, duplicate the agent first and promote the copy.
- A phone number, a web-call token or an API call names a specific agent, and reaches that agent whichever environment it is in.
On the Agents page, the filter next to Active/Archived switches between All and a single environment. "All" shows every agent with a badge for its environment; a single environment shows just that one's. Staging and Production start empty - you promote into them rather than creating there.
Environments do not isolate edits. An agent always runs its current saved configuration, so a change you save reaches that agent's callers immediately, whichever environment it is in - publishing does not gate it. To try a change on an agent that is already taking calls, duplicate it and edit the copy.
Targeting an environment from the API
The dashboard tracks the active environment for you. Over the API, name it with the
X-Environment-Id header - a kind (dev, staging, prod) or an environment uuid:
curl https://api.glytos.com/api/v1/workflows \
-H "X-API-Key: $GLYTOS_API_KEY" \
-H "X-Environment-Id: prod"Without the header, requests use the organization's default environment. A value that matches no environment is not rejected: it silently falls back to the default as well.
The header scopes lists, such as the agents and folders you get back. An agent addressed by its uuid is reachable whichever environment it is in, and new agents are always created in Development regardless of the header. The SDKs take it as an option - see SDKs.