Archive: v0.9.100 - v0.9.249

Archived Amigo API release notes covering v0.9.100 - v0.9.249. 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.249 - Platform API: Call Trace Analysis Retry Guidance Updated (July 2026)

Call Trace Analysis Retry Guidance Updated

The call trace analysis endpoint now recommends a longer retry interval for calls in pending status.

What changed:

• Retry guidance updated. The pending status description on the call trace analysis endpoint previously recommended retrying after 15 minutes. The recommended retry interval is now 30 minutes, reflecting updated processing cadence for the analysis pipeline.

What you need to do:

• Update polling intervals. If your integration polls the call trace analysis endpoint for pending results on a 15-minute interval, increase it to 30 minutes. More frequent polling still works but will return pending for longer before results are available.

v0.9.248 - Platform API: Integration Model Simplified (July 2026)

Integration Model Simplified

The integration data model has been simplified. The previous two-layer structure (a parent integration record plus a separate child record for REST-specific fields) has been collapsed into a single integration resource. All integration fields - including base_url and auth - now live directly on the integration object.

What changed:

• Flat integration model. Integration responses no longer use an internal parent/child structure. The base_url and auth fields are returned directly on the integration resource alongside name, display_name, enabled, and other existing fields. This is a structural simplification with no change to the response shape or field names visible to API consumers.
• kind field removed from integration responses. The kind field is no longer returned in integration responses or accepted in create/update requests. All integrations are REST integrations. The kind filter has been removed from the list integrations endpoint.
• kind field removed from internal integration payloads. Internal integration payloads used during session initialization no longer include a kind field. If your code consumes internal integration data and checks or filters by kind, remove that logic.
• No changes to endpoint structure. Integration endpoints (the per-action definitions within an integration) are unchanged. They continue to reference the parent integration directly.

What you need to do:

• Remove references to kind. If your code reads, filters, or sets the kind field on integrations, remove those references. The field is no longer present in responses or accepted in requests.
• No other migration required. The visible response fields (id, workspace_id, name, display_name, base_url, auth, enabled, endpoint_count, created_at, updated_at) are unchanged. Existing API consumers that do not reference kind require no changes.

v0.9.247 - Platform API: Desktop Integration Type and Computer Use Skill Tier Removed (July 2026)

Desktop Integration Type and Computer Use Skill Tier Removed

The platform no longer supports desktop-type integrations or the computer use execution tier for skills. REST integrations remain the only supported integration kind. The desktop sidecar infrastructure for remote desktop connectivity is retained as a standalone component but is no longer managed through the platform API.

What changed:

• Desktop integrations removed. The desktop integration kind has been removed. Integrations endpoints no longer accept or return desktop-type integrations. The kind filter on the list integrations endpoint no longer includes desktop as a valid value. Existing desktop integration records are archived but no longer accessible through the API.
• Computer use execution tier removed from skills. Skills no longer support the computer_use execution tier. The execution_tier field has been removed from skill configuration. All skills now use the standard orchestrated execution model.
• Desktop session endpoints removed. All desktop session management endpoints have been removed from the API. These endpoints previously handled creating, managing, and terminating desktop automation sessions.
• Task queue endpoints removed. Task dispatch and task status endpoints associated with background skill execution have been removed.
• Skill response model simplified. The execution_tier and desktop_integration fields are no longer returned in skill responses.
• Integration response model simplified. The kind field is still present on integration responses but will always be rest. Desktop-specific fields (host, port, display dimensions, gateway configuration, remote app settings) are no longer returned.

What you need to do:

• Remove references to desktop integrations. If your code creates or filters integrations by kind: desktop, remove those references. Only rest integrations are supported.
• Remove references to execution_tier. If your code sets execution_tier on skill configurations, remove that field. The field is no longer accepted.
• Remove references to desktop_integration. If your skill configurations reference a desktop_integration name, remove that field.
• Remove calls to desktop session endpoints. If your code calls desktop session management endpoints, remove those calls.
• Remove calls to task queue endpoints. If your code calls task dispatch or task status endpoints, remove those calls.

v0.9.246 - Platform API: Simulation Case Eval Execution (July 2026)

Simulation Case Eval Execution

Simulation runs now automatically execute evaluation criteria (evals) defined on saved cases when a run completes. Eval results are returned inline on the run detail endpoint.

What changed:

• Automatic eval execution on run completion. When a simulation run finishes, the platform evaluates all eval definitions captured from the run's cases. Two eval types are supported: assertions (which validate conversation outcomes) and metric checks (which compare observed metric values against expectations).
• Assertion eval kinds. Assertion evals support several kinds: transcript_contains and must_contain check whether a phrase appears in the conversation transcript; transcript_not_contains and must_not_contain verify a phrase does not appear; tool_called checks whether a specific tool was invoked during the conversation; final_state checks whether the conversation ended in an expected state; and llm_judge uses an AI evaluator to judge the transcript against a natural-language criterion.
• Metric eval checks. Metric evals look up observed metric values for the run and compare them against configured expectations. Expectations can specify exact equality, numeric ranges (gte/min, lte/max), or string containment.
• New fields on GET /runs/{run_id} response. The run detail response now includes eval_results (array of eval result objects), eval_result_count, eval_pass_count, eval_fail_count, and eval_error_count.
• Eval result object. Each eval result includes id, run_id, case_id, session_id, eval_key, eval_type, assertion_kind, metric_key, status (passed, failed, pending, skipped, or error), passed, score, expected, actual, rationale, details, definition, and created_at.
• Real-time events. Eval results emit events through the standard event pipeline, so dashboards and listeners can react to eval outcomes as they are produced.

What you need to do:

• No action required. The new fields are additive. Existing integrations that do not read eval results are unaffected.
• To use case evals, define evals on your simulation cases (assertion or metric type with the appropriate kind, expected values, and parameters). When runs complete, eval results will appear automatically on the run detail response.
• To track eval progress, read the eval_result_count, eval_pass_count, eval_fail_count, and eval_error_count fields from the run detail to get summary counts without iterating the full results array.

v0.9.245 - Platform API: Context Graph State in Non-Streaming Turn Responses (July 2026)

Context Graph State in Non-Streaming Turn Responses

The non-streaming conversation turn endpoint now returns the current context graph state alongside the agent response, giving callers visibility into where the agent is in the conversation flow after each turn.

What changed:

• New context_graph_state field on turn responses. Non-streaming turn responses now include a context_graph_state field (object or null). When available, this field contains the agent's current position in the context graph, including the active node, visited states, and state-specific metadata. The field is null when the context graph state cannot be determined.
• No change to streaming responses. This field is only returned on non-streaming (REST) turn responses. Streaming turn interactions are not affected.

What you need to do:

• No action required. The new field is additive. Existing integrations that do not read context_graph_state are unaffected.
• To use context graph state, read the context_graph_state field from the turn response object. Use it to track conversation flow progression, render navigation indicators, or drive conditional logic based on the agent's current state.

v0.9.244 - Platform API: REST Integration Endpoints as Context Graph Tool IDs (July 2026)

REST Integration Endpoints as Context Graph Tool IDs

Context graph validation now accepts REST integration endpoints as valid tool references. Previously, tool IDs in context graph states could only reference built-in tools, platform functions (fn_*), workspace data queries (wsq_*), and skill slugs. Now, endpoints from enabled workspace REST integrations are also accepted.

What changed:

• Integration endpoints accepted as tool IDs. Context graph tool references using the {integration_name}_{endpoint_name} format are validated against the workspace's enabled REST integrations. Each enabled integration's endpoints are resolved during context graph version creation, so references to disabled or nonexistent integrations are rejected.
• Validation scoped to workspace. Integration endpoint resolution is scoped to the workspace that owns the context graph. Endpoints from integrations in other workspaces are not visible and will fail validation.

What you need to do:

• No action required for existing context graphs. This change only adds a new category of accepted tool IDs. Existing context graphs that do not reference integration endpoints are unaffected.
• To use integration endpoints in context graphs, ensure the target REST integration is enabled in your workspace and reference endpoints using the {integration_name}_{endpoint_name} format in your tool ID fields.

v0.9.243 - Platform API: API Key Name in Expiry Alerts (July 2026)

API Key Name in Expiry Alerts

API key expiration alerts now include the key name alongside the key ID, making it easier to identify which key is approaching expiry without looking it up manually.

What changed:

• Key name included in expiry notifications. Expiration alert messages now display the API key name as a separate field before the key ID. If no name was set on the key, the alert displays "Unknown" as the key name.
• Webhook payload updated. The API key expiry webhook payload now includes an optional api_key_name field (string or null). Existing webhook consumers are not affected - the field is additive and defaults to null when not present.

What you need to do:

• No action required. Expiry alerts will automatically include the key name going forward. If you consume API key expiry webhooks programmatically, you can optionally read the new api_key_name field from the payload.

v0.9.242 - Platform API: Integration Auth Redesign (July 2026)

Integration Auth Redesign

Integration authentication types have been restructured into four clear variants with a unified secret storage model. The previous six auth types (api_key_header, bearer_token, oauth2_client_credentials, json_token_exchange, oauth2_jwt_bearer, bearer_token_exchange) are replaced by four types with cleaner configuration surfaces.

What changed:

• New auth types. Four auth types replace the previous six:

  • static_header - Replaces api_key_header and bearer_token. A single secret value sent verbatim as one header. For bearer tokens, store the full Bearer <token> string as the secret value and set header_name to Authorization.
  • oauth2_client_credentials - RFC 6749 § 4.4 Client Credentials grant. Now supports a client_auth_method field (basic or body) to control how client credentials are sent to the token endpoint.
  • oauth2_jwt_bearer - RFC 7523 § 2.1 JWT Bearer Token grant. Now supports configurable signing algorithms (RS256 through ES512), explicit include_iat and include_jti toggles, required assertion_subject field, and an extra_claims object for vendor-specific JWT extensions.
  • custom_token_exchange - Replaces json_token_exchange and bearer_token_exchange. A general-purpose pre-flight exchange with configurable request encoding (json or form), static and parameter-sourced headers and body fields, and a JSON Pointer path for extracting the token from the exchange response.
• Unified secret storage. All auth types now use a single secret_value field on the create/update request. The secret is stored at a single per-integration path. The previous per-type secret suffixes (api_key, bearer_token, client_secret, private_key, exchange_secret) are consolidated.
• secret_value moved to top level. The secret_value field is now a top-level field on the integration create/update request body, not nested inside the auth object. It is required when auth is provided.
• JSON Pointer keys for static body fields. Endpoint static_body_fields now use RFC 6901 JSON Pointer syntax (e.g. /meta/tool_name) instead of dot-notation (meta.tool_name).
• RFC 6570 URI Templates for path parameters. Endpoint paths now use RFC 6570 Level 1 URI Templates (e.g. /patients/{patient_id}/appointments) instead of the previous {param} convention. Behavior is the same - matched parameters are URL-encoded and consumed from the request params.
• Auto-merged input schemas for custom token exchange. When an integration uses custom_token_exchange auth with parameter mappings (param_headers or param_body_fields), the mapped parameters are automatically added to each endpoint's input schema. This ensures the agent knows to supply these values without manual schema duplication.
• Error handling. Integration endpoint calls now raise a structured error on any failure (auth errors, transport failures, HTTP error responses, response processing errors) instead of returning an error envelope in the success response. LLM-facing callers receive a JSON error payload so the agent session continues running.

What you need to do:

• If you use api_key_header auth: Change type to static_header. Move secret_value to the top-level request body.
• If you use bearer_token auth: Change type to static_header, set header_name to Authorization, and prepend Bearer to your secret value. Move secret_value to the top-level request body.
• If you use oauth2_client_credentials auth: Add client_auth_method (either basic or body). Move secret_value to the top-level request body.
• If you use json_token_exchange auth: Migrate to custom_token_exchange. Map your token_request_client_id_field and token_request_client_secret_field to static_body_fields entries (use {secret} placeholder for the secret). Set response_token_path to a JSON Pointer equivalent of your token_response_path (e.g. access_token becomes /access_token). Move secret_value to the top-level request body.
• If you use bearer_token_exchange auth: Migrate to custom_token_exchange. Map your exchange_secret_header and exchange_secret_format to static_headers entries. Map exchange_param_headers to param_headers. Set response_token_path to a JSON Pointer (e.g. token becomes /token). Move secret_value to the top-level request body.
• If you use oauth2_jwt_bearer auth: Add the now-required fields: assertion_subject, assertion_algorithm, include_iat, include_jti, and extra_claims (empty object {} if not needed). The assertion_scopes_in_jwt field is removed - use extra_claims with key scope instead. Move secret_value to the top-level request body.
• If you use dot-notation static_body_fields on endpoints: Convert to JSON Pointer syntax (e.g. meta.tool_name becomes /meta/tool_name).

