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 billing - so a teammate iterating on prompts does not also have to be able to change payment details.
Six roles come with every organization:
| Role | What it can do |
|---|---|
| Owner | Everything, including billing and deleting the organization. |
| Admin | Everything except billing: build and publish agents, manage members and roles. |
| Developer | Build, publish and run agents, and see what an agent is built from. |
| Operator | Run agents and read the member list. Cannot change an agent. |
| Analyst | Read agents and the knowledge base. Changes nothing. |
| Viewer | Read agents. |
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.
The administrative reads are separate and stay with Owner and Admin: the member list, the audit trail, API keys and API request logs.
You can also define your own roles from the same permission set when none of the six is the shape you want.
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 separate what you are building from what your callers are already using.
The flow is one direction:
- 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.
- Callers reach the agent that is in the environment your phone number or web call points at.
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.
An agent is never created straight into Production, and promoting is deliberate, so an edit cannot reach your callers by accident.
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 or an environment uuid:
curl https://api.glytos.com/api/v1/workflows \
-H "Authorization: Bearer $GLYTOS_API_KEY" \
-H "X-Environment-Id: prod"The SDKs take it as an option - see SDKs. New agents are always created in Development regardless; the header scopes what you read and which environment a call runs in.