For the complete documentation index, see llms.txt. This page is also available as Markdown.

Archive: v0.6.0 - v0.9.99

Archived Amigo API release notes covering v0.6.0 - v0.9.99. For current releases, see the main Amigo API changelog.

Archived release history for the Amigo API. For current releases, see the Amigo API changelog.

v0.9.99 - Verbatim Rubrics for Standard Quality Metrics (May 2026)

Verbatim Rubrics for LLM Judge Prompts

All 11 standard quality metrics (patient sentiment, conversational naturalness, conciseness, information accuracy, safety, and the six outcome metrics) now use the full verbatim rubric text from the authored specification instead of paraphrased summaries. This affects the ai_query_prompt field on builtin metric definitions.

The previous prompts condensed multi-paragraph rubrics into short narrative summaries, which stripped specific scoring anchors and signal definitions the LLM judge needs to score consistently. The updated prompts include the complete scoring bands, per-band anchor phrases, and severity definitions exactly as authored.

For the voice judge, the 10 dimension rubric blocks now include the full signal-to-severity mapping tables from the voice quality spec. Each dimension lists the specific signals to match against and the severity to assign, replacing the previous narrative descriptions. Severity labels are uppercase (CRITICAL, FLAG, WARNING) so the judge can anchor its output to them. A new scoring rule prevents the judge from upgrading or downgrading severity relative to what the spec assigns to each signal.

Increased Prompt Length Limit

The ai_query_prompt field on metric definitions now accepts up to 8,000 characters (previously 2,000). The higher limit accommodates full verbatim rubrics for standard quality judges.

Breaking change: None. The ai_query_prompt max length increase is backward-compatible. Existing custom metrics are unaffected. Standard metric prompt content has changed but standard metrics are platform-managed and not user-editable.

v0.9.98 - Simulation Bridge: Context Graph Versioning and Raised Limits (May 2026)

Context Graph Version Resolution

The simulation bridge endpoint now resolves the active context graph version instead of reading from the top-level context graph stub. Previously, the bridge prompt could reference stale states, tools, and behaviors that no longer matched what the voice agent actually runs. The bridge now reads the pinned version from the service's release version set, matching the same resolution path used by the agent engine at runtime.

If no version pin is configured, the bridge falls back to the latest version and logs a warning so operators can detect configuration drift.

Raised Concurrency and Scenario Limits

The simulation bridge now supports higher limits for power users running large-scale test suites:

Parameter
Previous Limit
New Limit

Maximum scenarios per run

20

50

Maximum concurrency

5

20

Maximum concurrent bridge runs per workspace

3

10

The maximum turns per scenario remains at 40. These limits apply to bridge runs initiated through the API or Developer Console. Agent Forge CLI users who call session primitives directly are not affected by these caps.

Updated Generation Model

Scenario generation and caller simulation now use an upgraded model for improved scenario diversity and more realistic caller behavior.

v0.9.97 - Absolute Upload URLs and Environment Configuration (May 2026)

Absolute Upload URLs

Upload links returned by the intake link endpoints now include fully qualified absolute URLs instead of relative paths. Previously, the upload_url field in link responses contained a relative path, requiring callers to construct the full URL themselves. Now the response includes the complete URL ready for sharing.

If the platform environment is not fully configured for upload link generation, the intake link endpoints return a 503 Service Unavailable error with a clear message instead of returning a broken relative URL.

Surface URL Configuration

Surface delivery (SMS and email) now uses a dedicated forms URL configuration, separate from the API base URL. This allows surface URLs and upload URLs to be served from different domains. Error messages for misconfigured delivery have been simplified.

v0.9.95 - Greeting Debounce Window (May 2026)

Post-Greeting Transcript Debounce

Voice sessions now apply a short debounce window after the agent greeting finishes playing, during which late-arriving user transcripts are still discarded. Speech-to-text engines can finalize transcripts for words spoken during the greeting with a delay that extends past the moment the greeting audio ends. Without this window, those stale fragments could reach the agent and contaminate the first real conversational turn.

The debounce applies to all transcript processing paths including barge-in detection, end-of-turn handling, and pre-fetch. No configuration is required - the protection is automatic for all voice sessions.

Behavioral effect:

  • Callers who speak over the greeting no longer have their words echoed back or acted on after the greeting completes

  • The first real agent turn starts cleanly, without leftover speech fragments from the greeting period

  • Barge-in remains suppressed through the debounce window, consistent with greeting protection behavior

v0.9.94 - Patient Update: Gender, Language, and Structured Address (May 2026)

Expanded Patient Update Fields

The patient_update world tool now accepts additional demographic and address fields, giving agents the ability to update more patient information during a conversation without requiring a separate EHR workflow.

New fields:

Field
Description

gender

Patient gender (male, female, other, or unknown)

language

Preferred language (e.g. English, Spanish)

address_line_1

Street address line

city

City

state

State name

postal_code

Postal code

Structured Address Support

Addresses can now be provided as individual components (address_line_1, city, state, postal_code) instead of a single free-text string. Structured fields take precedence over the free-text address field when both are provided. Existing address data is preserved when unrelated fields are updated, so a phone number change no longer clears a previously stored address.

Gender and Language Carry-Forward

When gender or language is not provided in an update, the existing value is carried forward from the current patient record. This prevents unrelated updates from clearing demographic data.

v0.9.93 - Dashboard Filter Binding and Per-Panel Row Limits (May 2026)

Dashboard Filter Binding

The dashboard execute endpoint now binds filter values as named SQL parameters to panel queries. Filters declared in the dashboard definition are matched against filter_values supplied in the execute request. If a filter value is provided, it is bound; if not, the filter's default value is used. Unknown keys in filter_values are silently ignored, so clients can safely pass stale keys after a dashboard definition changes.

Filter IDs are validated on create and update: IDs must start with a lowercase letter, contain only lowercase letters, digits, and underscores, and be at most 64 characters. The reserved identifier ws_id cannot be used as a filter ID.

Per-Panel Row Limits

Panels can now declare a max_rows field that overrides the system default row limit for that panel's query. This allows data-heavy panels (tables, exports) to request more rows while keeping chart panels lightweight.

Validation

Creating or updating a dashboard with invalid or reserved filter IDs now returns 422 Unprocessable Entity with a descriptive error message.

v0.9.90 - Standard Quality Metrics: 11 Builtin LLM-Judge Metrics (May 2026)

Standard Quality Metrics

The platform now ships 11 builtin quality metrics that evaluate every AI agent conversation using LLM-based judgment. These metrics run automatically on a daily schedule against call transcript summaries and require no configuration.

5 universal metrics apply to every service:

Metric
Type
What It Measures

Patient Sentiment

Categorical

How the patient felt about the interaction with the agent (positive, neutral, negative)

Conversational Naturalness

Numerical (1-10)

Whether the agent sounds like a person or a scripted system

Conciseness

Numerical (1-10)

Whether the agent kept responses appropriately brief

Information Accuracy

Boolean

Whether the agent accurately relayed information from tool calls

Safety

Categorical

Whether a safety concern arose and how it was handled (no_event, handled, warning, critical)

6 product-type outcome metrics compute only for services tagged with the matching product type:

Metric
Product Type
Categories

Outcome: Scheduling

scheduling

escalated, resolved, no_action

Outcome: Outbound

outbound

escalated, resolved, opted_out, no_action, no_answer

Outcome: Coaching

coaching

escalated, resolved, no_action

Outcome: Intake

intake

escalated, resolved, no_action

Outcome: Triage

triage

escalated, resolved, no_action

Outcome: Support

support

escalated, resolved, no_action

Product-type filtering uses service tags. Services tagged with a matching product type have the corresponding outcome metric computed for their calls. Services without a matching tag are excluded from that outcome metric. Universal metrics apply to all services regardless of tags.

Metric Model Update

The metric definition model adds a new field:

Field
Type
Description

applies_to_product_types

array of string or null

Product types this metric applies to. When set, the metric only computes for calls on services tagged with one of these types. When null, the metric applies to every service.

All 11 standard quality metrics are returned by the metric settings and metric definitions endpoints alongside existing builtin metrics. They appear as builtin: true with extraction_mode: "ai_query" and daily granularity.

Writes and Idempotency

Standard quality metric results are written idempotently. Retries or reruns for the same time window overwrite previous results rather than duplicating rows. Metric values appear in the same metric values endpoints and dashboard views as all other metrics.

v0.9.89 - Phone Number Provisioning: Rest-of-World Support and Number Types (May 2026)

Phone Number Types

Phone number search and provisioning now support three number types: local, mobile, and toll-free. The number_type parameter is required on both the available-number search and the provisioning request. The area code filter is now validated to only apply to local numbers (returns 422 for other types).

The phone number response now includes a number_type field so you can see the type without additional lookups.

Rest-of-World Regulatory Bundle Discovery