v0.9.241 - Platform API: First-Class Simulation Suites (July 2026)

First-Class Simulation Suites

Simulation suites are now first-class resources with full CRUD support and a dedicated run endpoint. Previously, suites were derived dynamically from suite:* tags on saved cases. Suites are now independent, named collections that define an explicit case list and optional required tags for dynamic case matching.

What changed:

• New suite endpoints. Five new endpoints for managing simulation suites:

  • POST /simulations/suites - Create a suite with a name, description, explicit case IDs (max 500), required tags for dynamic matching, suite-level tags, and metadata.
  • GET /simulations/suites - List all suites in the workspace, ordered by creation date (newest first). Each suite includes a case_count reflecting the total resolved cases.
  • GET /simulations/suites/{suite_id} - Get a single suite by ID.
  • PATCH /simulations/suites/{suite_id} - Partially update a suite. At least one field is required.
  • DELETE /simulations/suites/{suite_id} - Delete a suite (204 on success).
• Dedicated suite run endpoint. POST /simulations/suites/{suite_id}/run executes all cases resolved by a suite as a benchmark batch. The suite's explicit case IDs and required tags are combined to select the case set. The required_tags field must not be provided in the request body for suite runs.
• Suite support on benchmark endpoint. POST /simulations/benchmarks/run now accepts an optional suite_id field. When provided, the benchmark resolves cases from the suite definition instead of using required_tags. suite_id and required_tags are mutually exclusive - providing both returns HTTP 422.
• Updated suite response shape. The suite list and detail responses now return full suite objects with id, workspace_id, name, description, case_ids, required_tags, tags, metadata, case_count, created_by, created_at, and updated_at. The previous tag-derived response shape (tag, name, service_ids, latest_updated_at) is replaced.
• Updated benchmark response. The benchmark run response now includes an optional suite_id field indicating which suite triggered the run, if any.
• Stricter request validation. Create and update request bodies for simulation cases and suites now reject extra fields (HTTP 422) instead of silently ignoring them.

What you need to do:

• If you used the GET /simulations/suites endpoint: Update your client to handle the new response shape. The response now returns full suite objects instead of tag-derived summaries. The tag, service_ids, and latest_updated_at fields are no longer present.
• If you created suites by tagging cases with suite:* tags: Existing suite:* tags on cases still work for filtering, but suites are now managed as independent resources. Create explicit suite resources to take advantage of the new suite management and run capabilities.
• If you used the benchmark endpoint: The required_tags field is now optional (it was previously required for meaningful results). You can use suite_id instead to run a suite-based benchmark.
• If you sent extra fields in case create/update requests: Review your request payloads. Extra fields that were previously ignored now cause a 422 validation error.

v0.9.240 - Platform API: Voice Conversation Turn Fallback to Durable Store (July 2026)

Voice Conversation Turn Fallback to Durable Store

Voice conversation detail now falls back to the durable analytical store when turn data is no longer available in the hot session cache. Previously, voice conversation detail only read turns from the hot cache, which meant conversations whose cache had expired returned an empty turns array even though turn data existed in the durable store.

What changed:

• Automatic fallback for voice turns. The voice conversation detail endpoint now uses the same two-tier turn resolution as text conversations - the hot session cache is checked first, and if no turns are found, the endpoint reads from the durable analytical store. This ensures that historical voice conversations retain their full turn history regardless of cache expiration.
• Consistent behavior across channels. Text and voice conversation detail endpoints now follow the same turn resolution path. Both channels check the hot cache first and fall back to the durable store, so turn availability is consistent regardless of conversation type.
• No change to response shape. The voice conversation detail response schema is unchanged. Conversations that previously returned an empty turns array due to cache expiration will now return their full turn history.

What you need to do:

• No action required. This is a backwards-compatible improvement. Voice conversation detail responses that previously returned empty turns for expired sessions will now include the full turn history. If your application handled empty turns arrays as a special case for older voice conversations, that workaround is no longer necessary.

v0.9.239 - Platform API: Simulation Case Scenario Backfill (July 2026)

Simulation Case Scenario Backfill

Simulation case responses now guarantee that the scenario.instructions field is always present and non-empty across all endpoints that return simulation cases.

What changed:

• scenario.instructions always populated. The list, get, create, and update simulation case endpoints now ensure that every returned case includes a non-empty scenario.instructions value. Previously, legacy cases that were created before the schema restructuring could return an empty or missing instructions field inside the scenario object.
• Fallback for legacy cases. Cases that have no scenario instructions - for example, cases created before the schema migration - now fall back to the case description. If neither is available, a default placeholder is returned. This prevents API consumers from receiving empty scenario content for older cases.
• Database backfill included. Existing legacy cases with empty scenario data have been backfilled so that their stored scenario content is consistent with the new guarantee.

What you need to do:

• No action required. This is a backwards-compatible fix. If your code already handles the scenario.instructions field from the v0.9.238 schema, it will continue to work. Cases that previously returned empty instructions now return meaningful content instead.
• If you had workarounds for empty scenario.instructions: You can safely remove any client-side fallback logic that handled missing or empty instructions, as the API now guarantees a non-empty value.

v0.9.238 - Platform API: Simulation Case Schema Refactored (July 2026)

Simulation Case Schema Refactored

The simulation case schema has been restructured to use a nested, composable shape. Flat top-level fields for scenario content, grounding, evaluation criteria, and provenance have been replaced with structured objects. This is a breaking change to the simulation case create, update, and response shapes.

What changed:

• scenario replaces scenario_instructions, initial_message, and temperament. These three fields are now nested inside a scenario object with keys instructions, initial_message, and temperament. The scenario.instructions field is required and must be non-empty. initial_message defaults to an empty string and temperament defaults to null.
• grounding replaces fixtures. The fixtures object has been replaced by a grounding object. Currently supports one optional field: patient_entity_id (UUID). The previous fixtures.case_specific, fixtures.grounding_facts, and fixtures.schema sub-fields are no longer accepted.
• evals replaces assertions. The assertions array has been replaced by an evals array. Each eval item is a discriminated union with a type field. Two types are supported: metric (with metric_key, expected, params, weight) and assertion (with key, assertion_kind, description, expected, params, weight). Maximum 100 items per case.
• metadata replaces provenance. The provenance string field has been removed. A free-form metadata object is now available for arbitrary key-value data. Cases created by the scenario generator or bridge include a source key in metadata (e.g. "source": "bridge").
• constraints and target_spec removed. These top-level fields are no longer part of the case schema. Target specifications and constraints are now managed through evals and metadata.
• Per-case entity ID resolution updated. Benchmark runs that resolve a patient entity ID per case now read from grounding.patient_entity_id instead of fixtures.case_specific.entity_id or fixtures.entity_id.
• Run tags updated. Cases with a source value in metadata produce a source:<value> run tag instead of the previous provenance:<value> tag.

What you need to do:

• If you create simulation cases via the API: Restructure your request body. Move scenario_instructions, initial_message, and temperament into the scenario object. Move fixture data into grounding. Convert assertions to evals with the appropriate type discriminator. Replace provenance with a metadata object containing a source key if needed.
• If you read simulation case responses: Update your parsing to read from the new nested fields (scenario.instructions, scenario.initial_message, scenario.temperament, grounding.patient_entity_id, evals, metadata) instead of the removed top-level fields.
• If you update simulation cases via PATCH: Use the new field names (scenario, grounding, evals, metadata) in your update payloads. The old field names (scenario_instructions, initial_message, temperament, fixtures, constraints, target_spec, assertions, provenance) are no longer accepted.
• If you rely on per-case entity IDs in benchmarks: Set grounding.patient_entity_id on each case instead of embedding the entity ID in fixtures.

v0.9.237 - Platform API: Integration Endpoint Addressing Changed to ID (July 2026)

Integration Endpoint Addressing Changed to ID

Integration endpoint routes now use the endpoint's stable id instead of the endpoint name as the path parameter. The create-integration endpoint no longer accepts inline endpoints - endpoints must be added individually after the integration is created. The list-endpoints endpoint now supports search, multi-axis sorting, and cursor-based pagination.

What changed:

• Endpoint path parameter changed from endpoint_name to endpoint_id. The GET, PATCH, DELETE, and test routes for individual endpoints now use the endpoint's UUID (endpoint_id) instead of the endpoint name. The endpoint id is returned in the create and list responses.
• Create integration no longer accepts inline endpoints. The endpoints array has been removed from the create-integration request body. To add endpoints, use POST /integrations/{integration_id}/endpoints after creating the integration.
• Endpoint responses now include id. All endpoint responses (create, get, list, update) now include a stable id field (UUID) that uniquely identifies the endpoint.
• retry_on_status is now a set. The retry_on_status field on endpoint create, update, and response objects is now a set of integers (no duplicates) instead of an array. Duplicate status codes in requests are automatically deduplicated.
• List endpoints now supports search and sorting. The list-endpoints route accepts search (substring match on name or description), sort_by (repeated query param with +field or -field syntax; allowed fields: name, created_at, updated_at), limit (1-200, default 50), and continuation_token (opaque cursor for pagination).
• Get integration returns endpoint_count instead of inline endpoints. The integration response body now includes an endpoint_count integer instead of the full endpoints array. Use the list-endpoints route to retrieve endpoint details.
• Get integration returns both REST and desktop kinds. The get-integration route now returns a discriminated response that includes desktop integrations in addition to REST integrations.
• Delete integration returns 409 when referenced by skills. Deleting an integration that is referenced by one or more skills now returns 409 Conflict with a message listing the referencing skill names, instead of silently succeeding.

What you need to do:

• If you call endpoint routes using endpoint_name in the URL path: Update to use the endpoint id (UUID) instead. Retrieve endpoint IDs from the create or list responses.
• If you pass endpoints in the create-integration request body: Remove the endpoints field. Create the integration first, then add endpoints individually using the create-endpoint route.
• If you read endpoints from integration responses: Use the endpoint_count field for summary information. Call the list-endpoints route to retrieve full endpoint details.
• If you read retry_on_status as an ordered array: Treat the field as an unordered set. Duplicate values are no longer preserved.
• If you paginate the list-endpoints route: The response shape now includes items, has_more, and continuation_token fields. Pass the continuation_token from the response back as a query parameter to retrieve the next page.

v0.9.236 - Platform API: Direct Execution Tier Removed (July 2026)

Direct Execution Tier Removed

The direct execution tier has been removed from the Skills API. Skills that previously used the direct tier - which executed a single integration endpoint call without a companion agent - should be reconfigured to use endpoint overrides or the orchestrated tier instead.

What changed:

• direct removed from execution_tier. The execution_tier field on skill create, update, and response objects now accepts only orchestrated and computer_use. Requests that specify direct are rejected.
• system_prompt now required for all skills. Previously, system_prompt was optional for direct-tier skills (since no companion agent was involved). With the direct tier removed, every skill requires a system_prompt.
• Task state tier field no longer includes direct. The tier field on task state responses now accepts companion, desktop, and computer_use. Tasks default to companion when no tier is recorded.
• Former direct-tier skills migrated automatically. Existing skills that used the direct tier have been migrated to use endpoint overrides. The underlying integration endpoint is now invoked directly by the agent as a tool rather than wrapped in a dedicated skill.

What you need to do:

• If you create or update skills with execution_tier: "direct": Change to orchestrated (or computer_use if applicable) and provide a system_prompt. Alternatively, remove the skill and let the agent call the underlying integration endpoint directly.
• If you read execution_tier from skill responses and handle direct: Remove handling for the direct value. Only orchestrated and computer_use are returned.
• If you read the tier field from task state responses and handle direct: Remove handling for direct. The value is no longer returned.

v0.9.235 - Platform API: Integration Endpoint Config Reshaped (July 2026)

Integration Endpoint Config Reshaped

