# Workspaces 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 agent configurations, and its own safety policies. Data does not cross workspace boundaries. ## Tenant Isolation {% @mermaid/diagram content="flowchart TB subgraph WA\["Workspace A"] WMA\[World Model] --- SA\[Services] SA --- PA\[Phone Numbers] PA --- DA\[Data Sources] end subgraph WB\["Workspace B"] WMB\[World Model] --- SB\[Services] SB --- PB\[Phone Numbers] PB --- DB\[Data Sources] end WA \~\~\~ WB style WA fill:#f5f5f5,stroke:#083241 style WB fill:#f5f5f5,stroke:#083241" %} 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 ### Database-Level Isolation Workspace isolation is enforced at the database layer, not just the application layer. Every data query is automatically scoped to the current workspace before it executes - there is no code path that can read or write data across workspace boundaries, even in the event of an application-level bug. This is a fail-closed design: if the workspace context is missing from a request, the query returns zero rows rather than defaulting to unscoped access. This applies to all data tables - events, entities, entity relationships, data sources, sessions, calls, surfaces, and configuration. The database-level enforcement provides defense-in-depth for healthcare deployments where data isolation is a compliance requirement. Application-level access controls (API keys, role-based permissions) remain the primary access mechanism, but the database layer acts as an independent safety net that cannot be bypassed by application code. 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. | | **Operator** | View access plus operator actions: join and leave calls, switch modes, send guidance, and claim and review items in the review queue. | | **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 {% hint style="warning" %} Never test agent behavior changes directly in a production workspace. Use staging workspaces to validate changes before promoting them to production. {% endhint %} Most organizations use multiple workspaces to separate environments: | Environment | Purpose | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Production** | Live calls, real patient data, connected to production EHR. Enforces strict HIPAA-compliant idle session timeouts and enhanced audit retention. | | **Staging** | Pre-production testing with production-like configuration. Relaxed session timeouts reduce friction during development workflows. | | **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. Workspaces can be converted between staging and production through the API or the Developer Console. Before conversion, the platform returns compliance warnings describing what will change - converting to production activates stricter idle timeouts and HITRUST compliance controls; converting to staging relaxes them. The typical path is build in staging, then promote to production when the agent is ready for live patient interactions. ## 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** - External system connections (EHR, FHIR store, CRM) 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 * **Security settings** - Optional workspace-level security controls including voice biometric authentication ### Voice Biometric Authentication Workspaces can enable voice biometric authentication as an additional security layer for console access. The feature requires two gates: the console deployment must have voice auth enabled at the environment level (disabled by default), and the workspace security setting `voice_auth_enabled` must be turned on. When both are active, users complete a voice verification step after login - the platform compares a spoken passphrase against the user's enrolled voiceprint to confirm their identity. The enrollment flow captures a short voice sample to generate a voiceprint stored as a biometric event on the user's person entity in the [world model](/data/world-model.md). On subsequent logins, the user reads a randomized passphrase and the platform verifies the speaker's identity against the enrolled voiceprint. The verification threshold is configurable per workspace to balance security against usability. Voice biometric authentication is best-effort - if the voice pipeline is unavailable or the user's microphone is inaccessible, the system gracefully skips to standard authenticated access. This ensures that the additional security layer never blocks legitimate users from their workspace. {% hint style="info" %} **Developer Guide** - For API endpoints, SDK examples, and integration details, see the [Workspaces](https://docs.amigo.ai/developer-guide/platform-api/platform-api/workspaces) in the developer guide. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.amigo.ai/data/workspaces.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.