Provisioning is no longer limited to US and CA. The country parameter now accepts any ISO 3166-1 alpha-2 country code. Required bundles are resolved dynamically based on the country, number type, and business end-user type:

  • US: SHAKEN/STIR + CNAM bundles required (any number type)

  • CA: CNAM bundle required (any number type)

  • Other countries: regulatory compliance bundles are discovered automatically per country and number type

All required bundles must be approved before a number can be provisioned. The 409 error response now directs callers to inspect the bundle list to see which are missing or not yet approved.

Bundle List Filtering

The bundle list endpoint now supports optional filters:

Parameter
Type
Description

policy_sid

string

Filter by exact policy SID

iso_country + number_type

string pair

Resolve and return only bundles required for that country/number-type combination

policy_sid is mutually exclusive with the country/number-type pair. When no filters are provided, all bundles for the setup are returned.

Migration

  • The country parameter on provisioning and available-number search no longer restricts to US/CA - any valid two-letter country code is accepted

  • number_type is now a required parameter on available-number search and provisioning requests

  • Phone number responses include the new number_type field

v0.9.88 - Voice Judge: Audio-Native Quality Evaluation (May 2026)

Voice Quality: Audio-Native Per-Call Scoring

The platform now evaluates voice agent call quality directly from audio recordings, scoring each call across 10 dimensions that measure the voice experience independent of conversational logic or prompting. Scores range from 0.0 to 1.0 per dimension, with severity classifications (Critical, Flag, Warning) and quoted evidence from the audio.

The 10 voice quality dimensions:

Dimension
Priority
What It Measures

Latency and Dead Air

P0

Response latency between turns, prolonged silence

Pronunciation

P0

Correct pronunciation of medical terms, drug names, dates, numbers, patient names

Clarity

P0

Speech intelligibility and clean audio

Filler and Silence Management

P1

Graceful handling of processing pauses, appropriate verbal acknowledgments

Interruption Handling

P1

Clean barge-in behavior, smooth recovery after being interrupted

Audio Consistency

P1

Absence of volume spikes, pitch anomalies, or mid-word cutoffs

Pacing

P2

Conversational speech rate with appropriate pauses

Warmth and Tone

P2

Emotional appropriateness matched to patient state

Accent and Language Quality

P2

Language match and accent naturalness

Voice Identity

P2

Consistent agent voice and persona across the call

Each dimension includes an evidence quote describing exactly what was heard and when, so results are auditable rather than opaque scores.

Scoring runs as a scheduled batch job. Results are available per-service through a new API endpoint.

Platform API: Voice Judge Results Endpoint

New endpoint for retrieving per-call voice quality scores for a service:

Method
Path
Description

GET

/v1/{workspace_id}/services/{service_id}/voice-judge/recent

Recent voice-judge results (newest first)

Query parameters:

Parameter
Type
Default
Description

limit

integer

20

Max rows to return (1-100)

The response includes per-dimension scores, an overall composite score, severity counts, and the raw judge output with evidence quotes for UI drill-in.

Returns 503 if the analytics warehouse is unavailable, distinguishing infrastructure failures from "no evaluations yet" (which returns 200 with an empty list).

Metrics: 10 Voice Quality Metrics

Ten new builtin metrics aggregate per-call voice quality scores into per-workspace per-period averages:

  • voice_judge_latency_dead_air

  • voice_judge_pronunciation

  • voice_judge_clarity

  • voice_judge_filler_silence

  • voice_judge_interruption_handling

  • voice_judge_audio_consistency

  • voice_judge_pacing

  • voice_judge_warmth_tone

  • voice_judge_accent_quality

  • voice_judge_voice_identity

All are numerical metrics with daily granularity, unit score, and valid range [0.0, 1.0]. Available through the existing metric store endpoints.

v0.9.87 - Soft Escalation and Empathy Detection Accuracy (May 2026)

Escalation: Soft Escalation Keeps Agent on the Call

When a caller requests to speak with a human in a non-emergency context, the platform now performs a soft escalation instead of immediately suspending the agent. The agent stays on the call, acknowledges the caller's request, and lets them know an operator is being contacted. Operators are notified through the standard escalation flow and can take over when ready.

Previously, all escalations suspended the agent immediately, which could leave the caller in silence while waiting for an operator to join. Soft escalation eliminates that gap - the caller continues to hear the agent until the operator is connected.

Hard escalation behavior is unchanged: crisis-level detections still suspend the agent, but the current sentence now finishes playing before the agent goes silent. This prevents mid-sentence audio cutoffs that could be jarring for the caller.

Emotion Detection: Stricter Empathy Tier 2 Activation

Tier 2 empathy (full empathy mode) now requires agreement between both the categorical emotion model and the dimensional valence model before activating based on a distress emotion label alone. Previously, a distress label from a single model was sufficient to trigger Tier 2, which could cause false activations on calm, low-energy speech - particularly on telephony-quality audio where the categorical model can default to distress classifications.

This change reduces false Tier 2 activations on routine calls. When Tier 2 activates incorrectly, it caps speech speed for the remainder of the call, making the agent sound unnaturally slow. The fix aligns the Tier 2 activation logic with the stricter conjunctive pattern already used for Tier 3.

No API changes. Both changes affect runtime behavior only.

v0.9.86 - Simulation and Playground Entity Visibility (May 2026)

World Model: Entity State Includes Simulation and Playground Events

Entity state projections now include events from simulation and playground sessions. Previously, these events were filtered out along with other non-production sources, which meant that entities created or modified during tool testing, text playground sessions, or simulation runs did not appear in the world model.

With this change, running a tool in the playground or executing a simulation that writes entity data will produce visible entity state - the same data the agent would see during a live conversation. This makes testing workflows more realistic and easier to validate.

Analytical pipelines - metrics, encounter detection, and gap detection - continue to exclude simulation and playground events. Production analytics are not affected.

No API changes. This is a data pipeline behavior change only.

v0.9.84 - Enriched Call Trace Analysis (May 2026)

Call Intelligence: Component Attribution

Post-call analysis now identifies which system component caused each behavioral issue during a call. Every misalignment between caller signals and agent responses is attributed to one of seven components: speech recognition, navigation model, emotion detection, state machine, tool execution, prompt logic, or turn-taking. Each attribution includes the specific issue, structural evidence, and a severity rating (critical, contributing, or minor).

This enables targeted debugging - instead of reviewing an entire call to understand what went wrong, you can see that a specific failure was caused by, for example, incorrect emotion detection or a state machine that failed to advance.

Call Intelligence: Enriched Execution Traces

Structured execution traces forwarded to the analysis pipeline now include richer per-turn data:

Signal
Description

Tool summaries

Structural shape of each tool call: name, input key names, output length, success/failure, duration

Reasoning step count

Number of internal reasoning steps the agent took per turn

Emotion label and valence

Detected caller emotion and emotional direction per turn

Latency breakdown

Navigation and engine timing per turn

STT confidence

Speech recognition reliability score per turn

All data is structural and categorical only. No patient names, dates of birth, medical record numbers, or raw tool input/output values are included in the analysis pipeline.

Call Intelligence: PHI-Safe Tool Reporting

Tool call reporting in execution traces has been redesigned around data minimization. Instead of forwarding raw tool inputs and outputs (which may contain patient information), traces now report only the structural shape: tool name, sorted input key names, output character length, success/failure flag, and execution duration. This eliminates the PHI surface area entirely rather than relying on redaction.

v0.9.83 - Judge Mode Metrics and Catalog Cleanup (May 2026)

Platform API: Judge Mode for Custom Metrics

Custom metric definitions now support judge mode - LLM-based evaluation of individual interactions using a rubric prompt you define. This lets you create metrics that score each call, encounter, or session against criteria specific to your organization.

New definition fields:

Field
Type
Description

prompt

string

Rubric prompt for LLM judge evaluation. Use {$.path} references to inject entity context data. Max 4000 characters.

granularity

string

aggregate (one value per time period, default) or per_entity (one value per interaction)

Validation rules for judge mode:

  • Metrics with a prompt must use ai_query extraction mode

  • Metrics with per_entity granularity require a prompt

  • The prompt must contain at least one {$.path} context variable

  • Maximum 50 custom metric definitions per workspace

Example: A "clinical accuracy" judge metric could evaluate each call transcript against a rubric that checks whether the agent correctly verified allergies, confirmed medication dosages, and followed escalation protocols.

Platform API: Metric Catalog Response Changes

The GET /v1/metrics/catalog response schema has been updated:

Added fields:

Field
Type
Description

granularity

string

aggregate or per_entity

has_prompt

boolean

Whether the metric uses LLM judge evaluation

Removed fields:

Field
Notes

source

No longer included in catalog entries

channel_scope

No longer included in catalog entries

period_granularity

Replaced by granularity

Platform API: Freshness Endpoint Removed

The GET /v1/metrics/freshness endpoint has been removed.