Integration endpoint configuration has been simplified. Response shaping now uses a single Jinja template instead of separate filter, key, and template fields. Request-side static injection uses a flat field map instead of a nested transform object. Retry and timeout settings are now direct fields instead of a nested config object.

What changed:

• response_template replaces response_filter, result_key, and result_template. Response shaping is now a single Jinja template string rendered in a sandboxed environment. The template receives the parsed JSON response as top-level variables. Missing fields must be handled explicitly with | default("N/A") - unhandled missing fields raise an error. Set to null to fall back to the raw JSON response.
• max_response_length replaces max_result_length. Same behavior (truncate rendered output to prevent token bloat, 0 = no limit), renamed for clarity.
• static_body_fields replaces request_transform. Static fields are now a flat key-value map merged into POST/PUT/PATCH request bodies. Keys support dot-notation to build nested objects (e.g. meta.tool_name becomes {"meta": {"tool_name": ...}}). The inject map and wrap_params_key from the previous request_transform object are no longer accepted.
• timeout_seconds added. Per-request HTTP timeout, configurable from 0 to 600 seconds. Default: 30.0. Previously this was a fixed internal default.
• max_retries and retry_on_status replace retry_config. Retry settings are now direct fields on the endpoint instead of a nested object. Defaults are unchanged (max_retries: 2, retry_on_status: [429, 502, 503, 504]).
• Test endpoint response reshaped. The after_filter and after_mapping fields have been removed from the test endpoint response. A new rendered field shows the output after Jinja template rendering. final_result now contains the rendered output after truncation.

What you need to do:

• If you set response_filter, result_key, or result_template on endpoints: Replace these with a single response_template using Jinja syntax. For example, a template like {{name}} - {{birthDate}} replaces the old result_template with {{field.path}} placeholders. Add | default("N/A") to any field reference that might be missing.
• If you set max_result_length on endpoints: Rename to max_response_length. The value and behavior are unchanged.
• If you use request_transform with inject or wrap_params_key: Replace with static_body_fields. Move injected key-value pairs directly into the map. If you used wrap_params_key, restructure your endpoint configuration to use dot-notation keys in static_body_fields instead.
• If you set retry_config on endpoints: Replace with max_retries and retry_on_status as direct fields.
• If you read after_filter or after_mapping from test endpoint responses: Replace with rendered. The final_result field now matches rendered after truncation.

v0.9.234 - Platform API: Skill and Integration Delivery Fields Removed (July 2026)

Skill and Integration Delivery Fields Removed

The delivery and urgency_keywords fields have been removed from the Skill API. The result_delivery field has been removed from integration endpoint objects. Result delivery is now configured per state in the context graph rather than on individual skills or integration endpoints.

What changed:

• delivery removed from skills. The delivery field (values: interrupt, queue) has been removed from skill create, update, and response objects. Skills no longer carry a delivery mode - delivery behavior is determined by the context graph state that binds the tool.
• urgency_keywords removed from skills. The urgency_keywords field has been removed from skill create, update, and response objects. Urgency-based delivery escalation is no longer configured at the skill level.
• result_delivery removed from integration endpoints. The result_delivery field (values: interrupt, queue) has been removed from endpoint create and response objects. Integration endpoints no longer carry a delivery mode.
• Delivery configured on context graph state bindings. Result delivery is now a property of the context graph state's tool binding. The same tool can use different delivery modes in different states - for example, a tool can queue results silently during an intake state and interrupt immediately during a prescribing state. Existing configurations have been migrated automatically.

What you need to do:

• If you set delivery or urgency_keywords when creating or updating skills: Remove these fields from your request bodies. They are no longer accepted.
• If you read delivery or urgency_keywords from skill responses: Remove references to these fields. They are no longer included in responses.
• If you set result_delivery when creating integration endpoints: Remove this field from your request bodies. It is no longer accepted.
• If you read result_delivery from endpoint responses: Remove references to this field. It is no longer included in responses.
• To configure delivery behavior: Set the delivery mode on the tool binding within each context graph state where the tool is used.

v0.9.233 - Platform API: Integration Schema Redesign - REST/Desktop Split, Update Endpoint, Per-Endpoint CRUD (July 2026)

Integration Schema Redesign

Integrations have been restructured into variant-specific types. The public API now exclusively manages REST integrations and exposes new endpoints for updating integrations and managing individual endpoints. Desktop integrations are system-provisioned and not accessible through the public CRUD surface.

What changed:

• kind replaces protocol. Integration responses now include a kind field (value: rest) instead of the previous protocol field. The protocol query parameter has been removed from the list endpoint.
• builtin field removed. The builtin field has been removed from integration responses. All integrations returned by the public API are workspace-scoped rows created through the standard create flow.
• base_url is now required on create. The base_url field is required when creating an integration. Previously it defaulted to an empty string.
• Update integration endpoint added. PATCH /integrations/{integration_id} is now available. You can update display_name, base_url, enabled, and auth individually without deleting and recreating the integration. Auth updates require setting auth_provided: true in the request body to distinguish between "leave auth unchanged" and "clear auth".
• Per-endpoint CRUD added. Endpoints on a REST integration can now be managed individually:

  • POST /integrations/{integration_id}/endpoints - Add an endpoint
  • GET /integrations/{integration_id}/endpoints - List endpoints (paginated)
  • GET /integrations/{integration_id}/endpoints/{endpoint_name} - Get an endpoint
  • PATCH /integrations/{integration_id}/endpoints/{endpoint_name} - Update an endpoint
  • DELETE /integrations/{integration_id}/endpoints/{endpoint_name} - Delete an endpoint

  Endpoint names are immutable after creation. Adding, updating, or deleting endpoints updates the parent integration's updated_at timestamp.
• List endpoint no longer accepts protocol filter. The protocol query parameter has been removed from GET /integrations. The list endpoint now returns only REST integrations.

What you need to do:

• If you read the protocol field from integration responses: Replace references to protocol with kind. The value is rest for all integrations returned by the public API.
• If you read the builtin field from integration responses: Remove references to this field. It is no longer included in responses.
• If you filter by protocol on the list endpoint: Remove the protocol query parameter from your list requests. The endpoint now returns only REST integrations.
• If you pass an empty base_url on create: Provide a valid base URL. The field is now required and must be non-empty.
• If you delete and recreate integrations to change settings: Use the new PATCH /integrations/{integration_id} endpoint instead. This preserves the integration ID, endpoints, and associated secrets.
• If you recreate integrations to add or remove endpoints: Use the per-endpoint CRUD endpoints to manage endpoints individually without affecting the parent integration or other endpoints.

v0.9.232 - Platform API: Test Connection and Health Check Endpoints Removed (July 2026)

Test Connection and Health Check Endpoints Removed

The POST /integrations/{integration_id}/test-connection and GET /integrations/health-check endpoints have been removed from the Platform API. Integration health metadata fields have also been removed from integration responses.

What changed:

• Test connection endpoint removed. The POST /integrations/{integration_id}/test-connection endpoint has been removed. This endpoint previously probed an integration's auth resolution and upstream reachability without invoking a specific endpoint. Requests to this endpoint will return 404 Not Found.
• Health check endpoint removed. The GET /integrations/health-check endpoint has been removed. This endpoint previously returned a bulk health summary of all enabled integrations in a workspace. Requests to this endpoint will return 404 Not Found.
• Health metadata fields removed from integration responses. The last_tested_at and last_test_status fields have been removed from integration response objects. These fields previously reflected the most recent connection probe result. Integration list and get responses no longer include health metadata.
• Stored health metadata cleared. Previously persisted health metadata from connection probes has been removed from integration records. This is a data cleanup with no behavioral effect - the fields that surfaced this data have been removed from the API.

What you need to do:

• If you call POST /integrations/{integration_id}/test-connection: Remove these calls from your application. This endpoint no longer exists. Use the POST /integrations/{integration_id}/endpoints/{endpoint_name}/test endpoint to test specific integration endpoints instead.
• If you call GET /integrations/health-check: Remove these calls from your application. This endpoint no longer exists.
• If you read last_tested_at or last_test_status from integration responses: Remove references to these fields. They are no longer included in integration list or get responses.

v0.9.231 - Platform API: Integration Secrets Keyed by ID (July 2026)

Integration Secrets Keyed by ID

Integration auth secrets are now keyed by the integration's immutable ID rather than its user-supplied name. This means renaming an integration in a future release will not orphan its provisioned secrets.

What changed:

• Secret paths use integration ID. The platform now derives auth secret storage paths from the integration's stable UUID instead of its name. This is an internal change - callers never supply or see secret paths - but it affects the lifecycle guarantee: secrets are now permanently tied to the integration ID and cannot be orphaned by a name change.
• Integration ID assigned before secret provisioning. The integration ID is generated before any secrets are written, so the secret path and the database record always reference the same identifier. Previously, the ID was assigned at row insertion time, which could diverge from the path used during provisioning.

What you need to do:

• No action required for most users. Secret provisioning and resolution are fully managed by the platform. If you supply inline secret values (api_key_value, bearer_token_value, client_secret_value, private_key_value, exchange_secret_value) at creation time, they continue to work exactly as before.
• If you have integrations created before this release: Existing integrations created under the previous name-based scheme will be migrated automatically. No manual intervention is needed.

v0.9.230 - Platform API: Integration Secret Management Simplified, Update Endpoint Removed (July 2026)

Integration Secret Management Simplified, Update Endpoint Removed

Integration secret paths are now computed deterministically by the platform. The PUT update endpoint for integrations has been removed. Built-in integrations are no longer returned by the API - all integrations are workspace-scoped.

What changed:

• Update integration endpoint removed. The PUT /integrations/{integration_id} endpoint has been removed. Integrations can no longer be updated in place. To change an integration's configuration, delete and recreate it. This simplifies the integration lifecycle and eliminates edge cases around secret rotation during partial updates.
• Secret paths are now deterministic. Integration auth secrets are stored at platform-computed paths derived from the workspace, integration ID, and auth type. Callers no longer supply secret storage paths - the platform computes them automatically. The ssm_param_path, token_ssm_param_path, client_secret_ssm_param_path, private_key_ssm_param_path, and exchange_secret_ssm_param_path fields have been removed from the AuthConfig model. Inline secret values (api_key_value, bearer_token_value, client_secret_value, private_key_value, exchange_secret_value) remain the only way to supply secrets at creation time.
• Built-in integrations removed from API responses. List and get endpoints no longer include platform-defined built-in integrations (Google Maps, Google Search, Stedi, athenahealth). All integrations returned by the API are workspace-scoped rows created through the standard create flow. If your application filtered on the builtin field, those entries will no longer appear.
• Built-in integrations no longer block delete/update. Previously, attempting to delete or update a built-in integration returned 403 Forbidden. Since built-ins are no longer returned, this guard is removed. All integrations returned by the API can be deleted by their owner.

What you need to do:

• If you use PUT /integrations/{integration_id}: This endpoint no longer exists. To modify an integration, delete the existing one and create a new one with the updated configuration. Requests to the old endpoint will return 405 Method Not Allowed.
• If you supply *_ssm_param_path fields in AuthConfig: Remove these fields from your request bodies. The platform now rejects unknown fields on the auth config with 422 Unprocessable Entity. Supply secrets using the inline *_value fields only.
• If you depend on built-in integrations in list responses: Built-in integrations are no longer returned. If your application relied on built-ins appearing in GET /integrations, you will need to create workspace-scoped equivalents through the standard create flow.
• If you filter on the builtin field: This field will always be false for all returned integrations. You can remove any client-side filtering logic based on this field.

v0.9.229 - Platform API: List Endpoints Search by ID and Default Sort by Updated Date (July 2026)

List Endpoints Search by ID and Default Sort by Updated Date

List endpoints for agents, skills, services, integrations, and context graphs now support searching by ID and default to sorting by last updated date (newest first).

What changed:

• Search by ID. The search parameter on list endpoints for agents, skills, services, integrations, and context graphs now matches against the resource ID in addition to the previously supported fields (name, description, slug, display name). This makes it easier to locate a specific resource when you have a partial or full ID.
• Default sort changed to last updated. List endpoints for agents, skills, services, integrations, and context graphs now return results sorted by last updated date (newest first) by default. Previously, some endpoints defaulted to sorting by creation date or name. The sort parameter continues to work as before if you need a different ordering.

What you need to do:

