# 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-Org Tenancy
Organizations are the isolation boundary for data, configuration, and access control. When you need separation between regions, cohorts, or business lines, you create separate organizations.
Common reasons to use multiple organizations
* **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 org
* **Governance**: Independent roles, audit trails, and promotion controls per org
A typical setup for a multi-region deployment:
| Organization | 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 org has its own services, tools, version sets, and access controls. Changes roll out per org, so you can deploy to staging, validate, and promote to production without affecting other orgs.
## 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 constraints**: Voice channels limit state count and disallow certain state types for latency reasons.
* **Validation rules**: The system blocks deployment of incompatible configurations (e.g., a high-latency LLM on a voice service).
| Channel Type | Latency Profile | Key Constraints |
| ------------------------------ | --------------------------- | ------------------------------------------------------------- |
| Voice (phone, WebRTC) | Ultra-low latency required | Max 5 states, no dynamic behaviors, voice-optimized LLMs only |
| 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. If a voice service references a context graph with 12 states, the system flags it before the configuration reaches production.