v0.9.82 - Address-Aware Phone Number Provisioning (May 2026)

Platform API: Address Requirements on Phone Provisioning

Phone number search and provisioning now honor address requirements reported by the telephony provider, expanding the pool of numbers available for purchase.

Search filtering:

Available phone number search results are now filtered based on address compatibility rather than excluding all numbers with any address requirement:

  • Searching in the same country as the setup's business address excludes numbers requiring a foreign address.

  • Searching in a different country excludes numbers requiring a local (in-country) address.

  • Numbers with no address requirement or flexible requirements are always included.

Previously, all numbers with any address requirement were excluded from search results.

Provisioning validation:

Phone number provisioning now validates address requirements before purchase and automatically attaches the setup's business address when required:

Address Requirement
Behavior

none

No address needed - number is purchased directly

any

Setup's business address is attached to the purchase

local

Setup's business address is attached. Returns 422 if the business address country does not match the number's country.

foreign

Setup's business address is attached. Returns 422 if the business address country matches the number's country.

New error responses:

Status
Condition

409

Number is no longer available at purchase time

422

Number's address requirement is incompatible with the setup's business address country

v0.9.81 - Country-Conditional Phone Number Bundles (May 2026)

Platform API: Country-Conditional Regulatory Bundles

Phone number provisioning now enforces country-specific regulatory bundle requirements. Instead of requiring all three Trust Hub verification steps (customer profile, SHAKEN/STIR, CNAM) upfront, the setup flow separates the customer profile from regulatory bundles, and each country specifies which bundles are required before provisioning.

New endpoints:

Endpoint
Method
Description

/v1/twilio-setup/{id}/bundle/shaken-stir

POST

Submit SHAKEN/STIR bundle (required for US numbers)

/v1/twilio-setup/{id}/bundle/cnam

POST

Submit or update CNAM bundle (required for US + CA numbers)

/v1/twilio-setup/{id}/bundle

GET

List all bundles for a setup with status and failure details

Country requirements:

Country
Required Bundles

US

SHAKEN/STIR + CNAM

CA

CNAM only

What changed:

  • Setup creation no longer requires cnam_display_name - CNAM is now submitted as a separate bundle after customer profile approval.

  • Bundles are submitted individually - SHAKEN/STIR and CNAM are created via dedicated POST endpoints rather than being auto-advanced after customer profile approval.

  • Phone number provisioning gates on country-specific bundles - A US number requires both SHAKEN/STIR and CNAM approved; a CA number requires only CNAM.

  • Bundle status includes failure details - Each bundle carries human-readable failure strings from the latest rejection or noncompliant evaluation.

  • Pre-flight evaluations return actionable errors - Bundle submission endpoints return 422 with structured failure details when Twilio's evaluation fails, so you can fix issues before waiting for async review.

  • CNAM display name is updatable - POST to the CNAM bundle endpoint with a changed display_name updates the underlying data. Returns 409 if unchanged or if the bundle is under active review.

  • Use case creation gating simplified - Only requires customer profile approval, not all bundles.

  • Phone number search gating simplified - Only requires customer profile approval.

  • Country parameter restricted - Phone number search and provisioning now accept only US or CA.

Removed endpoints:

Endpoint
Replacement

PATCH /v1/twilio-setup/{id}/cnam

POST /v1/twilio-setup/{id}/bundle/cnam

POST /v1/twilio-setup/{id}/retry

Submit individual bundles via POST /bundle/{kind}

GET /v1/twilio-setup/{id}/event

GET /v1/twilio-setup/{id}/bundle for per-bundle status

Removed response fields:

  • Setup response no longer includes shaken_stir, cnam, cnam_display_name, ready, or last_error. Customer profile status is returned directly; bundle status is available via the bundles list endpoint.

  • Phone number response no longer includes shaken_stir_assignment_sid or cnam_assignment_sid.

Updated setup response:

  • customer_profile now includes last_failure (array of strings or null) for webhook rejection details.

v0.9.80 - Dashboard Embed BFF Proxy Auth (May 2026)

Platform API: Dashboard Embed BFF Proxy Auth

The DashboardEmbed component now supports cookie-based authentication through a backend-for-frontend (BFF) proxy. The apiToken prop is now optional - when omitted, the component uses same-origin credentials instead of a Bearer token.

This is useful when your application proxies dashboard API requests through its own backend, using session cookies or other server-side authentication rather than passing API tokens to the browser.

What changed:

  • apiToken is now optional - Previously required. When omitted, the component sends requests with same-origin credentials and no Authorization header, allowing a BFF proxy to handle authentication server-side.

  • Cookie-based auth support - Requests now include same-origin credentials, enabling session cookie authentication through a proxy.

  • No breaking changes - Existing integrations that pass apiToken continue to work exactly as before.

v0.9.79 - Dashboard Workspace Scoping and Slug Uniqueness (May 2026)

Platform API: Dashboard Workspace Scoping

Dashboard panel queries now require a :ws_id parameter binding to enforce workspace-level data isolation. This prevents panels from accidentally querying data across workspaces.

What changed:

  • Write-time validation - Creating or updating a dashboard with panel queries that do not reference :ws_id now returns 422 Unprocessable Entity with a message identifying the offending panel. Previously, these queries were accepted and could return unscoped data at execution time.

  • Execute-time enforcement - When executing a dashboard, any panel query missing the :ws_id binding returns an error result for that panel instead of running the query. Other panels in the same dashboard still execute normally.

  • Concurrent panel execution - Panel queries now execute concurrently with bounded parallelism, improving dashboard load times when multiple panels are present.

Platform API: Dashboard Slug Uniqueness

Dashboard slugs are now enforced as unique within a workspace. Attempting to create or update a dashboard with a slug that is already in use by another active dashboard in the same workspace returns 409 Conflict.

Previously, duplicate slugs could cause lookup failures when dashboards were retrieved by slug. Soft-deleted dashboards do not participate in the uniqueness constraint.

What changed:

  • Create - Returns 409 Conflict if the slug is already taken in the workspace.

  • Update - Returns 409 Conflict if the new slug collides with another active dashboard in the workspace.

v0.9.77 - Custom Phrase Escape Hatch and Adaptive Filler Timing (April 30, 2026)

Platform API: Custom Phrase for Progress Hints

Progress hints on tool call specs now support an optional custom_phrase field - an operator-authored filler utterance spoken while a slow tool executes. This is a narrow escape hatch for demo-critical tools where the standard generated fillers do not adequately cover the wait.

The field is gated to prevent misuse:

  • Minimum latency - expected_latency_ms must be 4000 or higher. Custom phrasing is reserved for tools with demonstrably long waits.

  • Class required - progress_class must be set. The class acts as the fallback when the custom phrase cannot be used (for example, when hints from multiple tools are merged).

  • Word limit - The phrase must be 30 words or fewer to keep fillers concise.

When all gates are satisfied, the custom phrase is spoken on the first filler tick. Subsequent ticks fall back to the standard class-based templates. When progress hints from multiple concurrent tools are merged, custom phrases are dropped because they are tool-specific and cannot be meaningfully combined.

What changed:

  • custom_phrase field - New optional string field on the progress hint object. Maximum 500 characters, at most 30 words. Validated on submission; requests that fail the gate conditions receive descriptive error messages.

  • Merge behavior - When the platform merges progress hints across concurrent tools, custom phrases are excluded from the merged result. The merged hint uses the standard progress class templates.

Platform API: Adaptive Filler Timing

The voice agent now adapts when the first filler utterance fires based on the tool's declared expected latency. For tools that declare an expected wait, the first filler fires earlier in proportion to the expected duration, so callers hear acknowledgment sooner during moderate waits (4-9 seconds) rather than waiting for the default delay. Tools without a declared latency keep the existing timing.

What changed:

  • Earlier first filler - Tools with a declared expected_latency_ms trigger their first filler utterance earlier, scaled to the expected wait. This prevents the scenario where a tool finishes before the caller hears any acknowledgment.

  • No change for unconfigured tools - Tools without expected_latency_ms retain the existing default filler timing.

v0.9.76 - World Model FHIR Name Preservation (April 29, 2026)

Platform API: FHIR Name Data Preserved in World Events

World model events now preserve structured FHIR name data (the HumanName format used by EHR systems) in their full original shape. Previously, the structured name could be dropped during event processing, which meant downstream queries that accessed name components - given name, family name, prefixes, suffixes - would return empty results.

The platform still extracts a flat display name for quick lookups. When a display name is not explicitly provided, the platform derives one from the structured name by combining the first given name and family name. FHIR HumanName lists, plain string names, and explicit display names are all handled correctly.

What changed:

  • Structured name retention - FHIR HumanName arrays are no longer removed from event data during processing. Queries that read name components (given names, family name, prefixes) from event data now return complete results.

  • Display name derivation - When no explicit display name is set, the platform derives one from the first entry in a FHIR HumanName list or from a plain string name. This ensures display name is populated consistently regardless of the source data format.