• If you rely on default list ordering: Be aware that results now appear in last-updated order by default. If your application depends on a specific sort order, pass the sort parameter explicitly.
• If you search for resources by ID: You can now paste a full or partial ID into the search parameter and it will match. No API changes are needed to use this - existing search calls will also match IDs automatically.
• No breaking changes. All existing query parameters and response shapes are unchanged.

v0.9.228 - Platform API: Simulation Case Management and Suites Endpoint (July 2026)

Simulation Case Management and Suites Endpoint

Simulation cases now support update, delete, and total count operations. A new suites listing endpoint returns all discoverable suites derived from suite:* case tags.

What changed:

• Update simulation cases. PATCH /simulations/cases/{case_id} partially updates editable fields on a durable simulation case. Updatable fields include service assignment, persona, description, scenario instructions, initial message, temperament, fixtures, constraints, target specification, assertions, tags, and provenance. At least one field must be provided. Reserved tag prefixes are validated on update. Returns the updated case, or 404 if the case does not exist. Requires Service.update permission.
• Delete simulation cases. DELETE /simulations/cases/{case_id} removes a simulation case. Returns 204 on success, or 404 if the case does not exist. Requires Service.update permission.
• List simulation suites. GET /simulations/suites returns all suites discovered from cases tagged with the suite: prefix. Each suite includes a human-readable name derived from the tag, the number of matching cases, distinct service IDs, and the most recent update timestamp. Suites are dynamic - they are derived from case tags rather than requiring explicit registration.
• Case list includes total count. The GET /simulations/cases endpoint now includes a total count in paginated responses, so clients can render pagination controls without issuing a separate count request.

What you need to do:

• If you manage simulation cases programmatically: You can now update and delete individual cases through the API. Use PATCH for partial updates and DELETE for removal.
• If you organize cases into suites: The new GET /simulations/suites endpoint provides suite discovery without needing to list and group cases client-side.
• If you paginate case listings: The total field is now available in the list response to support accurate pagination UI.
• No breaking changes. All existing endpoints continue to work as before. The new endpoints and fields are additive.

v0.9.227 - Platform API: Voice Sentiment Metric Removed (July 2026)

Voice Sentiment Metric Removed

The built-in voice_sentiment metric has been removed from the platform. This metric had zero active readers and is no longer computed or available in metric results.

What changed:

• voice_sentiment metric removed. The built-in voice sentiment metric is no longer included in the default metric definitions. It will no longer appear in metric query results, workspace metric settings, or the MCP server's available metrics list.
• Extraction mode simplified. The ai_sentiment extraction mode has been removed from the metric definition model. The supported extraction modes are now: static, ai_classify, ai_extract, ai_query, and sql_expr.
• Custom metric validation updated. The validation error message for unsupported extraction modes on custom metrics now lists static, ai_query, ai_classify, and ai_extract as the allowed modes.
• Built-in metric count reduced. The platform now ships 40 built-in metrics (previously 41).

What you need to do:

• If you query voice_sentiment in dashboards or integrations: Remove references to this metric key. Queries for voice_sentiment will return no results.
• If you use the ai_sentiment extraction mode in custom metric definitions: Migrate to ai_classify with appropriate labels, or use ai_query with a prompt that performs sentiment analysis. The ai_sentiment mode is no longer recognized.
• If you reference voice sentiment in MCP tool calls: Update your queries to use other available voice metrics such as voice_quality_score, voice_escalation, or voice_completion_reason.
• No data migration required. Historical metric values that were previously computed are unaffected, but no new values will be generated.

v0.9.226 - Platform API: Barge-In Events Preserved Individually in Call Intelligence (July 2026)

Barge-In Events Preserved Individually in Call Intelligence

Call intelligence now preserves individual barge-in event details instead of recording only an aggregate count. Each barge-in event includes the text that was interrupted and the timestamp of the interruption.

What changed:

• Individual barge-in events in conversation summary. The conversation summary section of call intelligence now includes a barge_in_events array alongside the existing barge_in_count field. Each entry contains interrupted_text (the agent utterance that was interrupted) and timestamp (ISO 8601 timestamp of the interruption, or null if unavailable).
• Aggregate count still present. The barge_in_count field continues to be populated and reflects the length of the barge_in_events array, so existing consumers that rely on the count are unaffected.

What you need to do:

• If you consume call intelligence data: You can now access per-event barge-in details in the conversation summary. The barge_in_count field remains unchanged, so no migration is required.
• No breaking changes. The barge_in_events array is additive. Existing integrations that read call intelligence data continue to work without modification.

v0.9.225 - Platform API: Call List Now Includes Intelligence-Only Calls (July 2026)

Call List Now Includes Intelligence-Only Calls

The call list endpoint now surfaces calls that have call intelligence data but no associated conversation record. Previously, the call list was driven exclusively by conversation records, so calls that were processed through the analytics pipeline but did not create a conversation were not visible in the list.

What changed:

• Unified call list. The call list is now built from a unified view that joins call intelligence records with conversation records. Calls that exist only in call intelligence - for example, calls ingested from external sources or processed through analytics without following the standard conversation lifecycle - now appear alongside traditional conversation-based calls.
• Field resolution across sources. Fields such as direction, duration, turn count, quality score, completion reason, final state, and source are resolved from whichever source has the most complete data. Call intelligence values take precedence where both sources provide a value, except for status and completion reason where conversation data takes precedence.
• Detail endpoint supports intelligence-only calls. Retrieving detail for a call that exists only as a call intelligence record returns all available metadata and scoring fields with an empty turns array, rather than returning a not-found error.
• No changes to filtering. Existing filters (status, direction, service, date range) continue to work. Status filtering considers the resolved status from both sources.

What you need to do:

• If you consume the call list endpoint: You may see additional calls that were not previously visible. These calls have an id derived from the call intelligence record rather than a conversation ID. All other fields follow the same schema.
• If you rely on the call_intelligence_batch_reader callback pattern (internal integrations): This callback has been removed. Intelligence data is now resolved directly in the list query. No action is needed if you use the public API.
• No breaking changes to response schema. The response shape is unchanged. New calls include the same fields as conversation-based calls, with null values for conversation-specific fields (such as caller_id and phone_number) when no conversation record exists.

v0.9.224 - Platform API: Integration Auth Rejects Platform-Managed SSM Paths Without Inline Secrets (July 2026)

Integration Auth Rejects Platform-Managed SSM Paths Without Inline Secrets

The platform now rejects integration auth configurations that reference a platform-managed SSM path without providing the corresponding inline secret value. Previously, it was possible to copy a platform-managed SSM path from an API response (or another integration) into a create or update request without supplying the actual secret material. This would create an integration that appeared configured but could not authenticate, because the path was auto-generated and the secret was not actually provisioned for the new integration.

What changed:

• Platform-managed SSM paths require inline secrets. When creating or updating an integration, if an auth field (such as api_key_value, bearer_token_value, client_secret_value, private_key_value, or exchange_secret_value) references a platform-managed SSM path but does not include the inline secret value, the API returns a validation error. The error message indicates which field is affected and instructs you to pass the secret value directly.
• External SSM paths are unaffected. If you manage your own SSM paths outside the platform, those paths continue to be accepted without an inline secret value.
• Inline secret values work as before. Passing the actual secret value directly (e.g. api_key_value, bearer_token_value) continues to work. The platform auto-provisions the secret to SSM and returns the managed path in the response.

What you need to do:

• If you copy SSM paths from API responses into new integration requests: Stop copying the ssm_param_path, token_ssm_param_path, client_secret_ssm_param_path, private_key_ssm_param_path, or exchange_secret_ssm_param_path values from responses. Instead, pass the original secret value in the inline field and let the platform provision it automatically.
• If you use external (self-managed) SSM paths: No changes needed. External paths are accepted as before.

v0.9.223 - Platform API: Dynamic Simulation Suite Tags (July 2026)

Dynamic Simulation Suite Tags

Suite tags in the simulation framework are now fully dynamic. Previously, suite tags had to be pre-registered alongside capability and agent-type tags. Now, any tag with the suite: prefix is accepted as a valid suite tag without prior registration. This makes it easier to create and iterate on test suites - just tag your cases with a new suite: value and it becomes a runnable suite immediately.

What changed:

• Suite tags are no longer validated against a fixed registry. Any suite:* tag is accepted on simulation cases. You can define new suites by tagging cases without updating a central registry.
• Capability and agent-type tags are still validated. Tags with the capability: and agent_type: prefixes continue to be validated against known values. Unrecognized capability or agent-type tags are still rejected to prevent typos from silently excluding cases from benchmarks and rollups.

What you need to do:

• No action is required. Existing suite: tags continue to work. You can now create new suites by applying any suite:* tag to your simulation cases.

v0.9.222 - Platform API: Conversation Turn Data Moved to Session Store, Call Analysis and Enrichment Fields Removed from API Responses (July 2026)

Conversation Turn Data Moved to Session Store

Per-turn conversation data is now served exclusively from the session store. The platform no longer reads turn data from the previous analytical table. This completes the migration to the session-based turn storage announced in earlier releases.

What changed:

• Turn data served from session store only. Call detail and conversation detail endpoints now resolve turns exclusively from the session store. If the session store is unavailable, the response includes all conversation metadata and scoring fields with an empty turns array, rather than falling back to the previous analytical table. This matches the existing behavior documented for historical calls whose turn data was not preserved in current stores.
• Historical calls unaffected. Calls whose turns were already in the session store continue to work identically. Calls whose turn data existed only in the previous analytical table will return an empty turns array in the detail response. All metadata, scoring, and summary fields remain available.

Call Analysis and Enrichment Fields Removed from API Responses

Several enrichment fields have been removed from call and conversation API responses. These fields were populated from analytical processing that has moved to the downstream analytics pipeline and are no longer written or returned by the platform API.

What changed:

• call_analysis removed from call detail responses. The call_analysis object (containing outcome classification, transport close details, and post-call analysis) is no longer included in call detail API responses. If you consumed this field, use the analytics pipeline or metric store for equivalent data.
• emotional_summary removed from call detail responses. The emotional_summary object is no longer included in call detail API responses.
• forwarding removed from call detail responses. The forwarding object is no longer included in call detail API responses.
• participants, states_visited, barge_in_events, and config removed from call detail responses. These enrichment arrays and objects are no longer included in call detail API responses.
• escalation_status field type relaxed. The escalation_status field on call summary and operator escalation responses is now a free-form string (max 64 characters) instead of a fixed set of values. Existing status values continue to work. Client code that validated against a strict set of allowed values should be updated to accept any string.

What you need to do:

• If you read call_analysis, emotional_summary, forwarding, participants, states_visited, barge_in_events, or config from call detail responses: These fields are no longer returned. Equivalent data is available through the analytics pipeline and metric store.
• If you validate escalation_status against a fixed set of values: Update your validation to accept any string up to 64 characters.
• If you depend on turn data for historical calls: Turns are now served exclusively from the session store. Historical calls that predate session store adoption will return an empty turns array with all other metadata intact.

v0.9.221 - Platform API: Endpoint-Level Overrides Removed, Google Maps Integration Split (July 2026)

Endpoint-Level Overrides Removed from Integrations

The base_url and auth fields on individual integration endpoints have been removed. All endpoints in an integration now inherit the integration-level base URL and auth configuration. This simplifies the integration model and removes ambiguity about which auth and URL apply to a given endpoint.

What changed:

• base_url removed from endpoint configuration. Individual endpoints no longer accept a base_url override. The integration-level base_url is used for all endpoints. If you previously used per-endpoint base URL overrides, split those endpoints into separate integrations with their own base URLs.
• auth removed from endpoint configuration. Individual endpoints no longer accept an auth override. The integration-level auth configuration is used for all endpoints. If you previously used per-endpoint auth overrides, split those endpoints into separate integrations with their own auth configurations.

Google Maps Built-in Integration Split into Two Integrations

The single google_maps built-in integration has been replaced by two separate built-in integrations: google_maps_places and google_maps_routes. This change reflects the removal of per-endpoint base URL overrides - the Places API and Routes API live at different hosts and now require separate integrations.

What changed:

• google_maps integration replaced. The google_maps built-in integration no longer exists. It has been replaced by google_maps_places (Places API endpoints) and google_maps_routes (Routes API endpoints including directions).
• google_maps_places integration. Contains all place search, geocoding, and place detail endpoints. Display name: "Google Maps - Places".
• google_maps_routes integration. Contains the directions endpoint. Display name: "Google Maps - Routes".
• Same authentication. Both integrations use the same API key authentication and the same GOOGLE_MAPS_API_KEY environment variable. No credential changes are needed.

