Deployment Model

Phased rollout from baseline parity to proven improvement, plus version sets, multi-org tenancy, and channel tagging.

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.