v0.9.74 - Per-Workspace Audit Log Isolation (April 25, 2026)

Platform API: Audit Log Workspace Scoping

Audit log entries are now scoped to individual workspaces. Previously, certain auto-provisioning events were logged once without a workspace association. Now each workspace receives its own audit entry, so workspace-level audit queries return complete results without cross-workspace leakage.

What changed:

  • Per-workspace audit entries - Operations that span multiple workspaces (such as user auto-provisioning) now emit a separate audit entry for each workspace involved. Each entry includes the workspace identifier and the user's role in that workspace.

  • Read-only isolation - Audit log access is restricted to read-only queries scoped to the caller's workspace. Services cannot modify or delete audit records, and queries only return entries belonging to the requesting workspace.

  • Service role groups - Service credentials are now assigned to role groups rather than referenced individually in access policies. Rotating a service credential no longer requires policy changes - the new credential is granted membership in the same role group.

v0.9.73 - Client Credentials OAuth2 & Secret Hashing (April 24, 2026)

Platform API: OAuth2 Client Credentials Grant

The identity service now fully supports the OAuth2 client_credentials grant type with secure secret management. Client secrets are hashed with a modern key derivation function (PBKDF2-SHA256, 210,000 iterations) before storage, replacing the previous approach.

What changed:

  • Credential creation - Creating a client_credentials or api_key credential now generates a secret automatically and returns it in the response. The plaintext secret is shown once and cannot be retrieved again. The response includes both the credential metadata and the secret.

  • Secret rotation - Rotating a client_credentials credential secret now uses the same secure hashing. API key rotation continues to work as before.

  • Token exchange - The client_credentials token grant now verifies secrets against the new hash format. Verification runs off the main request thread to avoid blocking on the CPU-intensive hashing operation.

  • Backward compatibility - Credentials created before this change (using the legacy hash format) continue to work. The system detects the hash format automatically and verifies accordingly. No migration is required for existing credentials.

v0.9.70 - Call Completion Reason Normalization & Validation (April 21, 2026)

Platform API: Standardized Call Completion Reasons

The completion_reason field on call intelligence records is now validated and normalized before storage. A canonical set of completion reasons is enforced across all producers (voice agent engine and API), and a database-level constraint prevents unknown values from entering the system.

The full set of valid completion reasons is: completed, abandoned, escalated, transferred, timeout, error, voicemail, no_answer, caller_hangup, forwarded, terminal_state, warm_transfer_completed, no_inbound_audio, cancelled.

New value: cancelled has been added for calls that are explicitly cancelled before completion.

Alias mapping: Legacy or provider-specific reason strings are automatically mapped to canonical values. For example, max_duration and idle_timeout both normalize to timeout. Unrecognized values are coerced to null and logged as warnings rather than causing write failures.

This change is backward-compatible. Existing calls with valid completion reasons are unaffected. Calls with previously stored non-canonical values will not be retroactively modified, but all new writes are validated.

v0.9.68 - Platform Health Monitoring & Entity Narrative Briefs (April 19, 2026)

Platform API: Platform Health Monitoring

Two new observability endpoints give operators real-time visibility into data pipeline health and end-to-end processing latency without querying the analytics warehouse directly.

Connector Health (GET /v1/{workspace_id}/sensorium/connector-health) returns per-source event health for every data source writing into the workspace. Each source entry includes events ingested in the last hour and last 24 hours, mean events per minute, the last ingested timestamp, and a freshness category:

  • fresh - last event less than 5 minutes ago

  • stale - last event 5 to 60 minutes ago

  • quiet - last event more than 60 minutes ago

  • never - no events in the last 24 hours

Loop Latency (GET /v1/{workspace_id}/sensorium/loop-latency) measures the end-to-end time from data ingestion (a world model event landing) to agent action (the agent acting on that data). Returns an overall median latency, total pair count, and an hourly sparkline (up to 168 hours / 7 days) with per-hour pair counts and median latency. The window_hours query parameter controls the lookback window (1-168, default 24).

Both endpoints are workspace-scoped and rate-limited under the standard read policy.

Platform API: Entity Narrative Briefs

New AI-powered narrative brief generation for patient entities. The platform reads the last 90 days of world model events for a patient, synthesizes them into a structured narrative summary with a versioned prompt, and returns both Markdown and structured JSON representations.

  • POST /v1/{workspace_id}/entities/{entity_id}/brief - generates a fresh brief on demand. The brief is persisted as a world model event, cached for fast retrieval, and includes evidence pointers (the event IDs that informed the narrative), a confidence score (0.0-1.0), the event count that went into the brief, and a prompt version identifier for traceability. Returns 404 if the entity is not a patient or does not exist in the workspace.

  • GET /v1/{workspace_id}/entities/{entity_id}/brief - returns the latest cached brief. Cache misses fall through to the event store and repopulate the cache transparently. When no brief has ever been generated, the response returns a consistent empty shape (null event_id and content fields) rather than a 404, so the UI can render a "not yet generated" state without error handling.

Briefs are currently scoped to patient entities. Cohort, territory, and workspace-level briefs are planned for a future release.

v0.9.67 - WhatsApp Voice Notes, Desktop Sessions & Simulation Bridge (April 18, 2026)

Platform API: WhatsApp Voice Note Conversations

The voice agent now handles WhatsApp voice notes as a full conversation channel. Patients send a voice note, the platform transcribes it, runs the same reasoning engine pipeline (context graphs, tools, safety boundaries, world model), synthesizes the agent's spoken reply, and returns it as a voice note in the same WhatsApp thread.

Session continuity is keyed on the patient's phone number - no session ID management required. Switching between text and voice notes in the same thread preserves full conversation context. Concurrent voice notes from the same patient are serialized (409 if a turn is already in progress) to prevent race conditions in the reasoning engine.

The voice turn endpoint accepts any common audio format and returns OGG Opus. Audio payloads are capped at 20 MB with enforcement at both the API gateway and engine tiers.

Platform API: Desktop Session Proxy

New desktop session endpoints let API consumers and the Developer Console drive RDP desktop sessions without direct cloud infrastructure access. The platform proxies session lifecycle operations (create, screenshot, action, status, disconnect) to the desktop sidecar, handling authentication, workspace isolation, and audit logging transparently.

Sessions are workspace-scoped and limited to one active session at a time per sidecar. A distributed lock prevents multi-pod race conditions on session creation. All operations require admin-level permissions and emit PHI-access audit events.

Platform API: Simulation Bridge

New POST /v1/{workspace_id}/simulations/bridge endpoint that turns a natural language test objective into a set of autonomous test scenarios. The platform generates personas with distinct temperaments and conversation strategies from the objective, then runs each scenario end-to-end as an autonomous caller against the configured service.

Each bridge run creates a tracked coverage run with per-scenario sessions, so results are visible through the existing coverage graph and scoring APIs. Runs are capped at 3 concurrent per workspace (429 if exceeded) with a 30-minute overall timeout.

This is the REST API equivalent of forge simulation bridge - same scenario generation and autonomous execution, accessible without the CLI.

Platform API: Phone Number Use Case Management

Phone number provisioning now supports use case management. Each number can be assigned to specific use cases (A2P messaging, outbound voice, etc.), with the platform enforcing capability requirements per use case type. Numbers, use cases, and their assignments are managed through dedicated CRUD endpoints under channel management.

Available number search filters by country, area code (NANP countries only), and required capabilities. The provisioning flow validates that the business profile and trust products are fully approved before allowing number purchases.

Platform API: Trigger Input Override

The manual fire endpoint (POST /v1/{workspace_id}/triggers/{trigger_id}/fire) now accepts an optional JSON body with an input field. Values from the override are merged into the trigger's stored input_template at fire time, so webhook consumers and manual testers can supply dynamic values (phone numbers, entity IDs, custom parameters) without modifying the trigger configuration.

This is the mechanism webhook destinations use to pass extracted payload fields through to the trigger's action.

v0.9.66 - Progress Hints and Expanded EHR Projections (April 17, 2026)

Platform API: Tool-Wait Progress Hints

Agent engineers can now shape how the voice agent narrates tool waits on a per-state and per-tool basis. A new ProgressHint primitive describes the shape of a wait - a semantic progress_class (lookup, write, external_call, compute, multi_step), an expected_latency_ms, and a mode (auto, silent, backchannel, verbal) - instead of the previous per-state filler phrase lists. The engine generates the actual utterance at runtime from the hint plus tool semantics, turn emotion, and conversation context.

  • New field progress (optional ProgressHint) on ToolCallSpec in action_tool_call_specs and exit_condition_tool_call_specs.

  • New field progress (optional ProgressHint) on ChannelOverride (state-level per-channel override).

  • Resolution order: per-tool hint > per-state channel override > engine default, merged field-wise so a tool only overrides the fields that actually differ.

  • Attempt-aware retries: when a tool retries, the engine emits deterministic templated language keyed on progress_class - acknowledgement on attempt 1, brief apology on attempt 2, "still working" on attempt 3 - with no LLM call in the retry latency path.