What you need to do:

• If you use per-endpoint base_url or auth overrides: Split those endpoints into separate integrations, each with its own integration-level base URL and auth configuration. These fields are no longer accepted on endpoint objects.
• If you reference google_maps by name: Update references to use either google_maps_places or google_maps_routes depending on which endpoints you use. The google_maps integration name is no longer valid.
• If you use the directions endpoint: This endpoint has moved from google_maps to google_maps_routes. Update any code that looks up the directions tool by integration name.

v0.9.220 - Platform API: Text Interact Turn Persistence Failures Now Surface Explicitly (July 2026)

Text Interact Turn Persistence Failures Now Surface Explicitly

The text interact endpoint now returns explicit error responses when turn persistence fails, instead of returning a silent success.

What changed:

• Non-streaming text interact returns 502 on persistence failure. If the agent generates a response but the platform fails to persist the conversation turn, the endpoint now returns a 502 Bad Gateway with a message indicating that conversation history may be incomplete. Previously, this scenario returned a 200 OK, which masked the data loss.
• Streaming text interact emits an error event on persistence failure. If turn persistence fails during a streaming interaction, the stream now emits an SSE error event with a message indicating that conversation history may be incomplete. Previously, the stream closed silently without signaling the failure.
• Voice session persistence failures logged at error severity. Voice session sync failures are now logged at error severity instead of warning severity, improving observability for persistence issues across all channels.

What you need to do:

If you consume the text interact endpoint, update your error handling to account for 502 responses (non-streaming) or error SSE events (streaming) that indicate persistence failures. These responses mean the agent's reply was generated and delivered, but the turn may not appear in conversation history. You may want to retry the interaction or notify the user that the conversation state could be stale.

v0.9.219 - Platform API: SMART Backend Services Auth Type Removed from Integrations (July 2026)

SMART Backend Services Auth Type Removed from Integrations

The smart_backend_services authentication type has been removed from the integrations framework. This auth flow is now handled by the connector runner service. Integrations that previously used SMART Backend Services auth should migrate to use the connector runner for SMART-authenticated connections.

What changed:

• smart_backend_services auth type removed. The smart_backend_services option is no longer accepted in the integration auth configuration type field. The supported auth types are now: api_key_header, bearer_token, oauth2_client_credentials, json_token_exchange, oauth2_jwt_bearer, and bearer_token_exchange.
• assertion_algorithm field removed. The assertion_algorithm field on the auth configuration model has been removed. This field was only used with the smart_backend_services auth type.
• assertion_kid field removed. The assertion_kid field on the auth configuration model has been removed. This field was only used with the smart_backend_services auth type.

What you need to do:

If you have integrations configured with smart_backend_services auth, migrate them to use the connector runner for SMART Backend Services authentication. The connector runner now owns this auth flow end-to-end. Contact support if you need guidance on migrating specific integrations.

v0.9.218 - Platform API: GCP WIF Auth Type Removed from Integrations (July 2026)

GCP WIF Auth Type Removed from Integrations

The gcp_wif authentication type has been removed from the integrations framework. Integrations that previously used GCP Workload Identity Federation auth should migrate to an alternative auth type.

What changed:

• gcp_wif auth type removed. The gcp_wif option is no longer accepted in the integration auth configuration type field. The supported auth types are now: api_key_header, bearer_token, oauth2_client_credentials, json_token_exchange, oauth2_jwt_bearer, smart_backend_services, and bearer_token_exchange.
• gcp_scopes field removed. The gcp_scopes field on the auth configuration model has been removed. This field was only used with the gcp_wif auth type.

What you need to do:

If you have integrations configured with gcp_wif auth, update them to use one of the remaining supported auth types before your next deployment. The supported auth types are now: api_key_header, bearer_token, oauth2_client_credentials, json_token_exchange, oauth2_jwt_bearer, and bearer_token_exchange. Contact support if you need guidance on migrating specific integrations.

v0.9.217 - Platform API: Agent Harness Approval Flag Update (July 2026)

Agent Harness Approval Flag Update

The non-interactive agent harness backend now uses a single consolidated flag for bypassing approval prompts and sandbox restrictions, replacing the previous separate flags.

What changed:

• Consolidated approval and sandbox bypass. The non-interactive harness now passes a single combined flag to bypass both approval prompts and sandbox restrictions. Previously, these were configured as two separate flags (one for approval suppression and one for sandbox access). The new flag is functionally equivalent - agent behavior and execution results are unchanged.

What you need to do:

No action is required. This is an internal harness configuration change. Agent runs, audit events, and result formats are unaffected.

v0.9.216 - Platform API: Additional Agent Harness Backend (July 2026)

Additional Agent Harness Backend

The agent execution layer now supports a second harness backend for non-interactive batch execution, in addition to the existing interactive harness. The new harness can be selected per workspace and is fully integrated with the existing job scheduling and audit event pipeline.

What changed:

• New harness option. Workspaces can now configure a second agent harness backend. The harness selection is set through workspace environment configuration and applies to all agent runs dispatched from that workspace. The new backend operates in non-interactive mode with full sandbox access, producing the same audit event structure and result format as the existing harness.
• Audit events. Runs using the new harness emit audit events with harness-specific event types, following the same structure used by the existing harness. Each event carries a tool identifier, input summary, sequence number, and timestamp. The harness name is recorded on the run result so downstream systems can distinguish which backend produced the output.
• Model selection. The new harness respects the same agent model configuration used by the existing harness. When an agent model is specified in workspace settings, it is passed through to the harness backend automatically.
• Environment configuration. Two new optional environment variables control the API credentials for the new harness. These are only required when the new harness is selected and are ignored for workspaces using the existing harness.

What you need to do:

No changes are required for existing workspaces. To use the new harness backend, update your workspace agent harness configuration. If you consume audit events or run results, the harness_name field on the result now reflects which backend executed the run.

v0.9.191 - Platform API: Realtime Metric Store with Hot Values and Delta History (June 2026)

Realtime Metric Store with Hot Values and Delta History

The metric store now serves hot metric values from a low-latency cache and lands durable history through the event pipeline, replacing the previous batch-only read path. The metric catalog endpoint also returns additional fields that were previously internal-only.

What changed:

• Hot metric reads. Metric values are now written to a fast in-memory cache on every metric projection and served directly from that cache for dashboard and call detail queries. This eliminates the delay between metric computation and metric availability in the UI. Cached values expire automatically after a rolling window, so idle workspaces do not accumulate stale data.
• Automatic cache pruning for active workspaces. Workspaces with continuous metric writes now prune expired entries from the hot cache on each write cycle. Previously, per-entry expiration only applied when the entire cache key expired due to inactivity. Active workspaces whose cache key was continuously refreshed could accumulate unbounded stale entries. The pruning runs in batches to bound per-write overhead.
• Delta history pipeline. Durable metric history now flows through the event pipeline into the analytical store, replacing the previous direct-write path. This decouples metric durability from the API request path, improving write latency for metric projection calls.
• Expanded metric catalog fields. The metric catalog endpoint now returns source, custom_source_key, period_granularity, and latency_tier on each catalog entry. These fields were previously available only in workspace settings. The key field validation is also now explicit in the response schema (lowercase alphanumeric with underscores, 1-64 characters).
• Renamed product surface. The metric store is now referred to as the "Realtime Metric Store" throughout the API and dashboard surfaces, replacing the previous "Universal Metric Store" name. The default metrics overview dashboard title has been updated accordingly.

What you need to do:

No API changes are required. Metric values are now available with lower latency in dashboards and call detail views. If you consume the metric catalog endpoint, you can optionally use the new source, period_granularity, and latency_tier fields for filtering or display.

v0.9.205 - Platform API: Sync Status Moved to Real-Time Cache (June 2026)

Sync Status Moved to Real-Time Cache

Data source sync status fields are now served from a low-latency cache written by the connector sync engine, replacing the previous database-backed write path. This improves sync status freshness and removes a synchronous database write from the polling hot path.

What changed:

• Sync status served from cache. The last_sync_at, last_sync_status, and last_sync_event_count fields on data source responses are now read from the same real-time cache that the connector sync engine writes after each poll cycle. Previously, these fields were written to the durable store during each poll, adding latency to the sync path and occasionally lagging behind the actual connector state.
• No schema changes. The data source response shape is unchanged. The last_sync_at, last_sync_status, and last_sync_event_count fields continue to appear on all data source endpoints (get, list, status) with the same types and semantics. When no sync has occurred yet, last_sync_at and last_sync_status are null and last_sync_event_count is 0, matching previous behavior.
• Internal sync status endpoint removed. The internal POST /data-sources/sync-status endpoint has been removed. This was an internal endpoint used by the connector sync engine and was not part of the public API. The sync engine now writes status directly to the cache without an intermediate API call.
• Sync status no longer searchable. Data source search no longer matches against sync status values. Searches continue to match against name, ID, source type, and health status.
• Connector source list includes cache-backed sync fields. The connector source breakdown endpoint now reads sync status from the same cache, so sync timestamps and status values on connector analytics responses are consistent with the data source detail endpoints.

What you need to do:

No API changes are required. If you previously relied on searching data sources by sync status text (e.g., searching for "error" to find failed syncs), use the health status field or filter by is_active instead. All other data source queries and responses work as before with improved freshness.

v0.9.215 - Platform API: Customer Data Zone and Catalog Reference Updates (June 2026)

Customer Data Zone and Catalog Reference Updates

The Data-MCP SQL query tool, the fallback SQL query tool used by the agent runtime, and the research query service now recognize the customer data zone catalogs. Catalog references across all LLM tool prompts have been updated to use fully qualified names.

What changed:

• Customer data zone available in SQL queries. The read-only SQL query tools now accept queries against the customer data zone. These views use definer-rights access control and are automatically filtered to the caller's workspace, so queries return only data belonging to the authenticated workspace. Both production and staging catalogs are supported.
• Fully qualified catalog references. All SQL tool descriptions presented to the agent now use fully qualified three-part catalog references instead of abbreviated names. This eliminates ambiguity when the agent constructs queries and ensures correct catalog resolution across environments.
• Analytics catalog consolidation reflected in tool prompts. Tool descriptions now reference the consolidated analytics catalog for metrics, billing, memory, scheduling, and call trace data, replacing references to individual legacy catalogs that were retired in the May 2026 consolidation.

What you need to do:

No API changes are required. If you use Data-MCP or the agent's SQL query capabilities, the customer data zone is now queryable alongside existing catalogs. Queries against the customer data zone are workspace-scoped automatically - no manual filtering is needed.

v0.9.214 - Platform API: Call Intelligence Served from Session Artifacts (June 2026)

Call Intelligence Served from Session Artifacts

Call intelligence data on voice conversation endpoints is now resolved from the hot session cache first, with automatic fallback to the durable analytical store. This replaces the previous approach of joining against a dedicated database table on every read.

What changed:

• Tiered call intelligence resolution. Single-call detail and conversation list endpoints now read call intelligence artifacts (quality scores, completion reasons, duration, direction, analytics summaries) from the fast session cache. When cached data is unavailable - for example, after cache expiration or for older conversations - the platform falls back to the durable analytical store automatically. No intelligence data is lost during the transition.
• Batch intelligence lookups for conversation lists. The conversation list endpoint now resolves call intelligence for an entire page of results in a single batch lookup rather than issuing per-conversation queries. This reduces list endpoint latency, especially for pages with many voice conversations.
• Consistent intelligence fields. The quality_score, completion_reason, final_state, duration_seconds, direction, source, service_id, and all analytics summary fields (risk_summary, latency_summary, conversation_metrics, tool_summary, safety_summary, operator_summary) continue to appear on conversation detail and list responses with the same types and semantics. Field precedence is unchanged: conversation-level values take priority where present, with intelligence artifacts filling in supplementary data.
• Status and filter behavior. Conversation list status filters now evaluate against conversation header fields only, rather than joining intelligence data into the filter predicate. This makes total counts and pagination more predictable. The direction=playground filter continues to work but playground-originated conversations are no longer represented as voice conversation summaries.

What you need to do:

