Deployment Model

A phased operating model for baseline definition, candidate validation, version-set release control, and workspace isolation.

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.