Platform API: Expanded EHR FHIR Projections

Charm-integrated workspaces now project every Charm entity into a queryable FHIR resource, closing gaps that forced scheduling and eligibility tools to fall back to partial data:

  • Practitioner: members → FHIR Practitioner with NPI, role, licensed states, specialty, and active flag. Resolves previously dead Practitioner/charm-{id} references in Appointment.participant.

  • Location: facilities → FHIR Location with address, timezone, geo position, phone, and hours of operation. Test/sentinel facilities project as status=inactive. Nearest-facility scheduling lookups now return real rows.

  • Coverage: per-patient insurance → FHIR Coverage with subscriber DOB and name, effective/term period, relationship, payer reference, and a deterministic fingerprint for dedup. Unblocks payer eligibility checks.

  • Slot: bookable Slots projected with start, end, status, and a schedule reference. Exposed via a new Slot view endpoint that resolves the provider display name from the Slot's schedule reference, so scheduling surfaces no longer need to join against the raw Schedule resource.

  • Extended Patient: language, marital status, race/ethnicity (US Core extensions), emergency contact, deceased status, and an assigned-facility Location reference.

  • Extended Appointment: appointment mode → serviceType, appointment timezone, member degree, member specialization, resource type, payer extensions, and cancelationReason on cancelled status.

v0.9.65 - Data-MCP Backend URL Override (April 17, 2026)

Data-MCP: Caller-Configurable Backend URL

Data-MCP callers can now choose which backend the MCP server proxies to on a per-request basis, instead of being pinned to the server's default deployment. A new X-Amigo-Api-Url request header specifies the target backend, validated against an allowlist on every request. Calls without the header continue to use the deployment's configured default, so existing integrations keep working unchanged.

The header value must match a host on the server's AMIGO_API_URL_ALLOWLIST. Unknown hosts return 400. The allowlist always includes the deployment's configured default in addition to any hosts the operator explicitly adds, so the default backend never needs to be listed separately.

This unblocks multi-region clients and split-brain test setups that want one Data-MCP server to route queries to the appropriate regional Platform API without running multiple MCP servers. Token caches are now keyed by (organization, key_id, backend_url) so credentials issued for one backend cannot be reused against another by accident.

v0.9.64 - Epidemiology REST Endpoints (April 17, 2026)

Platform API: Epidemiology REST Endpoints

Six new workspace-scoped endpoints under /v1/{workspace_id}/epidemiology/ expose the population-health analytics tables shipped in v0.9.63 directly over HTTP. Same statistical methodology (Wilson CI, Byar CI, Charlson CCI, Pearson χ² / PMI / Jaccard / lift); no SQL or Delta access needed to query them.

  • GET /v1/{workspace_id}/epidemiology/prevalence - active-condition prevalence with Wilson 95% CI. Filter by code, code_system (ICD10, SNOMED, ICD9, OTHER), age_bucket (0-17, 18-34, 35-49, 50-64, 65-79, 80+), gender. Toggle min_support_only=true to hide small-cell cohorts (observed < 5).

  • GET /v1/{workspace_id}/epidemiology/trends - monthly incidence time series for a specific code. Requires code; accepts start_month / end_month in YYYY-MM format plus the same cohort filters.

  • GET /v1/{workspace_id}/epidemiology/cohort-drivers - Standardized Prevalence Ratio (SPR = observed / expected) per (age_bucket, gender) cohort with Byar 95% CI. Requires code. SPR > 1 means the cohort over-indexes for that code. Defaults to min_support_only=true.

  • GET /v1/{workspace_id}/epidemiology/cooccurrence - co-occurring active-condition code pairs with Jaccard, lift, PMI, and Pearson χ². Filter by code to constrain one side of the pair. Sort by lift (default), pmi, chi_square, or jaccard.

  • GET /v1/{workspace_id}/epidemiology/patient-burden - per-patient condition features including Charlson Comorbidity Index (Quan 2005 ICD-10) and age-adjusted CCI (Charlson 1994). Filter by min_charlson, age_min / age_max, or gender. Sort by any numeric feature column (default age_adjusted_charlson_index).

  • GET /v1/{workspace_id}/epidemiology/patient-burden/{patient_entity_id} - full burden row for a single patient plus per-category Charlson flags across all 17 Quan (2005) ICD-10 categories (myocardial infarction, CHF, peripheral vascular, cerebrovascular, dementia, chronic pulmonary, rheumatic, peptic ulcer, mild liver, diabetes +/- complications, hemiplegia, renal, malignancy, moderate/severe liver, metastatic, HIV/AIDS).

All endpoints enforce workspace isolation at the SQL-parameter level and rate-limit under the standard read_rate_limit policy. Server returns 503 when the analytics warehouse is not configured for the deployment, 502 on a downstream query failure, and 404 for an unknown patient on the detail endpoint.

The six analytics tables are also advertised to the Insights Agent's sql_query tool and the Data-MCP server, so agents and MCP clients can compose the epidemiology outputs with any other world-model query in the same call.

v0.9.63 - Epidemiology Analytics & Inbound Webhook URL Canonicalization (April 16, 2026)

Platform API: Epidemiology Analytics Tables

New population-health analytics pipeline producing six layered output tables from the world model's L1 clinical projections. Each table is explainable, cite-able, and suitable for feeding into risk stratification models without a black-box step in between.

  • patient_condition_fact - exploded patient × condition grain with onset date, age at onset, code system normalized to ICD10 / SNOMED / ICD9, and coarse age cohort buckets. The base table every downstream measure joins against.

  • disease_trends_monthly - incident case counts per code per month per cohort. Use for outbreak detection, seasonality curves, and trend charts.

  • disease_prevalence_current - active-condition prevalence with Wilson 95% confidence interval. Small-sample-robust (Wilson 1927, Brown-Cai-DasGupta 2001): the interval stays in [0, 1] even for tiny cohorts.

  • disease_cohort_drivers - Standardized Prevalence Ratio (SPR) per (code, cohort) with Byar 95% confidence interval (Breslow & Day 1987). The canonical epidemiology measure for "does this cohort over- or under-index for this condition?" - an interpretable alternative to feature importance from a black-box model.

  • patient_condition_burden - per-patient Charlson Comorbidity Index using Quan (2005) ICD-10 mappings, plus age-adjusted CCI per Charlson (1994). Feature-ready input for risk stratification; MLflow / AutoML / SQL rules consume it downstream.

  • condition_cooccurrence_pairs - co-occurring code pairs with Jaccard similarity, lift, pointwise mutual information, expected count, and chi-square. Drives correlation-matrix visualizations and comorbidity pattern mining.

All association and ratio measures emit a min_support_met flag at the standard small-cell suppression threshold (observed count ≥ 5); UIs and downstream queries should filter on it to avoid reporting unstable rates. Tables are scoped per workspace and land in analytics_{env}.public.*.

Methodology is published and cited inline: Wilson (1927), Breslow & Day (1987), Charlson et al. (1987, 1994), Quan et al. (2005).

Platform API: Inbound Webhook URL Canonicalization

The inbound webhook receive URL moved from /hooks/{workspace_id}/{destination_id} to /v1/{workspace_id}/hooks/{destination_id} to match the versioned, workspace-scoped path convention used across the rest of Platform API. The URL is server-generated and returned on webhook destination create and get responses, so newly created destinations return the new URL automatically. Integrations that persisted an old URL should re-fetch the destination record and update their external webhook configuration.

v0.9.62 - Per-Key Entity Enrichment (April 16, 2026)

Platform API: Per-Key Entity Enrichment

New first-class API for extending world model entities with custom, source-attributed values. Previously, extra attributes on an entity were collapsed into an opaque blob with no source, confidence, or audit trail. Enrichment values are now per-key events with the same provenance, supersedes chain, and confidence resolution as every other world model event.

Each write validates against a workspace-scoped registry of allowed keys. Admins declare the keys their workspace tracks (entity type, value type, optional enum values, minimum confidence, PII flag) before any source can write them. Unknown keys are rejected at write time; enum violations, wrong value types, and sub-floor confidence values return 400 with a specific message. The same write API handles manual entries, connector backfills, forms, and agent-extracted values, differentiated only by source and confidence.

Reads return the current winner per (entity, key), selected by confidence class (authoritative > human-approved > AI-verified > uncertain) with recency as the tiebreaker. A history endpoint walks the full supersedes chain so any value can be traced back to the source event, timestamp, and confidence that produced it.