No API changes are required. Response shapes are unchanged. Conversation list and detail endpoints return the same fields with improved latency and consistency. If you filter conversations by status, results may differ slightly for edge cases where the intelligence record previously overrode the conversation header status.

v0.9.213 - Platform API: Generic Agent Harness Configuration (June 2026)

Generic Agent Harness Configuration

The platform now supports configuring which agent harness and model are used for agent task execution. Previously, the platform assumed a single hardcoded agent harness. You can now specify the harness type and model independently, enabling support for additional agent harness backends as they become available.

What changed:

• agent_harness configuration field. A new agent_harness field controls which agent harness backend is used for task execution. The default value is claude-code, preserving existing behavior for current deployments.
• agent_model configuration field. A new agent_model field specifies the model passed to the agent harness. This replaces the previous model configuration field and provides a harness-agnostic way to select models.
• Backward compatibility. Existing model configuration continues to work. If only the previous model field is set, the platform uses it as the agent model automatically. The new fields take precedence when both are specified.

What you need to do:

No immediate action is required. Existing configurations continue to work without changes. To use a different agent harness or model, set the new agent_harness and agent_model configuration fields in your environment. The previous model configuration field remains supported for backward compatibility.

v0.9.212 - Platform API: Outbound Calls Require workspace_id and service_id (June 2026)

Outbound Calls Require workspace_id and service_id

The outbound call endpoint now requires workspace_id and service_id on every request. These fields were previously optional strings and are now required UUID values.

What changed:

• workspace_id is required. The workspace_id field on the outbound call request body is now a required UUID. Previously it was an optional string that defaulted to null.
• service_id is required. The service_id field on the outbound call request body is now a required UUID. Previously it was an optional string that defaulted to null.
• Assignment always created. Outbound calls now always create a provisional assignment using the provided workspace and service identifiers. Previously, calls without workspace and service IDs skipped assignment creation silently.

What you need to do:

Update any outbound call integrations to include both workspace_id and service_id as valid UUIDs in every request. Requests that omit either field or provide non-UUID values will be rejected with a validation error.

v0.9.211 - Platform API: FHIR Protocol Coerced to REST (June 2026)

FHIR Protocol Coerced to REST

The FHIR integration protocol has been removed as a distinct protocol type. All existing FHIR integrations are automatically coerced to REST. FHIR integrations were already handled identically to REST integrations at runtime - this change removes the unnecessary distinction.

What changed:

• FHIR protocol removed. The protocol field on integrations no longer accepts fhir as a value. Valid values are now rest and desktop. Existing integrations that were previously configured as fhir have been migrated to rest automatically.
• Creatable protocol restricted to REST. The integration creation endpoint accepts only rest as the protocol value. The desktop protocol remains system-provisioned and cannot be created via the public API.
• No behavioral change. FHIR integrations were already using the same HTTP-based integration path as REST integrations, including auth resolution, endpoint configuration, result templates, and connection probes. This change reflects that existing behavior in the data model.

What you need to do:

No action is required. If you have existing FHIR integrations, they have been migrated to REST automatically. If you have automation that creates integrations with protocol: "fhir", update it to use protocol: "rest" instead.

v0.9.210 - Platform API: Open Query Write Boundary and Function Delete Cleanup (June 2026)

Open Query Write Boundary and Function Delete Cleanup

The open query tool (fn_query) now delegates read/write enforcement to the data warehouse permission layer instead of applying a client-side keyword blocklist. Deleting a Python or UDTF function now also removes the corresponding warehouse artifact.

What changed:

• Open query write boundary moved to warehouse permissions. The open query tool previously rejected SQL containing write keywords (INSERT, UPDATE, DELETE, MERGE, etc.) using a regex filter. This filter has been removed. Read/write enforcement is now handled by the warehouse permission layer - the agent's service identity has read access to the production catalog and full access only to the sandbox schema. Write statements against non-sandbox surfaces are denied by the warehouse with a permission error. This eliminates false positives from the old regex (e.g., column names containing "update") and provides a single, consistent enforcement point.
• Open query tool description updated. The tool description presented to the agent now explains that writes succeed only against the sandbox schema and that the warehouse denies writes elsewhere. The previous "read-only" framing has been removed.
• LIMIT injection scoped to SELECT/WITH. The automatic LIMIT 100 safety cap is now applied only to SELECT and WITH (CTE) queries. Write statements (INSERT, UPDATE, DELETE, MERGE) are no longer modified with a trailing LIMIT, which would have caused a syntax error.
• Function delete removes warehouse artifact. Deleting a Python or UDTF function now drops the corresponding warehouse artifact before removing the registry row. The drop is idempotent - if the artifact is already gone (e.g., from a partial previous deploy), the delete still succeeds. If the warehouse is unavailable, the delete fails with a 503 error and the registry row is preserved so the operation can be retried. SQL and AI functions have no warehouse artifact, so their delete behavior is unchanged.

What you need to do:

No API changes are required. If you previously relied on the open query tool rejecting write keywords, note that write enforcement is now handled by warehouse permissions. Writes against the sandbox schema will now succeed through fn_query; writes against other schemas will return a permission error from the warehouse rather than a client-side validation error. Function deletes for Python and UDTF types are now fully clean - no orphan warehouse artifacts are left behind.

v0.9.208 - Platform API: Simulation Branch Isolation Removed (June 2026)

Simulation Branch Isolation Removed

The simulation API no longer supports database branch-based write isolation. Simulation sessions now write through the standard event pipeline with source tagging, and downstream consumers filter non-production sources automatically.

What changed:

• branch_name field removed from session creation. The branch_name parameter on the create simulation session endpoint has been removed. Requests that previously included branch_name should omit it. The field is no longer accepted.
• Branch management endpoints removed. The POST /simulations/branches, GET /simulations/branches, and DELETE /simulations/branches/{branch_name} endpoints have been removed. Branch lifecycle management is no longer part of the simulation API.
• Simulation write isolation simplified. Simulation sessions continue to tag all writes with a simulation source, ensuring that simulation data is excluded from production sync, outbound EHR writes, gap detection, and billing. The tagging mechanism is unchanged - only the underlying isolation strategy has been simplified.
• No changes to simulation session behavior. Creating sessions, stepping through conversations, forking sessions, and scoring all work exactly as before. The only difference is that branch_name is no longer a parameter and branch endpoints no longer exist.

What you need to do:

Remove any branch_name fields from simulation session creation requests. Remove any calls to the branch management endpoints (POST /simulations/branches, GET /simulations/branches, DELETE /simulations/branches/{branch_name}). No other changes are required - simulation sessions continue to be isolated from production data through source tagging.

v0.9.207 - Platform API: Enum Drift Fixes for Conversations, Metrics, Review Queue, and Channels (June 2026)

Enum Drift Fixes for Conversations, Metrics, Review Queue, and Channels

Several API surfaces now accept a wider set of valid values, fixing 500 errors caused by enum mismatches between stored data and API response schemas.

What changed:

• SMS channel type added. The channel type enumeration now includes sms as a valid value. Surfaces and conversations using SMS channels are now correctly represented in API responses.
• Review queue completed action values expanded. The completed_action field on review queue items now accepts both verb and past-tense forms: approve, reject, correct, approved, rejected, and corrected. Previously, only the past-tense forms were accepted, which caused errors when items stored with verb-form values were returned through the API.
• Voice conversation status handling hardened. Voice conversation status resolution now maps unexpected status values to valid statuses instead of passing unrecognized values through. Conversations with statuses outside the expected set are mapped to a safe default, preventing serialization errors in conversation list and detail responses.
• Categorical metric grouping simplified. Dashboard metric queries for categorical metrics now group by category value only, removing a dependency on a legacy grouping field. This fixes errors when the legacy field is absent from metric records.

What you need to do:

No API changes are required. These fixes resolve intermittent 500 errors on conversation, review queue, metric, and channel endpoints. If you previously encountered server errors when listing or viewing conversations, review items, or dashboard metrics, those errors should now be resolved.

v0.9.206 - Platform API: Call Intelligence Artifact Contract Centralized (June 2026)

Call Intelligence Artifact Contract Centralized

The terminal call intelligence artifact - the payload emitted when a call or text session ends - now uses a single, validated contract across all channels and the metric projection endpoint. This replaces the previous pattern where each channel assembled its own payload dictionary with ad-hoc field sets.

What changed:

• Strict artifact validation. The terminal call intelligence artifact is now validated against a single schema before it is emitted or projected. Missing required fields, out-of-range scores, and unknown extra fields are rejected at build time rather than silently stored. This applies to voice calls, text sessions, and simulation sessions equally.
• Invalid direction and source values are now rejected. Previously, unrecognized call direction values fell back to "inbound" and unrecognized source values were silently dropped. Both fields now reject invalid values with an error. If you were relying on the fallback behavior for non-standard direction or source values, those calls will now fail to emit call intelligence until the values are corrected.
• Workspace ID included in the artifact. The artifact now carries the workspace identifier as a required field. The metric projection endpoint validates that the workspace in the artifact matches the workspace in the request path, returning a 422 error on mismatch.
• Metric projection accepts the shared artifact schema. The internal metric projection endpoint now accepts the same artifact schema used by the event pipeline. The previous endpoint-specific request model has been replaced by the shared contract. All fields, types, and constraints are identical.
• Improved error handling for call intelligence persistence. When the event pipeline emits successfully but the hot cache write fails, the platform now distinguishes between the two failure modes. Metric projection proceeds if the durable event was emitted, even when the cache write fails. Previously, any persistence failure would skip metric projection entirely.
• Playground calls excluded from metrics. Calls originating from the Developer Console playground are now explicitly excluded from metric projection. Previously, playground calls could be projected as production metrics depending on how the source value was interpreted.

What you need to do:

No API changes are required for standard integrations. If you consume call intelligence events downstream, the payload shape is unchanged - the same fields are present with the same types. If you were sending non-standard direction or source values through a custom integration, those values must now match the canonical set (direction: "inbound" or "outbound"; source: "real", "simulation", or "playground").

v0.9.204 - Platform API: Call Intelligence Enum Normalization (June 2026)

Call Intelligence Enum Normalization

Call intelligence data now normalizes call direction and call source values at write time, eliminating inconsistencies caused by legacy data or mismatched labels.

What changed:

• Direction and source normalization at write time. Call intelligence events now normalize direction and source values before they are stored. Historical aliases and legacy labels are mapped to their canonical equivalents automatically. For example, calls that were previously recorded with inconsistent direction labels now resolve to the correct canonical value. Unrecognized direction values fall back to "inbound" to satisfy storage constraints; unrecognized source values are dropped rather than stored with an incorrect label.
• Shared normalization across read and write paths. Both the call intelligence writer and the call listing read path now use the same normalization logic. Previously, the read path maintained its own alias mapping. This change ensures that direction and source values are consistent regardless of whether you are viewing a call in the Developer Console, querying the API, or consuming analytics events.
• Legacy data cleanup. A data migration corrects historical rows that contained non-canonical direction or source values. Calls affected by the legacy labeling inconsistency will now display correct values in dashboards and API responses without any action required.
• Monitoring for drift. The platform now tracks normalization events so the team can verify that no new sources of inconsistent values appear. Once the migration has been active long enough to confirm zero drift, the legacy fallback paths will be removed.

What you need to do:

No API changes are required. If you previously filtered or grouped calls by direction or source and noticed inconsistent labels, those values are now normalized. Dashboards and analytics that aggregate by direction or source will produce more accurate results.

v0.9.203 - Platform API: Frozen Conversation Status Removed (June 2026)

Frozen Conversation Status Removed

The frozen conversation status has been removed from the platform. Text conversations now use only active and terminal statuses (closed, completed, failed). Runtime session ownership is managed through the hot session cache rather than a persisted lifecycle status.

What changed:

• frozen status removed. The frozen value is no longer returned in conversation status fields and is no longer accepted as a filter value when listing conversations. Conversations that would previously have been frozen now remain active in the durable store while releasing runtime resources through cache expiration.
• resumed session status removed. The session_status field on text session creation responses no longer returns resumed. The field now returns either created or already_active.
• reactivated field removed. The reactivated boolean field has been removed from conversation thread resolution and text session creation responses. Conversations no longer transition between frozen and active states.
• Simplified conversation lifecycle. Active conversations release runtime resources through automatic cache expiration rather than explicit freeze/thaw transitions. When a new message arrives for a conversation whose session has expired, a new runtime session is created transparently. The conversation's durable identity and history are preserved across session boundaries.

