# Deployment Model
Amigo deployments follow a phased approach: match existing performance first, then discover what drives outcomes, then prove improvements before scaling. This page covers the deployment phases and the infrastructure that supports them.
## Phased Rollout
### Phase 1: Match
The first goal is replication, not improvement. We deploy agents that handle the same workflows your existing staff handles, at the same quality level. This builds trust and establishes baselines.
During this phase:
* Context graphs mirror your current call scripts and protocols
* Metrics track parity with human agent performance (handle time, resolution rate, patient satisfaction)
* Operators handle all escalations while the system learns edge cases
* Every interaction generates structured data for the next phase
### Phase 2: Discover
With baselines established and data flowing, the system identifies which variables actually drive outcomes. This is quantitative, not intuitive.
Examples of what discovery surfaces:
* Which greeting styles lead to higher completion rates
* Which scheduling flows reduce no-show rates
* Which escalation triggers catch real problems vs. create unnecessary transfers
* Which caller emotional patterns predict abandonment
### Phase 3: Prove
Discovered improvements are validated through simulation before they reach production. Changes run against thousands of synthetic conversations, and results must clear statistical thresholds before promotion.
The prove phase uses:
* A/B testing through version sets (a control version and a candidate version running in parallel)
* Simulation suites that exercise edge cases and regression scenarios
* Metric comparisons with confidence intervals, not just averages
### Phase 4: Scale
Proven improvements promote to production through the version set pipeline. Monitoring continues to detect drift and regression.
## Version Sets
Version sets control which configuration a service uses in production. They work like Git branches for your agent setup: you iterate on a development branch, test on a staging branch, and promote to release when validated.
Every service has two permanent version sets:
* **edge**: Always points to the latest versions. Locked from manual updates. Used for smoke testing.
* **release**: The default version set for production traffic. Updated only through deliberate promotion.
### Promotion Flow
The standard path from development to production:
1. **Personal branch** - Create a named version set (e.g., `personal-yourname`), pin specific agent and context graph versions, iterate locally
2. **Test** - Copy your configuration to the shared `test` version set, run targeted simulation suites, fix regressions
3. **Preview** - Promote to `preview`, run the full simulation suite, conduct stakeholder review
4. **Release** - If preview passes, promote to `release` by updating it to match the preview configuration
Each version set pins exact versions of the agent, context graph, and LLM preferences. No implicit "latest" in production.
## Multi-Workspace Tenancy
Workspaces are the isolation boundary for data, configuration, and access control. When you need separation between regions, cohorts, or business lines, you create separate workspaces.
Common reasons to use multiple workspaces
* **Data residency**: Keep patient data in the required geographic region
* **Cohort isolation**: Separate patient populations (e.g., different clinical programs)
* **Blast radius**: Limit the impact of configuration changes to a single workspace
* **Governance**: Independent roles, audit trails, and promotion controls per workspace
A typical setup for a multi-region deployment:
| Workspace | Region | Purpose |
| ---------------------------- | ---------- | ------------------------------- |
| `acme-cardio-useast` | US East | Cardiology program, US patients |
| `acme-cardio-eucentral` | EU Central | Cardiology program, EU patients |
| `acme-cardio-useast-staging` | US East | Staging environment for US |
Each workspace has its own services, tools, version sets, and access controls. Changes roll out per workspace, so you can deploy to staging, validate, and promote to production without affecting other workspaces.
## Channel Tagging
Services are tagged with the channels they serve (phone, web chat, SMS, email) and a deployment tier (voice, text, async).
What channel tags control
* **LLM selection**: Voice channels require low-latency models. A model that works well for text chat may be too slow for real-time voice.
* **Context graph validation**: Voice channels enforce tighter constraints on context graph complexity for latency reasons.
* **Deployment gates**: The system blocks deployment of incompatible configurations (e.g., a high-latency model on a voice service).
| Channel Type | Latency Profile | Behavior |
| ------------------------------ | --------------------------- | ---------------------------------------------------------------------- |
| Voice (phone, WebRTC) | Ultra-low latency required | Optimized context graphs, voice-tuned models, real-time audio pipeline |
| Text (web chat, SMS, WhatsApp) | Moderate latency acceptable | Full feature set, all state types |
| Async (email, API) | Relaxed latency | Full feature set, maximum reasoning depth |
Channel tags are set on the service configuration and enforced at deployment time.
---
# 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/platform-overview/deployment-model.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.