Workspaces and Tenant Isolation

Tenant isolation boundaries with separate world models, data sources, voice configs, and role-based access control.

A workspace is the tenant isolation boundary in the Amigo platform. Each workspace has its own world model, its own set of connected data sources, its own voice agent configurations, and its own safety policies. Data does not cross workspace boundaries.

Tenant Isolation

Every workspace maps to an isolated backend organization. This means:

• Events in one workspace are invisible to another

• Entity projections are computed per-workspace

• Phone numbers, services, and context graphs are scoped to a workspace

• API keys authenticate to a specific workspace

For healthcare organizations, this isolation model supports multi-site deployments where each clinic, department, or practice operates as its own workspace with its own data and configuration. A hospital system with five clinics can run five workspaces, each with its own EHR connector, phone numbers, and scheduling logic.

API Keys and Permissions

API access is scoped to an account within a workspace. Each account has a role that determines what it can do:

Role	Capabilities
Owner	Full access. Can manage accounts, billing, workspace settings, and all resources.
Admin	Can manage services, data sources, safety policies, and operational settings. Cannot manage billing or delete the workspace.
Member	Can create and manage conversations, view data, and use the API for day-to-day operations.
Viewer	Read-only access. Can view configurations, data, and call records but cannot modify anything.

API keys inherit the permissions of the account that created them. A key created by a member account cannot perform admin operations.

Environment Separation

Never test agent behavior changes directly in a production workspace. Use staging workspaces to validate changes before promoting them to production.

Most organizations use multiple workspaces to separate environments:

Environment	Purpose
Production	Live calls, real patient data, connected to production EHR
Staging	Pre-production testing with production-like configuration. Used for validating changes before they reach live calls.
Development	Building and testing new context graphs, actions, and integrations. May use synthetic data or a sandbox EHR instance.

This separation ensures that changes to agent behavior, safety rules, or data integrations can be tested in staging before they affect real patient interactions in production.

What Lives in a Workspace

A workspace contains all the resources needed to run a deployment:

• Services - Define which context graph and agent configuration handle calls

• Phone numbers - Routed to services within the workspace

• Data sources - EHR connections and connector runner configurations

• World model - The event store and entity projections for this workspace

• Safety policies - Monitor concepts, regulation templates, and escalation rules

• Voice settings - TTS voice selection, speed, keyterm lists, sensitive topic configuration

• Operator configuration - Which operators can join calls and how escalation works

Developer Guide - For API endpoints, SDK examples, and integration details, see the Workspaces in the developer guide.