What you need to do:

• If you filter conversations by status=frozen, remove that filter. Active non-terminal conversations all have active status.
• If you check for session_status: "resumed" in text session responses, update your code to handle only created and already_active.
• If you read the reactivated field from conversation materialization or session responses, remove that dependency. The field is no longer present.

v0.9.202 - Platform API: MCP Integration Protocol Removed (June 2026)

MCP Integration Protocol Removed

The MCP (Model Context Protocol) integration protocol has been removed from the platform. Integrations now support rest, fhir, and desktop protocols only.

What changed:

• mcp protocol removed. The mcp protocol option is no longer accepted when creating or updating integrations. The protocol field now accepts rest, fhir, or desktop (where desktop remains system-provisioned only).
• MCP-specific fields removed. The mcp_transport, mcp_command, mcp_args, mcp_url, and mcp_headers fields have been removed from integration create, update, and response models. These fields are no longer accepted in requests or returned in responses.
• Connection test simplified. The test-connection endpoint no longer includes MCP-specific probe logic. Connection probes exercise auth resolution and send a HEAD request to base_url for REST/FHIR integrations.
• Creatable protocol set narrowed. The set of protocols available for user-created integrations is now rest and fhir. The desktop protocol continues to be system-provisioned only.

What you need to do:

• If you have integrations using the mcp protocol, migrate them to rest or fhir before updating. Existing MCP integrations will no longer be recognized by the platform.
• Remove any mcp_transport, mcp_command, mcp_args, mcp_url, or mcp_headers fields from your integration create and update requests.

v0.9.201 - Platform API: Strict Context Graph Tool Reference Validation (June 2026)

Strict Context Graph Tool Reference Validation

Context graph version creation now validates every tool reference against deployed workspace resources. Previously, tool references were checked against skill slugs and built-in tool IDs but did not verify that referenced platform functions or workspace data queries actually existed. This change catches misconfigured context graphs before they reach production.

What changed:

• Platform function references validated at deploy time. Tool references using the fn_ prefix (e.g. fn_check_eligibility) are now verified against the workspace's deployed platform functions. If a referenced function does not exist, the context graph version creation request is rejected with a validation error listing the unresolved references.
• Workspace data query references validated at deploy time. Tool references using the wsq_ prefix (e.g. wsq_recent_appointments) are now verified against the workspace's deployed workspace data queries. Missing queries cause the same validation rejection.
• Skill references validated against enabled skills. Skill-based tool references continue to be validated against the workspace's skill registry, and now require the skill to be enabled. Disabled skills cause a validation error.
• Built-in legacy functions removed. Five previously built-in function tools (fn_entity_confidence, fn_caller_history, fn_patient_summary, fn_patient_memory_snapshot, fn_patient_dimension_summary) have been removed from the platform. These functions are no longer auto-registered for every workspace. If your agent uses any of these, deploy equivalent platform functions in your workspace before updating your context graph. The open query (fn_query) and write (fn_write) tools remain available as built-in tools.

What you need to do:

• If your context graphs reference fn_entity_confidence, fn_caller_history, fn_patient_summary, fn_patient_memory_snapshot, or fn_patient_dimension_summary, deploy these as platform functions in your workspace before creating new context graph versions. Existing deployed context graph versions continue to work, but new versions referencing these tools will fail validation.
• Ensure all fn_* and wsq_* tool references in your context graphs correspond to deployed platform functions or workspace data queries in the same workspace.
• Review any disabled skills referenced by context graphs - they must be enabled to pass validation.

v0.9.200 - Platform API: Call Intelligence Migrated to Session Store and Event Pipeline (June 2026)

Call Intelligence Migrated to Session Store and Event Pipeline

Call intelligence data now flows through the session store and event pipeline instead of being written directly to the analytical database. This change improves write latency for call intelligence, makes intelligence data available immediately after a call ends, and unifies the data path for voice, text, and simulation sessions.

What changed:

• Session store is the primary call intelligence store. Call intelligence summaries are now written to the fast session cache and emitted through the durable event pipeline, replacing the previous direct database write. Intelligence data is available for API reads immediately after the call ends, without waiting for analytical pipeline ingestion.
• Metric projection receives the full artifact. The internal metric projection endpoint now receives the complete call intelligence artifact directly from the agent engine, instead of reading it back from the database after a write. This eliminates a read-after-write dependency and removes the previous 404 response when the database row had not yet been committed. The projection endpoint no longer returns a not-found status.
• Unified intelligence path for all session types. Voice calls, text sessions, and simulation sessions all emit call intelligence through the same session store boundary. Previously, each session type used a slightly different write path. The unified path ensures consistent data shape, timing, and event semantics across all channels.
• Call intelligence reads from session store. The call intelligence detail endpoint now reads from the session store hot cache instead of querying the analytical database. This provides lower-latency reads and consistent data availability across all session types.
• Simulation intelligence simplified. Simulation sessions no longer write intelligence data to the analytical database directly. Intelligence flows through the session store and event pipeline, then metric projection is requested through the standard platform API path. This matches the production call intelligence flow.

What you need to do:

No API changes are required. The call intelligence response shape is unchanged. If you consume call intelligence data through the API, you may notice improved availability - intelligence data appears immediately after a call ends rather than after analytical pipeline processing.

v0.9.199 - Platform API: Text Conversation Turns from Session Logs (June 2026)

Text Conversation Turns from Session Logs

Text conversation detail now reads turn data from the session log pipeline instead of inline conversation state. This aligns text conversations with the same turn resolution path used by voice conversations, providing consistent turn data across both channels.

What changed:

• Turn resolution from session logs. The text conversation detail endpoint now reads turn history from the session store (hot path) with automatic fallback to the durable analytical store for historical conversations. Previously, text conversation turns were read from inline conversation state. This change means text conversations benefit from the same turn resolution pipeline that voice conversations already use.
• Consistent turn format. Text and voice conversation detail responses now produce turns through the same rendering logic. Turn structure, timestamp formatting, and role mapping are identical across both channels.
• Improved error handling. Turn read failures now return a 502 status with a descriptive error message ("Conversation turns unavailable" or "Conversation turns invalid") instead of failing silently or returning malformed data. Transient session store read failures are handled gracefully - the endpoint falls back to the durable store rather than returning an error.

What you need to do:

No API changes are required. The conversation detail response shape is unchanged. If you consume text conversation turns, you may notice improved turn availability for historical conversations that previously returned empty or incomplete turn data.

v0.9.198 - Platform API: Parallel Tool Registration During Session Initialization (June 2026)

Parallel Tool Registration During Session Initialization

Session initialization now registers workspace tools and data warehouse functions concurrently using a structured task group, replacing the previous sequential-then-deferred approach. This reduces session startup latency and simplifies error handling.

What changed:

• Concurrent tool registration. Workspace tool registration and data warehouse function registration now run fully in parallel during session initialization. Previously, one registration path ran in the foreground while the other was deferred to a background task. Both paths now complete before the session proceeds, ensuring all tools are available to the agent from the first interaction.
• Consistent error handling. Both registration paths now use the same non-fatal error handling. If either registration fails, the failure is logged as a warning and the session continues without those tools. Previously, the two paths used different error handling strategies, which could produce inconsistent behavior when one path failed.
• Tool snapshot consistency. Because both registration paths complete before the session's tool list is finalized, all registered tools are guaranteed to be visible to the agent immediately. Previously, deferred registration could complete after the tool list snapshot was taken, causing some tools to be silently unavailable until the next session.

What you need to do:

No API changes are required. Sessions will initialize faster and all registered tools will be consistently available from the first turn. If you previously observed intermittent tool availability at session start, this change resolves that behavior.

v0.9.197 - Platform API: Fail-Fast Text Session Routing (June 2026)

Fail-Fast Text Session Routing

Text session routing and conversation directory operations now use strict fail-fast error handling. Previously, cache unavailability was silently absorbed and routing fell back to alternate lookup paths or returned empty results. Now, infrastructure errors propagate immediately so operators see one clear failure mode instead of silent behavior changes.

What changed:

• Cache is a required dependency. Text session management and conversation routing now require the hot-path cache at initialization. Passing a missing or null cache reference raises an error at startup rather than being silently accepted.
• No silent fallback on cache errors. Cache read and write errors (connection failures, timeouts) now propagate to the caller instead of being suppressed. Previously, errors were caught and the system returned empty results or skipped writes. This could mask infrastructure problems and cause sessions to silently stop routing. Errors are now surfaced so monitoring and alerting can catch them.
• Consent lookup errors propagate. SMS consent cache lookups and writes follow the same fail-fast pattern. Infrastructure errors are no longer absorbed - callers see the failure and can handle it explicitly.
• Deprecated compatibility wrapper removed. The legacy resolve_or_create conversation directory method has been removed. Callers should use the epoch-aware resolution method, which provides correct actor-epoch state for reactivated conversations.
• Improved diagnostics for session engine cursor errors. When session load cursors are incoherent, the error now includes the specific cursor values and emits a metric, making diagnosis faster.

What you need to do:

No API changes are required. If you operate self-hosted infrastructure, ensure the active-session cache is healthy and monitored. Cache unavailability will now surface as explicit errors rather than degraded routing behavior. If you were using the deprecated resolve_or_create conversation directory method through internal tooling, migrate to the epoch-aware resolution method.

v0.9.196 - Platform API: Simplified Metrics Hot Path (June 2026)

Simplified Metrics Hot Path

The metrics pipeline has been simplified by removing the per-entity metric cache from the session store. Metric values now flow exclusively through the event pipeline and the realtime metric store, reducing write overhead on the session hot path.

What changed:

• Per-entity metric caching removed from the session store. The session store no longer maintains a separate per-entity metric cache. Previously, per-entity metrics were written to both the session-level cache and the event pipeline. Now, metric values are written only to the event pipeline and served from the realtime metric store. This reduces per-session write volume and simplifies the data flow.
• Session store scope narrowed. The session store now handles conversation turns and call intelligence data only. Metric storage and retrieval are handled entirely by the realtime metric store, which was introduced in v0.9.191.

What you need to do:

No API changes are required. If you consume metrics through dashboards, call detail views, or the metric catalog endpoint, behavior is unchanged - metrics continue to be available with the same low latency provided by the realtime metric store. The only difference is internal: the redundant session-level metric cache has been removed.

v0.9.195 - Platform API: Realtime Call Intelligence Metrics for Text Sessions (June 2026)

Realtime Call Intelligence Metrics for Text Sessions

Text sessions now project call intelligence metrics in realtime when a session ends, matching the behavior already in place for voice calls.

What changed:

• Realtime metric projection for text sessions. When a text session completes, the platform now projects a terminal call intelligence row through the same realtime projection path used by voice calls. This means text session quality scores, conversation analytics, and custom metrics appear in dashboards and call detail views with the same low latency as voice call metrics. Previously, text session metrics relied on a separate path that could delay visibility.
• Projection is best-effort. Metric projection for text sessions is secondary to the committed source data. If projection fails, the source call intelligence row is unaffected and metrics will be available once the analytical pipeline catches up. A failed projection does not cause the text session cleanup to fail.

What you need to do:

No API changes are required. Text session metrics now appear in dashboards and analytics with the same timeliness as voice call metrics. If you consume call intelligence data for text sessions, you may notice that metric values are available sooner after session completion.

v0.9.194 - Platform API: Resilient Call List Normalization (June 2026)

Resilient Call List Normalization

The call list endpoint now normalizes call direction and call source values before returning results, preventing unexpected values from causing errors in the response.

What changed:

• Call direction normalization. Call direction values are now validated and normalized before inclusion in call list responses. Legacy or non-standard direction values are mapped to their canonical equivalents where a known alias exists. Unrecognized values are omitted rather than causing a server error.
• Call source normalization. Call source values in the call list now pass through the same normalization already applied elsewhere in the API. Previously, raw values were returned directly, which could include non-standard entries. Unrecognized source values are now omitted from the response.

What you need to do:

No API changes are required. Call list responses now return consistent, validated values for direction and source fields. If you previously encountered errors when listing calls with unexpected direction or source values, those calls will now appear with normalized values or with those fields set to null.

v0.9.193 - Platform API: Deterministic Event Pipeline and Strict Session Journal Validation (June 2026)

