Workspaces

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 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

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

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. 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. 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.

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