> For the complete documentation index, see [llms.txt](https://docs.amigo.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amigo.ai/platform-overview/deployment-model.md).
# Deployment Model
Teams can use a phased operating model: establish a baseline, form improvement hypotheses, validate candidates, and scale only after an explicit release decision. These phases are a recommended workflow, not an automated promotion system.
## Phased Rollout
### Phase 1: Match
The first goal is a bounded comparison, not a claim of immediate improvement or parity. Select the workflows, escalation paths, evidence, and outcome measures that will define the baseline.
During this phase:
* Context graphs encode the approved workflow and operating boundaries.
* Metrics compare eligible agent evidence with the chosen baseline, using the same definitions and filters.
* Operators cover the authored escalation paths and unavailable-agent fallback.
* Retained runs, traces, evaluations, and review evidence inform the next phase when those artifacts are available.
### Phase 2: Discover
With a baseline established, teams analyze observed evidence to form hypotheses about which changes may improve outcomes. Correlation in metrics or traces is not proof that a configuration variable caused the result.
Questions discovery can investigate:
* 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
Candidate changes should be exercised through representative simulations, targeted integration tests, and isolated operational validation before production. Teams define the required case count, comparison method, risk checks, and release criteria for the use case.
The prove phase uses:
* Candidate and control version sets with explicit configuration snapshots.
* Simulation suites that exercise common paths, edge cases, and regressions.
* Metric comparisons that preserve filters, sample sizes, missing evidence, and uncertainty.
* Human review for safety-sensitive or clinically consequential behavior.
Simulation evidence supports a release decision; it does not certify safety or reproduce production deterministically.
### Phase 4: Scale
After an authorized reviewer approves a candidate, teams can copy its version-set configuration to `release`. Continue monitoring production evidence and keep a tested rollback configuration; promotion does not prove that future behavior will remain unchanged.
## Version Sets
Version sets are named service configurations that select agent and Context Graph versions, model preferences, and a supported non-voice turn runtime. They provide reviewable snapshots for testing and release management.
Every Platform service must contain a `release` version set. When service creation omits version sets, the API creates an unpinned `release` set. Other names such as `personal-dev`, `test`, or `preview` are customer conventions, not additional automatic environments.
### Promotion Flow
The standard path from development to production:
1. **Personal candidate** - Create a named version set, pin the intended agent and Context Graph versions, and inspect the resolved configuration.
2. **Targeted test** - Run the suites and integration checks relevant to the change.
3. **Shared candidate** - Optionally copy the configuration to a team-named set such as `preview` for broader review.
4. **Release** - After approval, copy the reviewed candidate configuration to `release` and verify the stored result.
A version set can pin exact agent and Context Graph versions and carry model preferences. A pinned component changes only when its stored version number changes. An unpinned component resolves to the latest available version when configuration is loaded, so publishing a new version can affect later sessions without a separate pin update. Pin `release` when production behavior should change only through a reviewed configuration update.
## Applying Version-Set Changes
The Platform API upserts individual named version sets on a service. Agent Forge can compare sets, copy a source set to a target, and back up the previous `release` configuration during its promote workflow unless that backup is explicitly disabled.
Treat a version-set update as a change to subsequent configuration resolution, not as an in-place migration of every active interaction. A live session or durable conversation actor can retain configuration loaded earlier. Validate the new `release` value, monitor new runs, and keep a rollback path rather than assuming every next message immediately uses the update.
Use retained configuration versions, Forge diffs, simulation evidence, and applicable audit records together when reviewing a release. No single artifact proves that the candidate produced the intended runtime outcome.
## 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.
## Service Channel and Environment
Platform services expose a typed `channel_type`, a typed `environment`, and optional key-value tags. These fields have different purposes:
| Field | Current Contract |
| -------------- | --------------------------------------------------------------------------------------------------- |
| `channel_type` | `voice` or `text`; selects the service's primary channel behavior. |
| `environment` | `sandbox` or `production`; selects the service environment used by supported runtime configuration. |
| `tags` | Optional key-value metadata for customer organization and discovery. |
Do not treat arbitrary tags as proof of model selection, Context Graph validation, or a deployment gate. Validate the selected runtime, version-set model preferences, channel provisioning, tool exposure, and integration behavior for the service you release.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.amigo.ai/platform-overview/deployment-model.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.