Deterministic Event Pipeline and Strict Session Journal Validation

The session persistence engine now enforces strict journal metadata on all entries, emits deterministic event identifiers for downstream idempotency, and removes the request-path durable store fallback.

What changed:

• Deterministic event identifiers. Turn and call intelligence events emitted to the analytics pipeline now carry stable, deterministic identifiers derived from each entry's journal position. If a retry re-emits the same event, downstream consumers deduplicate automatically. This makes the emission path at-least-once without risk of duplicate analytical records.
• Flush-before-cache ordering. The event pipeline now confirms delivery before writing to the active-session cache. Previously, a cache write could succeed while the durable event delivery silently failed, leaving a gap in the analytical store. Flush failures now propagate to the caller so the synced cursor is not advanced prematurely.
• Strict journal metadata validation. Session entries loaded from the active-session cache must carry canonical journal metadata - a journal kind, schema version, and index. Entries missing any of these fields are rejected at load time instead of being silently accepted with a fallback index. This eliminates an ambiguous migration-window code path where entries without journal metadata could produce inconsistent replay ordering.
• Durable store replay removed from request path. The session engine no longer falls back to the analytical data store when the active-session cache is empty. Historical replay and bulk backfill are handled by offline data repair jobs and analytical projections, keeping per-request latency predictable. The session engine constructor no longer accepts optional data-store or replay parameters.
• Unified turn-session identity for text and audio turns. Text and audio turn endpoints now derive session identifiers, cache keys, and conversation identifiers through a shared identity module. The derivation logic is unchanged - existing sessions continue without interruption - but the consolidation removes duplicated validation across the two endpoints.
• Conversation detail read path simplified. The voice conversation detail endpoint no longer queries the analytical data store as a fallback when turn data is absent from the active-session cache. If turns are expected but not found, the response includes available metadata with an empty turns array and emits an observability breadcrumb. This matches the behavior already documented for historical calls in v0.9.192.

What you need to do:

No API changes are required. Session persistence, event emission, and conversation detail responses use the same schemas as before. The changes affect internal reliability and consistency guarantees:

• Retry-safe event emission means analytics pipelines no longer need custom deduplication logic for turn and call intelligence events.
• Calls where turn data has expired from the active-session cache now consistently return an empty turns array in the detail response, rather than attempting a slow fallback query.

v0.9.192 - Platform API: Listed Call Entity Fallback for Call Detail (June 2026)

Listed Call Entity Fallback for Call Detail

The call detail endpoint now resolves detail for all calls shown in the call list, even when turn-level data is not available in durable stores.

What changed:

• Listed entity fallback. When a call appears in the call list but has no durable turn-level record (for example, older simulation or playground calls that predate the current session storage pipeline), the call detail endpoint now returns a minimal detail response built from the call's metadata and intelligence data. Previously, these calls returned a 404 from the detail endpoint despite being visible in the list. The response includes all available scalar fields (status, duration, direction, quality score, summaries, recording information) with an empty turns array.
• Consistent list-to-detail resolution. Every call returned by the call list endpoint is now guaranteed to resolve through the call detail endpoint. This eliminates the inconsistency where some listed calls - particularly historical simulation and playground entries - could not be inspected.
• Graceful degradation. If the metadata lookup encounters a transient error, the endpoint falls through to the existing 404 response rather than returning a 500. This keeps the fallback path safe for callers that retry on not-found responses.

What you need to do:

No API changes are required. Call detail responses use the same schema as before. Calls that previously returned 404 despite appearing in the call list will now return a valid detail response. The turns array will be empty for calls where turn-level data was not preserved, and recording information will be included when available.

v0.9.190 - Platform API: Simplified Call Detail Source Resolution (June 2026)

Simplified Call Detail Source Resolution

The call detail endpoint now uses a simplified resolution path that removes redundant fallback layers and resolves call data from fewer, more predictable sources.

What changed:

• Simplified source chain. Call detail resolution now follows a shorter, deterministic path: the primary voice service, then durable conversation storage, then simulation records. Previously, the endpoint checked additional intermediate stores that duplicated data already available through the durable path. Removing these redundant layers reduces per-request latency and eliminates edge cases where stale intermediate data could shadow more complete records.
• Legacy turn store removed. Historical conversation turns stored in an older per-turn format are no longer queried. Turn data is now served exclusively from the hot session cache or the durable session log. Calls that predate both stores may return without turn-level detail. This change has no effect on calls created after the session log pipeline was enabled.
• Consistent detail dependencies. All call and conversation detail endpoints now share a single set of read-path dependencies initialized at startup, rather than constructing them per request. This ensures consistent behavior across the call detail, conversation detail, and turn-backfill paths.
• Simulation calls resolved independently. Simulation session detail is now treated as a distinct source rather than a fallback in the real-call chain. If a call identifier matches a simulation session, it is resolved directly without first attempting voice or durable lookups. This avoids unnecessary queries for identifiers that were never real calls.

What you need to do:

No API changes are required. Call detail responses have the same schema and fields as before. If you have calls from before the durable session log was enabled, those calls may return without conversation turns - this was already the case for most of these calls in practice.

v0.9.189 - Platform API: Fail-Fast Startup Validation for Hot-Path Dependencies (June 2026)

Fail-Fast Startup Validation for Hot-Path Dependencies

The platform now validates all critical runtime dependencies at startup and refuses to serve traffic if any required dependency is unavailable. This applies to both the Platform API and the Connector Runner.

What changed:

• Startup connection verification. Services that depend on a fast session cache now verify connectivity at startup with a bounded timeout. If the cache is unreachable, the service fails immediately with a clear error instead of starting and silently dropping writes or returning degraded responses during live conversations.
• Required event pipeline validation. In deployed environments, services that emit world events now validate that the event pipeline is fully configured at startup. If the event pipeline endpoint or target is missing, the service refuses to start. This prevents silent data loss where events would be dropped because the pipeline was partially configured.
• Conversation directory cache lookup. The conversation resolution path now checks the active-session cache before querying the durable store. When a conversation is found in the cache and is active, the system refreshes its time-to-live and returns immediately without hitting the database. This reduces per-message latency on the hot path for active conversations.

What you need to do:

No API changes are required. These are infrastructure-level reliability improvements. Services will now fail loudly at startup if dependencies are misconfigured, rather than degrading silently at runtime. If you manage your own deployment configuration, ensure that all required environment parameters for the session cache and event pipeline are set before deploying.

v0.9.188 - Platform API: Text Session Latency and Error Handling Improvements (June 2026)

Text Session Latency and Error Handling Improvements

Text sessions now load conversation history exclusively from the fast cache on the live interaction path, and the text interact endpoint returns clearer error responses when agent processing fails.

What changed:

• Cache-only session loading on the live path. Text session turns no longer fall back to the durable analytics store when the fast cache is empty. The durable store query could add significant latency to individual turn requests. Live sessions now load from the fast cache only, keeping per-turn response times predictable. Durable store replay remains available for offline recovery and batch scenarios where latency constraints are relaxed.
• Turn count in text interact response. The text interact response now includes a turn_count field reflecting how many turns have been completed in the session. The conversation turn count is reconciled between the session engine and the upstream response, using the higher value to ensure accuracy.
• Explicit error responses. The text interact endpoint now returns structured HTTP error responses instead of silently producing empty results. Agent timeouts return a 504 (Gateway Timeout), agent processing failures return a 502 (Bad Gateway), and sessions where the agent produces no response also return a 502 with a descriptive message. Previously, some of these failure modes could result in a successful response with an empty message list.
• Deferred terminal artifacts for text sessions. Conversation summaries and call intelligence data are now written only when a text session is finalized, not after every turn. Active turns still sync session state incrementally, but analytical artifacts are terminal - writing them mid-conversation was both slow and semantically incorrect. This reduces per-turn processing overhead.
• Post-call metric projection authentication. The post-call metric projection pipeline now supports agent-scoped authentication tokens in addition to service account tokens. This allows metric projection to proceed using the session's existing credentials when available, reducing the need to mint additional service tokens.
• Cleanup ordering for agent sessions. Agent session credentials are now revoked after all post-call processing is complete, rather than at the start of cleanup. This ensures that workspace-scoped cleanup operations (such as metric projection) can use the session's credentials through their completion.

What you need to do:

No API changes are required. Clients that consume the text interact response can optionally read the new turn_count field. Clients that previously treated empty message lists as a soft failure should be aware that these cases now return explicit HTTP errors (502 or 504). The response schema is otherwise unchanged.

v0.9.187 - Platform API: Restored Call Detail Turns from Durable Storage (June 2026)

Restored Call Detail Turns from Durable Storage

The call detail endpoint now recovers conversation turns from durable storage when the primary source returns a valid call record but its turn data has expired.

What changed:

• Turn backfill from durable storage. When the call detail endpoint returns a call record that has metadata (status, duration, participants) but no conversation turns, the platform now checks durable conversation storage for turn data. If turns are found, they are merged into the call detail response. This addresses cases where short-lived caches expire before the call detail is requested, which previously resulted in structurally valid responses with empty turn lists.
• Additional fallback for fully missing calls. Calls that are not found in the primary call store are now also looked up in durable conversation storage before falling back to the entity-only projection. This expands the window during which call details with full turn history remain available.
• Conversation lookup by entity ID. When a call cannot be found by its call identifier in conversation storage, the platform now resolves the underlying call reference from the entity store and retries the conversation lookup. This handles cases where the call was recorded under a telephony-assigned identifier that differs from the entity ID used in the API.

What you need to do:

No API changes are required. The call detail endpoint returns the same response shape. Calls that previously returned empty turn lists may now return full conversation history. This is a backward-compatible improvement - clients that already handle turns will display richer data automatically.

v0.9.186 - Platform API: Metrics Pipeline Ordering and Transport Resilience (June 2026)

Metrics Pipeline Ordering and Transport Resilience

The realtime metrics pipeline now uses improved ordering rules when resolving duplicate metric values, and the event transport handles additional failure modes gracefully.

What changed:

• Improved metric value ordering. When multiple metric value events arrive for the same metric, the pipeline now considers the metric's effective period as a secondary ordering signal after the computed timestamp. This ensures that a recomputed metric for a newer period takes precedence over an older-period retry, even if the retry arrived later. Previously, only the computed timestamp and arrival time were used for ordering.
• Deterministic tiebreaker for retries. The final tiebreaker for metric value deduplication now uses ascending event identity order instead of descending. This produces stable, repeatable results during replay without relying on event identity as a freshness signal. The change only affects the rare case where all other ordering signals are identical.
• Transport error handling. The event transport now catches timeout and connection failures during flush and converts them into structured send errors. Previously, these failure types could propagate as unhandled exceptions. Other unexpected errors still propagate normally. This is a fail-closed design - callers receive an explicit error rather than a silent retry.
• Workspace-scoped query validation. Query validation for workspace-scoped analytical queries now uses stricter pattern matching to prevent false matches against similarly named catalog paths. This reduces the risk of an unscoped query accidentally bypassing workspace isolation.

What you need to do:

No API changes are required. Metric values are resolved using the same endpoints and response shapes. The ordering improvement may change which value is selected as the latest in rare cases where duplicate events with identical computed timestamps existed. Transport error handling changes are internal to the event pipeline and do not affect API callers.

v0.9.185 - Platform API: Canonical Session Replay for Text Sessions (June 2026)

Canonical Session Replay for Text Sessions

The session engine now replays text session history from a canonical journal projection, replacing the previous row-order-based fallback. Returning text sessions load interaction history from a cleaned, indexed projection that guarantees deterministic replay order regardless of how historical data was originally ingested.

What changed:

• Journal-indexed replay. Each interaction log entry now carries a stable journal index that defines its absolute position in the session timeline. When a returning session is loaded from the durable store, entries are ordered by journal index rather than ingestion timestamp. This eliminates rare ordering inconsistencies that could occur when entries shared identical timestamps.
• Canonical projection filtering. The durable store query now filters to only return entries that carry canonical journal metadata. Legacy entries without journal metadata are excluded from cold replay unless they have been explicitly migrated through a backfill process. This ensures the session engine always receives well-structured, typed entries.
• Replay limit. Cold session replay is now capped at a defensive upper bound to prevent unbounded query results for abnormally large sessions. Normal text sessions are orders of magnitude smaller than this limit. If the limit is reached, the engine logs a warning and continues with the available entries.