New endpoints:

  • PUT /v1/{workspace_id}/world/entities/{entity_id}/enrichment/{key} - write a single value with source, confidence, and optional effective_at. Returns the event ID and ingested timestamp.

  • GET /v1/{workspace_id}/world/entities/{entity_id}/enrichment - list current winners for an entity with full provenance (value, value_type, confidence, source, source_system, effective_at, event_id).

  • GET /v1/{workspace_id}/world/entities/{entity_id}/enrichment/{key}/history - supersedes chain for one key, newest first, with is_current and supersedes pointers.

  • POST /v1/{workspace_id}/world/enrichment-keys - register a key (entity_type, key, value_type, optional allowed_values, min_confidence, is_pii).

  • GET /v1/{workspace_id}/world/enrichment-keys - list registered keys, optionally filtered by entity_type.

  • PATCH /v1/{workspace_id}/world/enrichment-keys/{key_id} - update allowed_values, source_hint, description, min_confidence, or is_pii. key and value_type are immutable; create a new key and migrate if those need to change.

  • DELETE /v1/{workspace_id}/world/enrichment-keys/{key_id} - unregister a key. Historical events remain in the append-only log; future writes against that key return 400.

Value types: string, number, boolean, date, enum, json. Writes require the admin role or above (Workspace:Update). Reads are rate-limited.

Agent-extracted values that do not match a registered key are silently dropped, so they do not pollute the event stream or win over governed values. This gives admins full control over which attributes are tracked without blocking agent-side capture.

See the Data & World Model developer guide for the full request contract and the World Model conceptual overview.

v0.9.61 - Customer Data Intake (April 16, 2026)

Platform API: Customer Data Intake

New direct upload channel for approved customer integrations to stream PHI documents into a workspace landing zone. Complements the connector system for cases connectors cannot cover: bulk historical loads, partner document drops, and upstream systems that prefer to push on their own cadence.

  • POST /v1/{workspace_id}/intake/files - streams a single file body into workspace-isolated storage. Returns upload id, volume_path, server-computed sha256, size_bytes, and scan_status.

  • Two-layer authentication: the standard platform-api key or JWT plus a per-customer HMAC signature over a canonical request string (sha256:content_type:customer_slug:timestamp). Timestamp freshness window prevents replay.

  • Metadata travels in x-amigo-intake-* headers so large payloads stream without JSON buffering. Server recomputes SHA-256 during the stream; a mismatch deletes the partial object and returns 422.

  • Every accepted upload writes an append-only audit row (workspace, customer slug, storage path, filename, content type, hash, size, uploader actor, received-at, scan status) and emits a signal event for downstream pipelines to consume.

  • New permission scopes: intake:write (submit uploads) and intake:read (read the audit log). Neither is included in the default member role.

  • TLS-only transport and workspace-isolated storage meet HITRUST and HIPAA requirements for PHI ingestion.

Malware scanning, built-in parsing for the full format list (PDF, CCDA, FHIR bundles, CSVs), and a self-service portal for rotating customer HMAC secrets are on the near-term roadmap and will ship without changes to the upload contract.

See the Data Intake developer guide for the full request contract and the Customer Data Intake conceptual overview.

v0.9.60 - Warm Hand-Off, Agent Trace, Call Analysis & Webhook Filtering (April 15, 2026)

Platform API: Warm Hand-Off

New warm transfer flow for operator escalation. When a patient asks to speak with a human, the agent dials the call center into the existing conference, puts the patient on hold, briefs the operator with full conversation context, then connects them. The patient never repeats themselves.

Three conference phases driven by tool calls:

  • Normal - Agent and patient in conversation

  • Briefing - Agent and operator connected, patient on hold. The operator receives a real-time AI briefing with situation summary, patient context, and recommended actions. The operator can ask the agent questions or instruct it to resume with the patient.

  • Connected - Operator and patient connected, agent removed from the call

Barge-in is automatically disabled during the briefing phase to prevent the operator's speech from interrupting the agent's context transfer. The agent is stopped and removed from the conference once the operator takes over.

Platform API: Agent Trace APIs

Two new debugging endpoints for agent conversation analysis:

  • GET /calls/{id}/trace - Per-turn execution log with actions, tools, state transitions, emotions, inner thoughts, and latency. Includes barge-in details (interrupted text, discarded utterances).

  • GET /calls/{id}/prompts - Full LLM prompts (system prompt, conversation history, tool definitions) for each turn.

Equivalent endpoints are available for simulation sessions. Per-turn prompts are emitted as events for analytics queries.

Platform API: Call Trace Analysis

New GET /calls/{id}/trace-analysis endpoint providing audio-native intelligence analysis of completed calls. Returns emotional arc, key decision moments with causal attribution, counterfactual analysis, coaching recommendations, and interaction dynamics. Analysis is computed asynchronously after call completion, so the endpoint returns status: pending while processing and status: unavailable if analysis is not configured.

Platform API: Decision Trace

Agent reasoning is now classified with structured signal and effect types on each conversation turn. Every turn carries a signal_kind (what triggered the agent's response, such as caller speech, tool result, or state transition) and effect_kind (what the agent did: spoke, invoked a tool, navigated, or escalated). Decision events are emitted at call end for analytics, with three new metrics: turns per call, tool invocation rate, and state transition rate.

Platform API: Webhook Event Type Validation

Inbound webhook destinations now enforce accepted_event_types filtering. When a destination defines an event type whitelist, the platform extracts the event type from the signed request body (checking type, event_type, event, and action fields in priority order) and rejects payloads that don't match with a 422 response. Event type extraction uses only the signed body; unsigned headers are excluded to prevent spoofing via replay attacks with modified headers.

Platform API: Webhook Trigger Retry

Webhook destinations now support configurable retry on transient trigger fire failures via the retry_attempts field. When a connection timeout or network error occurs during trigger execution, the platform retries with exponential backoff (0.5s base delay). Only transient connection-level errors are retried; application errors that may have persisted data are not retried, preventing duplicate events from non-idempotent operations.

Platform API: Web Chat Audio Input

New POST /step-audio endpoint on text sessions allows web chat clients to send audio recordings instead of text. Audio is transcribed server-side and fed through the same reasoning pipeline as text input, so users can mix voice and text messages in the same session.

Platform API: Minimum TTS Speed

New min_tts_speed field on voice configuration sets a floor for the empathy engine's speed modulation. The empathy system reduces TTS speed after detecting caller distress, but without a floor it could make the agent sound unnaturally slow. The minimum speed prevents over-modulation while preserving the warmth response.

New world_payer_search tool for mid-call insurance payer lookup. Queries FHIR payer resources synced from the EHR with fuzzy matching (alias expansion for common abbreviations like "Blue Cross" to "BCBS", token overlap, and sequence matching). The agent can verify a patient's stated insurance carrier against the practice's accepted payer list during the call.

Platform API: Simulation Tags

Simulation runs and sessions now accept an optional tags parameter, an array of strings for labeling and filtering. Tags are persisted and returned through create and list endpoints.

Platform API: Surface Re-Delivery

Surfaces (agent-generated forms) can now be re-delivered after initial delivery. Previously, the deliver endpoint rejected surfaces that had already been sent. Now only terminal statuses (completed, expired, archived) and pending review block re-delivery. This allows resending form links when a patient loses the original.

Platform API: Context Graph Tool Validation

Pushing a context graph now validates that all referenced built-in integration tool IDs exist. Invalid tool references are rejected at push time rather than failing at runtime during calls.

v0.9.58 - Voice Pipeline, Semantic Search & Connector Architecture (April 13, 2026)

Platform API: Barge-In Improvements

Three changes to voice pipeline barge-in detection:

  1. Recognized speech required - Barge-in now always requires actual recognized words from the speech-to-text engine. Previously, sustained background noise classified as speech activity for 2 seconds could trigger an interrupt with zero recognized words. This eliminates false interruptions from coughs, breathing, HVAC, and background conversation.

  2. Short phrase support - The minimum speech duration for barge-in has been lowered significantly. Short responses like "yes," "no," and "okay" (200-400ms) can now trigger barge-in. Previously these finished before reaching the duration threshold and were only processed as end-of-turn events.

  3. Faster end-of-turn interrupt - When the speech engine detects end-of-turn with a complete transcript, the system now interrupts the agent's audio immediately from the recognition listener rather than waiting for the transcript processing queue. This eliminates 50-200ms of latency on short-phrase interrupts.

Platform API: Dynamic Call Forwarding

The forward_call tool now accepts an optional phone_number parameter (E.164 format) for ad-hoc call forwarding to any number. Previously, call forwarding was limited to pre-configured numbers from EHR location data or static workspace settings. The resolution priority is: explicit phone number (if provided) > location-based lookup (if location_id provided) > static workspace fallback. Workspaces only need forward_call_enabled in their voice configuration to use the tool - no pre-configured forwarding number is required.

Entity queries now support semantic similarity search via vector embeddings. The ?semantic=<query> parameter on the generic query endpoint performs cosine similarity against entity embeddings, which encode the full projected state (demographics, clinical data, relationships). This finds entities by meaning without requiring exact field matches, so searching "elderly patient with diabetes" returns relevant matches even when the exact phrasing differs.

A ?tags=<tag1,tag2> parameter supports array overlap filtering on entity tags. Both parameters compose with existing filters (entity_type, source, text search, confidence thresholds).

Platform API: Memory Analytics Sample Facts

The memory analytics endpoint now returns a sample_facts field on each dimension in the response. Sample facts are representative examples drawn from distinct entities using a windowed sampling approach that guarantees per-dimension coverage. Text is truncated for cache safety.

Platform API: Connector Configuration in Workspace Settings

Connector definitions are now managed through workspace settings with typed configuration models. Each connector definition includes a sync strategy field with strict validation, preventing a class of misconfiguration bugs (incorrect strategy values, missing fields). The data source response now includes an is_stale field computed from the connector's last successful sync and its configured cadence. Configuration changes are picked up by the connector runner's config refresh loop.

Platform API: Asynchronous Entity Projection

Entity state projection is now decoupled from the event write path. Writing an event no longer blocks on recomputing the entity's full state. Events insert immediately, and a background projection process recomputes entity state asynchronously. This reduces write latency for high-throughput scenarios (bulk imports, concurrent agent sessions) while maintaining the same eventual consistency guarantee: entity state reflects all events within seconds of the write.

Platform API: Event-Driven Review Queue

The review queue now processes flagged events immediately via event-driven notifications instead of polling on a fixed interval. When the world model writer commits a low-confidence event, it publishes a notification that the review loop picks up and processes within seconds. A periodic safety-net poll (every 5 minutes) catches any events missed by the real-time path. Stale item expiration runs on its own cadence, separate from the review evaluation cycle.

Classic API: Tool Repo Files Endpoint Method Change

The tool repository file retrieval endpoint has changed from GET to POST with a JSON request body. The ref and file_paths parameters that were previously sent as form/query parameters are now sent in the JSON body. The operation ID (get-tool-repo-files) remains unchanged.

Classic API: Prompt Log Error Tracking

Prompt logs now include an errored field that indicates whether the LLM interaction produced an error. This allows filtering prompt logs to identify failed interactions without downloading and inspecting the full log content.

Classic API: Dynamic Behavior Webhook Fix

The dynamic_behavior_set.version_changed webhook event now sends the correct body payload. Previously, the webhook body did not match the documented schema when a dynamic behavior set version was created or updated.

Platform API: Computer Use RDP Hardening

The Computer Use execution tier now supports production-grade Windows RDP connections with enterprise network configurations:

  • RD Gateway traversal for reaching desktops behind corporate firewalls

  • RemoteApp mode for single-application access (launching one application rather than a full desktop session)

  • Terminal farm load balancing for connecting to pools of application servers

  • Connection health monitoring between automation rounds with automatic reconnect on transient failures

  • Desktop integration configuration with 8 new fields for RDP gateway, RemoteApp, load balancing, and security settings

Platform API: Computer Use Agent Intelligence

The Computer Use execution tier now includes three intelligence layers that improve reliability on multi-step desktop automation tasks:

  • Context management - Old screenshots are compacted to text descriptions while retaining the most recent images for visual continuity. This enables long-horizon tasks (more than 3-4 steps) that previously exhausted the model's context window.

  • Reflection agent - Between automation rounds, a lightweight classifier evaluates whether the task is progressing, stuck in a loop, or complete. If stuck for three consecutive rounds, the task is terminated rather than looping indefinitely. Recovery suggestions are injected when the agent appears off-track.

  • Screen analysis - UI elements and error states are extracted from screenshots and provided as structured grounding hints, improving click accuracy on complex forms and multi-panel layouts.

Two new desktop actions are also available: clipboard-based typing for Unicode and special characters, and drag operations for selection and drag-and-drop workflows.

Platform API: Typed Entity Response Fields

Entity API responses now include 19 typed top-level fields for common attributes: name, phone, email, birth_date, gender, mrn, status, source, appointment_status, appointment_start, appointment_end, appointment_type, domain, industry, deal_stage, deal_amount, direction, duration_seconds, and call_sid. These fields are available on all entity types (returning null when not applicable) and replace the need to parse the unstructured state object. The state field is now deprecated - it will continue to be returned for backward compatibility but consumers should migrate to the typed fields.

Platform API: Entity Projection Pipeline

Entity state projection now runs as a continuous streaming pipeline. Entity projections are computed from the event stream and updated continuously as new events arrive. This replaces the previous interval-based background task with a streaming architecture that reduces projection latency and scales independently of the agent engine.

Classic API: Cached Token Metering

A new cached-token-count usage event is now emitted alongside the existing input-token-count event. This tracks how many input tokens were served from the prompt cache versus computed fresh, enabling more granular cost analysis and cache hit rate monitoring.

v0.9.57 - Computer Use Execution Tier (April 13, 2026)

Platform API: Computer Use Execution Tier

Skills now support a fifth execution tier: Computer Use. This enables any agent skill to interact with desktop applications (browsers, remote desktop sessions, and VNC connections) through a multi-turn automation loop.

The agent connects to a desktop session, reads screen content, and performs actions (clicking, typing, navigating) to complete tasks in systems that do not expose APIs. This is particularly relevant in healthcare, where many EHR platforms, insurance portals, and practice management tools are accessible only through their web or desktop interfaces.

Key capabilities:

  • Browser automation for web-based portals and applications

  • Remote desktop (RDP) and VNC connections for legacy desktop applications

  • Multi-turn interaction loops that handle multi-step UI workflows (login, navigate, fill forms, extract results)

  • Structured result extraction - the skill returns structured data back to the calling agent, not raw screenshots

Computer Use tasks run with the same confidence scoring, audit logging, and review pipeline as other tool types. The execution tier is configured per skill, so workspaces control which skills have desktop access.

The five skill execution tiers are now: Direct (single LLM call), Orchestrated (multi-turn with tools), Autonomous (extended agent loops), Browser (headless web automation), and Computer Use (full desktop automation).

v0.9.56 - EHR Integration Improvements & Appointment Data Quality (April 13, 2026)

Platform API: Expanded EHR Outbound Write-Back

The outbound sync engine now supports write-back to additional EHR systems via SMART Backend Services (FHIR). The new handler supports both deferred mode (queues changes until the target system enables write access) and live mode (immediate FHIR resource creation). This brings the total number of EHR systems with bidirectional sync to four.

Platform API: Connector Authentication Expansion

The SMART Backend Services authentication flow now supports additional JWT signing configurations for service account authentication. This expands the set of EHR systems and cloud healthcare services that can use machine-to-machine authentication for data exchange.

Platform API: Appointment Cancellation Handling

Appointment projections now correctly detect cancellations synced from EHR systems. Previously, cancellations were only recognized when sent as explicit cancellation events. Now, appointments with a cancelled status are detected regardless of the event type used by the source system. This fixes a data quality issue where EHR-synced cancellations could appear as active appointments.

v0.9.52 - Data-Platform-First Memory (April 10, 2026)

Platform API: Data-Platform-First Memory

Memory dimension scores and entity facts are now served from pre-computed tables populated by a background pipeline, replacing the previous inline extraction approach. This eliminates query-time computation overhead and provides faster, more consistent reads.

Key changes:

  • Dimension endpoint (GET /v1/{ws}/memory/{entity_id}/dimensions) reads pre-aggregated per-dimension stats (fact count, average confidence, source count, latest fact timestamp)

  • Facts endpoint (GET /v1/{ws}/memory/{entity_id}/facts) now includes an extracted_text field on each fact: a pre-computed human-readable summary of the fact's content. Previously, callers had to parse the raw event data themselves.

  • Analytics endpoint (GET /v1/{ws}/memory/analytics) is unchanged; it still queries live event data for workspace-level aggregation

The background pipeline runs as part of post-session processing. Newly ingested data is available in memory query results within seconds of pipeline completion. No API signature changes: existing integrations continue to work, and the extracted_text field is additive.

v0.9.51 - Behavior Settings, Sim Call Adapter & Outbound Prewarm (April 9, 2026)

Platform API: Behavior Settings

New workspace-level settings endpoint for managing dynamic behavior configurations:

Endpoint
Method
Description

/v1/{ws}/settings/behaviors

GET

Get current behavior settings

/v1/{ws}/settings/behaviors

PUT

Update behavior settings

Stores tool-level behavioral directives with keyword, emotion, and state triggers. The Developer Console reads from this endpoint for its Behaviors management page.

Platform API: Simulation Call Adapter

Simulated coverage sessions now appear alongside real calls in the calls page. The call list endpoint supports an include_simulated parameter and direction=simulated filter. Call detail falls back to the simulation adapter when a call ID is not found in the real call store, so simulation sessions are accessible through the same call detail interface used for production calls.

Platform API: Streaming Playground

Playground and simulation sessions now stream LLM tokens in real time through the observer bus. Frontends connect via WebSocket and see tokens, tool calls, and state transitions as they happen, using the same streaming infrastructure as live voice sessions.

Performance: Outbound Call Prewarm

Outbound calls now prewarm the engine during the dialing/ringing phase (5-15 seconds before patient answers). When the patient picks up, the engine and greeting are already initialized. Eliminates approximately 3 seconds of dead air at the start of outbound calls.

Performance: Function Catalog Warmup

Platform function catalog discovery is now cached, eliminating a cold start delay on the first call in a workspace. Subsequent calls resolve the function catalog in under 1ms.

Platform API: LLM Extraction for Custom Memory Dimensions

Custom memory dimensions now support an extraction_mode field: static (JSONPath, deterministic) or llm (semantic extraction using the dimension's description as a prompt). Built-in dimensions use static extraction. Custom dimensions default to LLM extraction for handling nuanced, context-dependent information.

v0.9.49 - Memory Settings, Email Channel & Hazel EHR (April 8, 2026)

Platform API: Memory Dimension Settings

New workspace-level API for configuring memory dimensions. Six built-in dimensions (clinical, behavioral, operational, social, engagement, risk) ship as defaults. Workspaces can add custom dimensions, adjust weights, or deactivate built-ins without code changes.

Endpoint
Method
Description

/v1/{ws}/settings/memory

GET

Get current memory dimension configuration

/v1/{ws}/settings/memory

PUT

Update memory dimension configuration

Changes take effect on the next post-session processing run. The memory pipeline reads configuration dynamically.

Platform API: Email Channel

Native email delivery for surfaces via workspace-configured email provider. Surface delivery now supports email as a first-class channel alongside SMS and WhatsApp, with the same lifecycle tracking (delivered, opened, submitted) and real-time events.

Platform API: Hazel EHR Adapter

New EHR connector adapter for Hazel Health systems. Supports inbound polling (patients, visits, time slots, insurance records) and outbound write-back (visit creation, cancellation, rescheduling, insurance card upload, confirmation logging).

Fix: Soft Escalation Without Crisis Flag

Fixed a bug where the conversation monitor's soft_escalate action was silently discarded when the crisis flag was not set. Non-emergency operator handoff requests (e.g., caller asking to speak with a human) now correctly trigger escalation and fire the call.escalated event to the operator command center.

v0.9.48 - Simulation Coverage, Multi-Step Forms & Tool Migration (April 8, 2026)

Platform API: Simulation Coverage (Branch-and-Bound)

New coverage testing API that systematically explores context graph state space using branch-and-bound exploration. Replaces the previous exploration-based simulation model with a knowledge graph that tracks every turn individually.

Endpoint
Method
Description

/v1/{ws}/simulations/coverage/runs

POST

Create a coverage run with an ephemeral database branch for write isolation

/v1/{ws}/simulations/coverage/runs/{id}/sessions

POST

Create a conversation session within a run

/v1/{ws}/simulations/coverage/sessions/{id}/step

POST

Step a session forward with a simulated user message

/v1/{ws}/simulations/coverage/sessions/{id}/fork

POST

Fork a session into N children at a decision point (core B&B primitive)

/v1/{ws}/simulations/coverage/sessions/{id}/score

POST

Score a session against configured metrics

/v1/{ws}/simulations/coverage/runs/{id}/graph

GET

Retrieve the coverage knowledge graph with topology overlay and ghost nodes

/v1/{ws}/simulations/coverage/runs/{id}/complete

POST

Complete a run and clean up ephemeral branches

The knowledge graph includes observed turns (per-state session counts, pass rates, turn counts) and a topology overlay with ghost nodes for context graph states never reached in any session. The fork primitive atomically clones parent session state N times, steps each with a different simulated message, and returns all observations.

Platform API: Multi-Step Surface Forms

Surface forms with sections now render as stepped pages with progress bar, Next/Back navigation, and per-step field validation. Single-section and no-section forms continue to render as a single page (backward compatible).

Platform API: Gap Scanner Appointment Detection

The gap scanner now detects upcoming appointments using a batch query that joins entity relationships with appointment events at scan time. This runs once per workspace per tick and reads current event state directly, so appointment updates (cancellations, rescheduling) are reflected immediately.

Platform API: Legacy Tool Execution Removed

All workspaces have been migrated from the legacy serverless tool execution infrastructure to the platform's built-in tool system. The legacy tool executor and its associated configuration have been removed. Existing tool definitions continue to work; only the execution backend changed. This removes an external compute dependency and simplifies the deployment footprint.

v0.9.47 - Personas, Workflows & New Clinical Primitives (April 7, 2026)

Platform API: Personas

New first-class resource for cross-channel agent identity. A Persona defines who the agent is (name, role, background, communication style) independently of how it communicates (voice configuration, channel type). Services now reference a persona_id instead of embedding identity fields directly.

Endpoint
Method
Description

/v1/{ws}/personas

POST

Create a persona

/v1/{ws}/personas

GET

List personas (paginated, sortable)

/v1/{ws}/personas/{id}

GET

Get a specific persona

/v1/{ws}/personas/{id}

PUT

Update a persona

/v1/{ws}/personas/{id}

DELETE

Delete a persona

Services display the associated persona_name alongside the persona ID for easier identification.

Platform API: Environment & Workflow Settings

Two new workspace settings resources for configuration management:

  • Environment settings (GET/PUT /v1/{ws}/settings/environments) - Per-environment configuration overlays (sandbox vs production). Services reference an environment, and the overlay provides tool and data source overrides. Audit-logged.

  • Workflow settings (GET/PUT /v1/{ws}/settings/workflows) - Declarative multi-step workflow specifications stored at the workspace level. Enables structured, repeatable operational workflows that agents can follow.

Platform API: Queue & Ticket Tools

Two new built-in clinical tools:

Tool
Type
Description

queue_lookup

Read

Reads outbound task entities from the world model, returning pending/scheduled tasks ordered by priority or next attempt time. Filterable by status (scheduled, dispatched, completed, failed, cancelled, snoozed).

ticket_create

Write

Creates a support ticket event for a patient entity. Writes a ticket.created event that flows through outbound sync to the workspace's ticketing or CRM system. Supports title, description, priority (low/normal/high/critical), and category.

Platform API: Charm EHR Adapter

New EHR connector adapter for Charm systems. Supports patient polling, appointment reference data sync, and outbound appointment writes with CRM engagement tracking.

Platform API: Data Collection in Context Graphs

Context graphs can now include declarative data collection specifications. Instead of relying solely on the agent to identify missing data, context graph states can define what data must be collected and the system handles field rendering, validation, and world model integration automatically.

Breaking: Legacy Tool Aliases Removed

Legacy tool name aliases have been removed. All built-in clinical tools now use their canonical names only. Context graphs referencing the old names are automatically migrated.

Platform API: Multi-Number WhatsApp

WhatsApp messaging now supports multiple sender numbers per workspace with per-organization credential scoping. This enables workspaces to use different WhatsApp numbers for different services or departments.

v0.9.46 - Clinical Tools Expansion & Meditab EHR Adapter (April 6, 2026)

Platform API: New Clinical Tools

Three new built-in tools available during voice and text interactions:

Tool
Type
Description

log_call

Write

Records call outcome events (appointment booked, confirmed, declined, no answer, rescheduled, voicemail left, callback requested). Outcomes flow through outbound sync to source systems for reporting and workflow automation.

reschedule_appointment

Write

Reschedules an existing appointment to a new slot. Cancels the original and books the replacement atomically.

save_patient

Write

Combined create-or-update operation. Updates an existing patient when entity ID is provided, or creates a new record with duplicate checking when not. Accepts flexible date formats and natural field names.

Platform API: World Tool Prefix

Built-in clinical tools have been renamed to use a consistent naming convention. The previous tool names continue to work as legacy aliases, so no migration is required.

Platform API: Meditab EHR Adapter

New EHR connector adapter for Meditab systems. Uses SMART Backend Services authentication for standards-based connectivity. Supports appointment slot search and scheduling operations through the connector runner.

v0.9.45 - Database-Level Workspace Isolation (April 6, 2026)

Platform API: Database-Level Workspace Isolation

Workspace data isolation is now enforced at the database layer in addition to application-level access controls. Every data query is automatically scoped to the current workspace before execution, so no code path can access data across workspace boundaries.

This is a defense-in-depth measure for healthcare deployments where data isolation is a compliance requirement:

  • Fail-closed design - If workspace context is missing from a request, the query returns zero rows rather than defaulting to unscoped access

  • Full coverage - Applies to all data tables: events, entities, entity relationships, data sources, sessions, calls, surfaces, and configuration

  • Independent safety net - Database-level enforcement cannot be bypassed by application code, even in the event of a bug in the API layer

Application-level access controls (API keys, role-based permissions) remain the primary access mechanism. The database layer provides an independent guarantee that data never leaks between workspaces.