> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/api-reference/change-logs/web-platform/web-platform-history-03.md).

# Web Platform History: Archive 3

Retained Web Platform history, archive 3, with original entry headings and links back to current integration guidance.

Historical entries retain their original release/source context. Use [Current Upgrade Guidance](/api-reference/change-logs/upgrade-guide.md) for current integration boundaries and [Web Platform](/api-reference/change-logs/web-platform.md) for the recent history and archive index. An older entry does not establish current availability.

<details>

<summary>v2.199.0 - Developer Console: Honest Raw-Transcript Fallback for Voice Conversation Detail (July 2026)</summary>

#### Honest Raw-Transcript Fallback for Voice Conversation Detail <a href="#honest-raw-transcript-fallback-for-voice-conversation-detail" id="honest-raw-transcript-fallback-for-voice-conversation-detail"></a>

The voice conversation detail page now detects when per-turn transcripts are unavailable and displays the raw recognized transcript honestly instead of rendering a single misleading system message.

**What changed:**

* **Raw-transcript fallback detection.** When a voice call's turn-by-turn log was not retained (the live session expired and no durable per-turn record was found), the platform previously displayed a single system message containing the entire recognized transcript. This appeared as one chat bubble labeled "System" even when the call had many turns, which was misleading. The detail page now detects this condition and renders a dedicated notice instead.
* **Transcript notice panel.** When the fallback is detected, the page shows a notice explaining that per-turn transcripts are unavailable, states how many turns the call actually had, and displays the raw recognized transcript in a clearly labeled block. If no transcript was recorded, the panel indicates that as well.
* **No change to normal calls.** Calls with full per-turn transcripts continue to render the standard turn-by-turn conversation view.

**What you need to do:**

* **No action required.** The fallback detection and notice are automatic. No configuration changes or new permissions are needed.

</details>

<details>

<summary>v2.198.0 - Developer Console: World-Model Lens on Conversation Detail (July 2026)</summary>

#### World-Model Lens on Conversation Detail <a href="#world-model-lens-on-conversation-detail" id="world-model-lens-on-conversation-detail"></a>

The conversation detail page now includes a world-model interaction panel and framework attribution, giving operators an aggregate view of how the agent read and wrote against the world model during a conversation.

**What changed:**

* **World-model interaction panel.** The text conversation detail view now shows a dedicated panel summarizing the conversation's world-model activity: total reads and writes, which tools were used for each, the anchor entity, and any failed tool calls. This is an aggregate view across all turns - the transcript still shows tool calls turn by turn.
* **Capabilities and write-floor panel.** Alongside the interaction summary, a second panel displays the harness capabilities and enforced write floor for the bound service, including the available read and write tools and the clinical write principal. If no service is bound to the conversation, the panel indicates that capabilities cannot be resolved.
* **Framework attribution badge.** Each conversation now displays a framework badge on the detail page header, identifying which runtime produced the conversation. All conversations through the standard conversation path are attributed to the context-graph framework.

**What you need to do:**

* **No action required.** The new panels appear automatically on the text conversation detail page. No configuration changes or new permissions are needed.

</details>

<details>

<summary>v2.197.0 - Developer Console: Unified Runs Surface (July 2026)</summary>

#### Unified Runs Surface <a href="#unified-runs-surface" id="unified-runs-surface"></a>

The Developer Console now has a unified Runs page that brings text conversations, voice calls, and framework runs into a single surface with tabbed navigation. This replaces the separate Conversations and Agent Trace sidebar entries with one "Runs" entry under Operations.

**What changed:**

* **New Runs page.** A new page at `/{workspace}/runs` provides a tabbed view of all agent runs. The Text conversations tab is available to all users and shows the same conversations table previously found under the standalone Conversations page. The Voice calls and Framework runs tabs are visible to Amigo staff only (matching the previous Agent Trace visibility gate).
* **Sidebar updated.** The Operations section now leads with "Runs" instead of separate "Conversations" and "Agent Trace" entries. The Runs entry highlights when you are on the Runs page, the Conversations page, or the Agent Trace page, so existing bookmarks and deep links continue to work.
* **Agent Trace still accessible.** The Agent Trace page remains at its existing URL and continues to show the voice call review list. It is no longer a separate sidebar entry - voice call review is accessed through the Voice calls tab on the Runs page instead.
* **Framework runs placeholder.** The Framework runs tab displays a placeholder indicating that framework runs from partner SDKs are not yet listed in this surface. Individual runs remain inspectable through the API and the Framework Runs panel under Evaluation.

**What you need to do:**

* **No action required.** All existing URLs continue to work. The Conversations page and Agent Trace page are still accessible at their original paths. The sidebar navigation has been consolidated, but no functionality has been removed.

</details>

<details>

<summary>v2.196.0 - Developer Console: Unified Testing Under Evaluation + Voice Library Moved to Tools (July 2026)</summary>

#### Unified Testing Under Evaluation + Voice Library Moved to Tools <a href="#unified-testing-under-evaluation--voice-library-moved-to-tools" id="unified-testing-under-evaluation--voice-library-moved-to-tools"></a>

The Developer Console sidebar has been reorganized so all testing and evaluation surfaces live under a single Evaluation section, and the Voice Library has moved from the Agents section to the Tools section.

**What changed:**

* **Playground moved to Evaluation.** The Playground now lives under the Evaluation section (subtitled "Try, test, and measure agent quality") rather than Operations. This gives "where do I test my agent?" a single answer - the Playground, simulations, case libraries, and quality metrics are all grouped together.
* **Operations updated.** The Operations section (subtitled "Watch live and past runs") now leads with Runs (the unified run surface that replaced the separate Conversations and Agent Trace entries). Playground is no longer listed here.
* **Voice Library moved to Tools.** The Voice Library has moved from the Agents section to the Tools section (subtitled "Capabilities agents use - tools, skills, integrations, voices"). Voice assets are capabilities that agents use, so they sit alongside tools, skills, and integrations.

**What you need to do:**

* **No action required.** This is a navigation reorganization only. All pages remain at the same URLs. No workflows, API interactions, or functionality have changed - only the sidebar grouping has been updated.

</details>

<details>

<summary>v2.195.0 - Developer Console: Plain-Language Section Descriptions in Sidebar (July 2026)</summary>

#### Plain-Language Section Descriptions in Sidebar <a href="#plain-language-section-descriptions-in-sidebar" id="plain-language-section-descriptions-in-sidebar"></a>

The Developer Console sidebar now displays a short, plain-language subtitle beneath each navigation section header, so a new enterprise admin can understand the purpose of each section at a glance without needing to learn platform-specific terminology.

**What changed:**

* **Section descriptions added.** Every top-level navigation group in the sidebar now shows a one-line description beneath its title. For example, the Agents section reads "Build agents on any framework," the Tools section reads "Capabilities agents use - tools, skills, integrations, voices," and the Evaluation section reads "Try, test, and measure agent quality."
* **Hidden when collapsed.** When the sidebar is collapsed to icon-only mode, the descriptions are hidden along with the section titles, keeping the compact view uncluttered.
* **All sections covered.** Descriptions are provided for Home, Agents, Tools, World Model, Operations, Deployment, Evaluation, Engagement, Data, Governance, Sensorium, Workspace, Admin, and Conversations (operator view).

**What you need to do:**

* **No action required.** This is a display-only enhancement to the sidebar navigation. No URLs, workflows, or API interactions have changed.

</details>

<details>

<summary>v2.194.0 - Developer Console: Per-Service World Model and Capabilities Panel (July 2026)</summary>

#### Per-Service World Model and Capabilities Panel <a href="#per-service-world-model-and-capabilities-panel" id="per-service-world-model-and-capabilities-panel"></a>

The agent detail page now includes a World Model & Capabilities panel that shows the tools and world-model scope an agent binds to when deployed in a given service. Because tool bindings in the Amigo Agent Framework are service-scoped, the panel lets you select one of the agent's referencing services and inspect its harness context.

**What changed:**

* **New World Model & Capabilities card.** The agent detail page now displays an expandable card below the version list. When the agent is deployed in at least one service, the card shows the harness context for the selected service - read tools, write tools, clinical write principal, clinical scope, and enforcement point.
* **Service selector.** A dropdown at the top of the card lets you switch between services that reference the agent. The panel fetches the harness context for the selected service and updates the displayed tools and write-floor information.
* **Empty state guidance.** If the agent is not deployed in any service, the card displays a message explaining that tools bind per service and that deploying the agent in a service will populate this panel.

**What you need to do:**

* **No action required.** This is a display-only enhancement to the existing agent detail page. No URLs, workflows, or API interactions have changed.

</details>

<details>

<summary>v2.193.0 - Developer Console: Framework Badge on Service Detail (July 2026)</summary>

#### Framework Badge on Service Detail <a href="#framework-badge-on-service-detail" id="framework-badge-on-service-detail"></a>

The Service detail page now displays the framework of the bound agent directly in the Linked Resources card, so you can see which framework powers the service without navigating to the agent detail page.

**What changed:**

* **Framework badge in Linked Resources.** The Service detail page now includes a Framework row in the Linked Resources card, showing a branded framework badge for the agent bound to the service. This surfaces the same framework information available on the agent detail and unified agents list, but in the context of the service that deploys it.

**What you need to do:**

* **No action required.** This is a display-only enhancement to the existing Service detail page. No URLs, workflows, or API interactions have changed.

</details>

<details>

<summary>v2.192.0 - Developer Console: Agent Detail Redesign Phase 2 - Framework Badge and Capabilities (July 2026)</summary>

#### Agent Detail Redesign Phase 2 - Framework Badge and Capabilities <a href="#agent-detail-redesign-phase-2-framework-badge-and-capabilities" id="agent-detail-redesign-phase-2-framework-badge-and-capabilities"></a>

The agent detail pages now surface framework information and native capabilities directly, closing two visibility gaps in the agent detail experience.

**What changed:**

* **Framework badge on platform agent detail.** The agent sidebar now displays the framework badge for platform agents, so the authoring framework is visible without navigating back to the agent list.
* **Capabilities card on native agent definition detail.** The definition detail page now includes a Capabilities section that displays the world tools allowed by the definition's latest version. If the definition has no versions yet, the card indicates that capabilities are defined per version. If the latest version allows no world tools, the card states that explicitly.
* **Version-level capability resolution.** Capabilities are fetched from the latest version of the definition, reflecting the fact that allowed world tools are authored per version for native definitions.

**What you need to do:**

* **No action required.** These are display-only enhancements to existing detail pages. No URLs, workflows, or API interactions have changed.

</details>

<details>

<summary>v2.191.0 - Developer Console: Unified Agents List (July 2026)</summary>

#### Unified Agents List <a href="#unified-agents-list" id="unified-agents-list"></a>

The Agents page now shows a single, unified list of agents across all four supported frameworks - Amigo Agent Framework, OpenAI SDK, Anthropic SDK, and OpenAI Realtime - replacing the previous split between the Agents list and the separate Native Agents registry page.

**What changed:**

* **Unified agent table.** The Agents page now merges platform agents and native (bring-your-own-framework) agent definitions into a single table. Each row displays the agent's framework (with branded badge), name, status, and last-updated time. Clicking a row navigates to the appropriate detail page based on the agent's framework.
* **Framework filter.** A new framework dropdown above the table lets you filter agents by framework (All frameworks, Amigo Agent Framework, OpenAI SDK, Anthropic SDK, OpenAI Realtime). Client-side search by name or ID is also available.
* **New Agent button with framework picker.** A "New Agent" button opens a dialog where you choose which framework to author on. Each option shows the framework badge and a short description of the authoring path, then routes you to the corresponding authoring surface (Context Graphs for Amigo Agent Framework, Native Agents registry for OpenAI SDK and Anthropic SDK, Services for OpenAI Realtime).
* **Native Agents sidebar item removed.** The separate "Native Agents" navigation item has been removed from the sidebar. Native agent definitions are now accessed through the unified Agents list. The agent-definitions detail route is still reachable by clicking a native agent row, and the sidebar keeps the Agents item active when viewing a native definition detail page.
* **Updated page description.** The Agents page description now reflects the multi-framework scope: "Agents across every framework - Amigo Agent Framework, OpenAI SDK, Anthropic SDK, and OpenAI Realtime."
* **Agent definition detail improvements.** The definition detail page now includes a copy button next to the definition ID and uses improved typography for the empty-versions state. The back button label has been simplified from "Back to Native Agents" to "Back to Agents."
* **Truncation indicator.** When the number of agents from any single source exceeds the display limit, a note appears below the table indicating that results are capped and suggesting the framework filter or search to narrow results.

**What you need to do:**

* **No action required.** All existing pages remain at the same URLs. The Native Agents detail pages are still accessible; only the sidebar entry point and the list page have changed. If you had bookmarked the Native Agents list page, use the main Agents page instead and filter by framework.

</details>

<details>

<summary>v2.190.0 - Developer Console: Layered Navigation and Framework Branding (July 2026)</summary>

#### Layered Navigation and Framework Branding <a href="#layered-navigation-and-framework-branding" id="layered-navigation-and-framework-branding"></a>

The Developer Console sidebar navigation has been further refined to express a layered stack - Frameworks, Capabilities, World Model - and framework references throughout the console now display branded logos alongside their labels.

**What changed:**

* **Layered sidebar navigation.** The sidebar sections now express a three-layer stack that separates what agents are built on, what they can do, and what they act on:
  * **Agents** (Frameworks layer) - Author an agent on any of the four supported frameworks. Includes the agent list, Native Agents registry, Context Graphs, and Voice Library.
  * **Tools** (Capabilities layer) - What agents can do. Tools, Skills, and Integrations are consolidated here. Skills and Integrations are accessible via the Tools page tab bar and the command palette; the sidebar entry point is "Tools."
  * **World Model** (Substrate layer) - The durable state agents act on. Agent Memory and Entity Browser live here. Tools have moved up to the new Tools section.
  * **Operations** - Observe and operate what agents are doing, live and historical. Playground, Conversations, Trace, and Review live here. This section was previously named "Runs."
  * **Evaluation** - Test and measure agent quality. Simulations, case libraries, and related items live here. Previously named "Simulations."
  * **Engagement** - Proactive outreach and patient-facing surfaces. Previously named "Outbound."
  * **Governance** - Compliance posture and audit trail. Previously named "Reports."
* **Framework logos and branded labels.** Agent definitions, the definitions table, and run detail now display a framework logo alongside each framework name. The four supported frameworks display as "Amigo Agent Framework," "OpenAI SDK," "Anthropic SDK," and "OpenAI Realtime" with their respective brand marks. Previously, frameworks were shown as plain text badges.
* **Consistent framework label taxonomy.** Framework labels are now sourced from a single taxonomy across all console surfaces (agent definitions list, definition detail, run results). The labels "Claude Agent SDK" and "OpenAI Agents SDK" have been renamed to "Anthropic SDK" and "OpenAI SDK" respectively for consistency with the vendor brand names.
* **Integrations moved from Workspace to Tools.** The Integrations palette entry has moved from the Workspace section to the Tools section, reflecting its role as a capability rather than a workspace setting.

**What you need to do:**

* **No action required.** All existing pages remain at the same URLs. The changes affect sidebar navigation grouping, section names, and framework display formatting. No workflows or endpoints have changed.

</details>

<details>

<summary>v2.189.0 - Developer Console: Framework-Agnostic Navigation and Native Agents Registry (July 2026)</summary>

#### Framework-Agnostic Navigation and Native Agents Registry <a href="#framework-agnostic-navigation-and-native-agents-registry" id="framework-agnostic-navigation-and-native-agents-registry"></a>

The Developer Console sidebar navigation has been reorganized to reflect the framework-agnostic world-model architecture, and a new Native Agents registry page lets you browse and inspect bring-your-own-framework agent definitions.

**What changed:**

* **Reorganized sidebar navigation.** The sidebar sections now follow a framework-agnostic information architecture. The previous section ordering (Home, Agents, Conversations, Simulations, Outbound, Data, Reports, Workspace) has been replaced with a structure that separates authoring, world model, runs, and deployment concerns:
  * **Agents** - Author agents of any framework. Includes the agent list, the new Native Agents registry, Context Graphs, and Voice Library.
  * **World Model** - The substrate agents bind to. Tools, Agent Memory, and Entity Browser now live here (previously under Agents or Data).
  * **Runs** - What agents did, regardless of framework. Playground, Conversations, Trace, and Review live here. This section was previously named "Conversations."
  * **Deployment** - Binding an agent to channels. Services has moved here from the Agents section.
* **New Native Agents page.** A new "Native Agents" item in the Agents section opens a registry of bring-your-own-framework agent definitions (Claude Agent SDK, OpenAI Agents SDK). The list page shows each definition's name, framework, and status with infinite-scroll pagination. Clicking a definition opens a detail page showing the definition metadata, all immutable versions, and per-version details (agent count, write-tool indicator, validator revision, and body hash).
* **Agent Memory and Entity Browser moved to World Model.** These items previously appeared under the Data section. They now sit under World Model alongside Tools, reflecting their role as the world state that agents read and write.
* **Services moved to Deployment.** The Services item previously appeared under Agents. It now sits under Deployment, separating the concern of authoring an agent from deploying one.

**What you need to do:**

* **No action required.** All existing pages remain at the same URLs. The changes affect only sidebar navigation grouping and ordering. The new Native Agents pages are available automatically.

</details>

<details>

<summary>v2.188.0 - Developer Console: Framework Runs - Native Definition Runs and Actor Badges (July 2026)</summary>

#### Framework Runs - Native Definition Runs and Actor Badges <a href="#framework-runs-native-definition-runs-and-actor-badges" id="framework-runs-native-definition-runs-and-actor-badges"></a>

The Framework Runs panel on the service detail page now supports launching native agent definition runs and displays actor attribution badges on trajectory steps.

**What changed:**

* **Run source selector.** A new Source dropdown at the top of the Framework Runs form lets you choose between two run modes: "This service's agent" (the existing platform run path) and "Native definition (bring your own)" (a new native run path). Platform runs remain the default.
* **Native definition runs.** When you select the native source, the framework and version set fields are replaced by a free-form JSON editor where you paste your own agent definition document. The definition must include a `framework` field and conform to the platform's clamp schema. Invalid JSON is caught client-side before submission; server-side validation returns detailed errors for schema violations.
* **Actor badges on trajectory steps.** Each trajectory step now shows an actor badge when the step includes actor attribution. In multi-agent runs (handoff graphs, subagent delegations), this badge identifies which agent within the definition produced the step, making cross-agent trajectories easier to read.
* **SDK updated to 0.86.0.** The platform SDK dependency has been updated to 0.86.0, which includes the native run request shape and optional framework field.

**What you need to do:**

* **No action required.** The source selector, native config editor, and actor badges appear automatically on the Framework Runs panel. To try a native run, switch the source to "Native definition," paste a valid definition JSON, enter a message, and launch the run.

</details>

<details>

<summary>v2.187.0 - Developer Console: Framework Runs - Cache Token Usage and Two-Column Form Layout (July 2026)</summary>

#### Framework Runs - Cache Token Usage and Two-Column Form Layout <a href="#framework-runs-cache-token-usage-and-two-column-form-layout" id="framework-runs-cache-token-usage-and-two-column-form-layout"></a>

The Framework Runs panel on the service detail page now displays granular cache token usage and uses a more compact two-column form layout.

**What changed:**

* **Cache token usage in run results.** When a completed run includes cache-read or cache-write token counts, the token usage line now shows these alongside standard input and output counts (e.g., "Tokens: 150 in - 200 out - 1,000 cache read - 500 cache write"). Cache entries appear only when non-zero, so runs without caching remain compact.
* **Two-column form layout.** The Framework and Version Set fields now sit side by side on wider screens, matching the form layout conventions used elsewhere on the service page. The message field retains full width below.
* **SDK updated to 0.85.0.** The platform SDK dependency has been updated to 0.85.0, which includes the cache token fields in the run usage model.

**What you need to do:**

* **No action required.** The updated layout and cache token display appear automatically on the Framework Runs panel.

</details>

<details>

<summary>v2.186.0 - Developer Console: Framework Runs Panel on Service Detail Page (July 2026)</summary>

#### Framework Runs Panel on Service Detail Page <a href="#framework-runs-panel-on-service-detail-page" id="framework-runs-panel-on-service-detail-page"></a>

The service detail page in the Developer Console now includes a Framework Runs panel that lets you dispatch and monitor partner-framework agent runs directly from the console.

**What changed:**

* **New Framework Runs card.** A new card appears on the service detail page with a form to launch an agent run against an external framework. You select a framework (Claude Agent SDK or OpenAI Agents SDK), specify a version set (defaults to `release`), enter a user message, and click Launch Run.
* **Live run polling.** After dispatch, the panel polls the run status automatically. While the run is in progress, a spinner and status badge indicate the current state. Polling stops when the run reaches a terminal status (succeeded, failed, or timed out).
* **Run results inline.** When a run completes, the panel displays the outcome - status badge, framework label, duration, token usage (input and output), and the agent's final text for successful runs. Failed and timed-out runs show the error message.
* **Trajectory steps.** If the run produced trajectory steps, they are listed below the result with step kind badges and content previews, so you can see the sequence of actions the framework agent took.
* **Framework selection.** The framework dropdown lists the two supported frameworks with human-readable labels. The default selection is Claude Agent SDK.

**What you need to do:**

* **No action required.** The Framework Runs panel appears automatically on every service detail page. Select a framework, enter a message, and launch a run to test your service's agent configuration against an external framework.

</details>

<details>

<summary>v2.185.0 - Developer Console: Background Tools Fleet Capacity Widget on Active Calls Page (July 2026)</summary>

#### Background Tools Fleet Capacity Widget on Active Calls Page <a href="#background-tools-fleet-capacity-widget-on-active-calls-page" id="background-tools-fleet-capacity-widget-on-active-calls-page"></a>

The Active Calls page in the Developer Console now displays a second fleet capacity widget showing the isolated background-tool runner fleet alongside the existing voice fleet widget.

**What changed:**

* **Background Tools fleet widget.** A new fleet capacity strip labeled "Background Tools Fleet" appears below the existing Voice Fleet Capacity strip on the Active Calls page. It shows the same capacity metrics - ready, allocated, total, headroom - but scoped to the isolated fleet that executes background tool runs.
* **Distinct labels.** The allocated count on the background-tools widget is described as "running tools" rather than "live calls" to reflect what the fleet handles. The title reads "Background Tools Fleet" instead of "Voice Fleet Capacity."
* **Independent polling.** Each widget polls its fleet independently on the same interval, and the two widgets never share cached data, so the numbers always reflect the correct fleet.

**What you need to do:**

* **No action required.** The widget appears automatically on the Active Calls page. Operators monitoring fleet capacity now see both fleets at a glance.

</details>

<details>

<summary>v2.184.0 - Developer Console: Destinations Tab in Intake - Trigger Customer Data Materialization (July 2026)</summary>

#### Destinations Tab in Intake <a href="#destinations-tab-in-intake" id="destinations-tab-in-intake"></a>

The Intake tab under Data Sources now includes a Destinations segment that shows each dataset's materialized destination table and lets you trigger the customer data materializer directly from the console.

**What changed:**

* **New Destinations segment.** A fifth segment - Destinations - has been added to the Intake tab (alongside Uploads, Schemas, Sources, and Batches). It lists every registered dataset with its ingestion mode (snapshot or document), materialization status, row count, and last-materialized time.
* **Per-dataset materialization.** Each dataset row includes a Materialize button that triggers materialization for that single dataset. A toast notification confirms the run was started.
* **Materialize all curated.** A top-level "Materialize all curated" button triggers materialization for every curated dataset in the workspace in a single run.
* **Refresh.** A Refresh button reloads the destinations list so you can check for updated row counts and timestamps after a run completes.
* **Async feedback.** Materialization runs asynchronously. The UI indicates which dataset (or all datasets) is being materialized and disables additional triggers until the current request completes. Errors are surfaced in a toast notification.

**What you need to do:**

* **No action required.** The Destinations segment is available automatically. Navigate to Data Sources, open the Intake tab, and select the Destinations segment to view and trigger materialization.

</details>

<details>

<summary>v2.183.0 - Developer Console: Live Agent Messages After Deferred Tool Completion in Text Playground (July 2026)</summary>

#### Live Agent Messages After Deferred Tool Completion in Text Playground <a href="#live-agent-messages-after-deferred-tool-completion-in-text-playground" id="live-agent-messages-after-deferred-tool-completion-in-text-playground"></a>

When a deferred tool completes in the background and the agent produces a follow-up message outside the normal turn cycle, that message now appears live in the text playground conversation timeline - without waiting for the next user turn or a page refresh.

**What changed:**

* **Out-of-band agent messages rendered live.** After a deferred (background) tool completes, the agent may narrate a follow-up answer outside the synchronous turn cycle. Previously, this message only appeared after a page refresh or the next user turn. Now it appears in the conversation timeline as soon as the platform delivers it.
* **Workspace event stream subscription.** The playground subscribes to workspace-level agent message events alongside the existing background completion events. Messages belonging to a different conversation or arriving after the session ends are silently ignored.
* **Deduplication at render.** If the agent's out-of-band message echoes text already shown from a synchronous turn reply, the duplicate is suppressed at render time so messages are never shown twice.
* **On-turn refresh as catch-up.** The existing on-turn refresh path continues to serve as a catch-up mechanism, so no messages are lost even if the live event is missed.

**What you need to do:**

* **No action required.** The change is automatic. Deferred tool completions that trigger agent follow-up messages now surface immediately in the text playground.

</details>

<details>

<summary>v2.182.0 - Developer Console: Tool Dispatch Axes on Context Graph Bindings; Delivery Removed from Skill Editor (July 2026)</summary>

#### Tool Dispatch Axes on Context Graph Bindings <a href="#tool-dispatch-axes-on-context-graph-bindings" id="tool-dispatch-axes-on-context-graph-bindings"></a>

Tool bindings in the context graph editor now expose three orthogonal dispatch axes - Execution, Delivery, and Lifecycle - alongside the existing Result persistence selector. Delivery mode has been removed from the skill creation form because it is now authored per state-tool binding on the context graph.

**What changed:**

* **Three dispatch axes per tool binding.** Each tool attached to a context graph state now shows four selectors in a grid: Execution (Blocking or Background), Delivery (Interrupt or Queue), Lifecycle (Independent or Coupled), and Result (Accumulate or Override). These replace the previous single Result persistence dropdown.
* **Sensible defaults.** New tool bindings default to Blocking / Interrupt / Independent / Accumulate, which reproduces the historical inline behavior. Existing graphs that do not set these fields behave identically to before.
* **Background + Queue prevented.** Selecting Background execution automatically snaps Delivery back to Interrupt and disables the Queue option, because a backgrounded result that is queued would never reach the user.
* **Coupled lifecycle explanation.** Selecting Coupled lifecycle displays an inline note: if the conversation moves on before the tool finishes, its result is dropped instead of folded in. This applies to text channels only - voice keeps its own call-teardown rule.
* **Delivery removed from skill editor.** The Delivery dropdown (Interrupt / Queue) has been removed from the skill creation form. Delivery is now controlled per tool binding in the context graph, not on the skill itself.
* **Sparse storage.** Dispatch axes at their default values are omitted from the stored configuration, keeping stored context graph versions compact.

**What you need to do:**

* **No action required for existing graphs.** Defaults match the previous behavior. Existing tool bindings without explicit dispatch axis values continue to work as before.
* **Review skill templates.** If you relied on the skill-level Delivery setting, note that delivery is now configured per tool binding in the context graph editor.

</details>

<details>

<summary>v2.181.0 - Developer Console: Sortable "Uploaded at" Column in Intake Files List (July 2026)</summary>

#### Sortable "Uploaded at" Column in Intake Files List <a href="#sortable-uploaded-at-column-in-intake-files-list" id="sortable-uploaded-at-column-in-intake-files-list"></a>

The Files list in the Intake tab now lets you sort by upload time, so you can quickly find the most recent or oldest uploads.

**What changed:**

* **Sortable column header.** The "Uploaded at" column header is now a toggle button. Clicking it switches between newest-first and oldest-first sort order. A directional arrow on the header indicates the current sort direction.
* **Newest-first by default.** The Files list defaults to newest-first, so recently uploaded files and version bumps appear at the top.
* **Client-side sorting.** Sorting applies across the full file set loaded in the browser, so toggling the sort direction is instant and does not trigger a new data fetch.
* **No action required.** The change is automatic. The Files list now supports sort toggling without any configuration changes.

</details>

<details>

<summary>v2.180.0 - Developer Console: Graceful Handling of Large Folder Sync Timeouts in Intake (July 2026)</summary>

#### Graceful Handling of Large Folder Sync Timeouts in Intake <a href="#graceful-handling-of-large-folder-sync-timeouts-in-intake" id="graceful-handling-of-large-folder-sync-timeouts-in-intake"></a>

Syncing a large external drive source no longer shows a "Sync failed" error when the operation takes longer than the gateway allows. The sync continues in the background and the UI now tells you so.

**What changed:**

* **Informational toast instead of error.** When syncing a large drive source takes longer than the gateway timeout, the Developer Console now shows a "Sync still running" informational toast instead of a "Sync failed" error. The message explains that discovery is finishing in the background and suggests checking the Batches tab or refreshing shortly.
* **Batches list refreshed on timeout.** When a sync times out, the Batches list is automatically refreshed so the batch created server-side appears without requiring a manual page reload.
* **Genuine failures still surface as errors.** Actual sync failures - such as missing credentials, authorization errors, or missing sources - continue to show the "Sync failed" error toast as before. Only gateway timeouts are reclassified as informational.
* **No action required.** The change is automatic. Large drive source syncs that previously appeared to fail will now display accurate status without any configuration changes.

</details>

<details>

<summary>v2.179.0 - Developer Console: Live Background Tool Results in Text Playground (July 2026)</summary>

#### Live Background Tool Results in Text Playground <a href="#live-background-tool-results-in-text-playground" id="live-background-tool-results-in-text-playground"></a>

Background skill completions now appear in the text playground conversation timeline the instant they finish, without waiting for the next turn.

**What changed:**

* **Live delivery.** When a background skill completes during an active text playground session, the result is pushed into the conversation timeline immediately. Previously, background completions only appeared after the next turn was sent. The playground now subscribes to workspace-level completion events and renders each result as soon as it arrives.
* **Task-based correlation.** Each background completion is matched to its original dispatch by a stable task-based key. Completions that belong to a different conversation or arrive after the session has ended are silently dropped, so stale results never appear in the wrong session.
* **On-turn catch-up preserved.** The existing path that drains background completions on the next turn remains active as a catch-up mechanism. If a completion event is missed (for example, due to a brief network interruption), it is still picked up when the next turn is sent.
* **No action required.** The change is automatic. Background skills configured with background execution will show results live in the text playground without any configuration changes.

</details>

<details>

<summary>v2.178.0 - Developer Console: Fleet Capacity Widget Labeled as Platform-Wide (July 2026)</summary>

#### Fleet Capacity Widget Labeled as Platform-Wide <a href="#fleet-capacity-widget-labeled-as-platform-wide" id="fleet-capacity-widget-labeled-as-platform-wide"></a>

The Voice Fleet Capacity widget on the Active Calls page now clearly indicates that capacity counts span all workspaces, not just the current one.

**What changed:**

* **Platform-wide label.** The widget title now reads "Voice Fleet Capacity - all workspaces" to make it clear that the counts reflect the shared platform-wide pool, not workspace-scoped resources.
* **Allocated description updated.** The "Allocated" metric description now reads "live calls - all workspaces" instead of "live calls."
* **Explanatory caption.** A caption below the widget explains that the fleet is a shared platform-wide pool - the counts span every workspace, not just the current one. Headroom represents the total remaining isolated-call capacity across the fleet.
* **No action required.** The change is cosmetic. No configuration or workflow changes are needed.

</details>

<details>

<summary>v2.177.0 - Developer Console: Paginated Files List in Intake Tab (July 2026)</summary>

#### Paginated Files List in Intake Tab <a href="#paginated-files-list-in-intake-tab" id="paginated-files-list-in-intake-tab"></a>

The Files list in the Intake tab now loads all files across multiple pages, removing the previous cap of 50 files.

**What changed:**

* **Full file list loading.** The Files list now automatically fetches all pages of files for the workspace. Previously, only the first 50 files were displayed, which meant datasets with more than 50 files - such as those synced from an external drive source - showed an incomplete list. The list now loads all pages progressively so that client-side search and status filters operate on the complete file set.
* **No action required.** The change is automatic. Workspaces with more than 50 files in their intake datasets will now see the full list without any configuration changes.

</details>

<details>

<summary>v2.176.0 - Developer Console: Document Source Origin in Files List (July 2026)</summary>

#### Document Source Origin in Files List <a href="#document-source-origin-in-files-list" id="document-source-origin-in-files-list"></a>

The Files list in the Intake tab now shows where each document originated, so operators can distinguish between documents synced from external cloud storage and documents uploaded manually.

**What changed:**

* **Source column added.** The Files list now includes a Source column that displays the origin of each document. Documents synced from an external drive source display "Drive" with a link to the original file in the source system. Manually uploaded documents display "Upload". Documents without a known origin display a dash.
* **Link to source file.** For drive-synced documents, the Source column entry links directly to the file in the external storage system, so operators can quickly navigate to the original source. The external file identifier is shown as a tooltip for reference.
* **No action required.** The Source column appears automatically in the Files list. No configuration changes are needed.

</details>

<details>

<summary>v2.175.0 - Developer Console: Google Drive Sources and Batches in Intake Tab (July 2026)</summary>

#### Google Drive Sources and Batches in Intake Tab <a href="#google-drive-sources-and-batches-in-intake-tab" id="google-drive-sources-and-batches-in-intake-tab"></a>

The Intake tab in the Developer Console now includes Sources and Batches segments for connecting external cloud storage folders to datasets and managing file discovery batches.

**What changed:**

* **Sources segment.** A new Sources view lists registered external data sources with their mapped datasets, connection status (Active, Disabled, Error), and creation timestamp. Each source row includes a Sync Now action that triggers file discovery for the source's configured folders.
* **Add Drive Source dialog.** A new dialog lets operators register an external source by providing a display name and one or more folder-to-dataset mappings. Each mapping accepts a folder identifier (or a full folder URL, which is automatically parsed to extract the identifier) and a dataset slug. The dialog validates that folder identifiers and dataset slugs conform to the expected format and that dataset slugs are unique within the source. Source credentials are provisioned out-of-band and are not part of the registration payload.
* **Batches segment.** A new Batches view lists file discovery batches with their dataset, status (Discovered, Ready, Processing, Completed, Failed), file count, and discovery timestamp. Batches in Ready status display a Start Processing action that triggers extraction for all files in the batch.
* **Segmented control updated.** The Intake tab segmented control now includes four segments: Uploads, Schemas, Sources, and Batches. Each segment is deep-linkable via the `segment` query parameter.
* **Refresh controls.** Both the Sources and Batches views include a Refresh button for manual data reload.

**What you need to do:**

* **No action required.** The new segments appear automatically in the Intake tab. To connect an external source, navigate to Data Sources, select the Intake tab, switch to the Sources segment, and click Add Drive source.

</details>

<details>

<summary>v2.174.0 - Developer Console: Voice Fleet Capacity Widget on Active Calls Page (July 2026)</summary>

#### Voice Fleet Capacity Widget on Active Calls Page <a href="#voice-fleet-capacity-widget-on-active-calls-page" id="voice-fleet-capacity-widget-on-active-calls-page"></a>

The Active Calls page in the Developer Console now displays a live fleet capacity widget showing the health and availability of the voice infrastructure.

**What changed:**

* **Fleet capacity widget.** A new widget at the top of the Active Calls page shows real-time voice fleet capacity: ready instances (warm buffer), allocated instances (live calls), total instances, and available headroom. The headroom indicator uses color-coded severity - green when capacity is healthy, yellow when tight, and red when near the ceiling.
* **State distribution bar.** Below the summary metrics, a distribution bar breaks down instances by state, giving operators a visual overview of fleet composition at a glance.
* **Always visible.** The widget renders even when there are zero active calls, so operators always have visibility into the warm pool and available headroom without needing to wait for call activity.
* **Live polling.** The widget polls alongside the active calls list, so capacity data stays current without manual refresh.
* **Graceful loading.** The widget stays hidden during initial load to avoid a second loading indicator alongside the active calls list. It appears once the first data response arrives. If the capacity data fails to load, an error message is displayed.

**What you need to do:**

* **No action required.** The widget appears automatically on the Active Calls page. No configuration or feature flags are needed.

</details>

<details>

<summary>v2.173.0 - Developer Console: Revert Live Background Activity Surface in Text Playground (July 2026)</summary>

#### Revert Live Background Activity Surface in Text Playground <a href="#revert-live-background-activity-surface-in-text-playground" id="revert-live-background-activity-surface-in-text-playground"></a>

The live background activity lane, provenance labels, and post-close result capture introduced in v2.171.0 and v2.172.0 have been reverted. Background skill results return to the previous behavior of appearing on the next conversation turn.

**What changed:**

* **Background activity lane removed.** The dedicated "Background activity" section below conversation turns has been removed. Background tool results and agent messages are no longer displayed in a separate lane.
* **Provenance labels removed.** The "Background tool" label, "Background" badge, and "Proactive update" accent on tool cards and agent messages have been removed. All tool cards display the standard "Tool completed" / "Tool failed" / "Calling tool" labels. All agent messages display the standard "Agent" label.
* **Relative timestamps removed.** The live-updating relative timestamp chips on background cards and messages have been removed.
* **Post-close result capture removed.** The session subscription no longer stays active after close to capture late-arriving background results.
* **Live deduplication removed.** The deduplication logic for live background pushes against the conversation history has been removed.
* **Standard conversation flow restored.** Background skill results appear in the conversation when the next turn is sent, matching the behavior prior to v2.171.0.

**What you need to do:**

* **No action required.** If you relied on live background result rendering, background skill results now appear after sending the next message in the conversation.

</details>

<details>

<summary>v2.172.0 - Developer Console: Background Activity Lane, Provenance Labels, and Post-Close Results in Text Playground (July 2026)</summary>

#### Background Activity Lane, Provenance Labels, and Post-Close Results in Text Playground <a href="#background-activity-lane-provenance-labels-and-post-close-results-in-text-playground" id="background-activity-lane-provenance-labels-and-post-close-results-in-text-playground"></a>

{% hint style="warning" %}
**Reverted in v2.173.0.** The features described in this entry were reverted. See v2.173.0 above.
{% endhint %}

Background skill results and unsolicited agent messages now render in a dedicated "Background activity" lane in the text playground, with provenance labels, relative timestamps, and support for results that arrive after the session ends.

**What changed:**

* **Dedicated background activity lane.** Background tool results and proactive agent messages now render in a visually separated "Background activity" section below the numbered conversation turns, rather than being attached to whatever turn happens to be open. This prevents background results from being mistaken for a reply to the user's last message.
* **Provenance labels on background cards.** Tool call cards originating from background skill execution are labeled "Background tool completed" (or "Background tool running" / "Background tool failed") with a "Background" badge, distinguishing them from in-turn tool calls. Unsolicited agent messages are labeled "Proactive update" with a distinct visual accent instead of the plain "Agent" label.
* **Relative timestamps.** Each background tool card and proactive message displays a live-updating relative timestamp (e.g. "20s ago", "5m ago") showing when it arrived, so you can see how stale a proactive update is at a glance.
* **Post-close result capture.** Background results that arrive after the session has ended are now captured and displayed in the background activity lane rather than silently dropped. The session subscription stays active briefly after close to catch late-arriving results.
* **Improved deduplication.** Deduplication between live background pushes and the next-turn drain now normalizes text before comparison, so results that differ only by minor formatting are correctly collapsed to a single card.

**What you need to do:**

* **No action required.** Background skill results and agent messages now appear automatically in the dedicated lane. If you previously relied on sending a follow-up message to see async skill results, that workaround is no longer necessary.

</details>

<details>

<summary>v2.171.0 - Developer Console: Live Background Tool Results and Agent Messages in Text Playground (July 2026)</summary>

#### Live Background Tool Results and Agent Messages in Text Playground <a href="#live-background-tool-results-and-agent-messages-in-text-playground" id="live-background-tool-results-and-agent-messages-in-text-playground"></a>

{% hint style="warning" %}
**Reverted in v2.173.0.** The features described in this entry were reverted. See v2.173.0 above.
{% endhint %}

The text playground now renders background skill results and unsolicited agent messages live, without requiring the user to send another turn.

**What changed:**

* **Live background tool results.** When a skill configured with background execution completes during an active text playground session, the tool result card appears in the conversation immediately. Previously, background skill results only surfaced after the user sent the next message. This eliminates the "must refresh to see the result" symptom for async skill workflows.
* **Live unsolicited agent messages.** Agent messages that arrive without a preceding user turn - for example, proactive notifications triggered by a background skill - now render in the conversation as they arrive.
* **Automatic deduplication.** Both background tool results and agent messages are deduplicated against the conversation history. When the next turn drains the same result or message from the server, the playground keeps a single copy rather than showing a duplicate card or bubble.
* **Works across session states.** Live pushes are rendered whether the session is actively connected, has ended, or is in an error state. Idle and connecting sessions ignore live pushes as expected.

**What you need to do:**

* **No action required.** Background skill results and agent messages now appear automatically in the text playground. If you previously needed to send a follow-up message to see async skill results, that workaround is no longer necessary.

</details>

<details>

<summary>v2.170.0 - Developer Console: Multi-Type Document Schemas in Customer Data Intake (July 2026)</summary>

#### Multi-Type Document Schemas in Customer Data Intake <a href="#multi-type-document-schemas-in-customer-data-intake" id="multi-type-document-schemas-in-customer-data-intake"></a>

The Developer Console now supports creating document schemas that accept multiple file types, so a single schema can handle a mix of document formats.

**What changed:**

* **Multi-type document schemas.** When creating a document schema (PDF, Word, Markdown, or text), the Create Schema dialog now shows an "Also accept" toggle group listing the other document types. Select any combination of additional types that the schema should accept alongside the primary type. For example, a schema with a primary type of PDF can also accept Word and Markdown uploads.
* **Upload validation updated.** The file upload dialog now validates uploaded files against all accepted types for the schema, not just the primary type. The file input's accept filter reflects the full set of accepted types, so the browser's file picker shows all valid extensions.
* **Validation error messages updated.** When an uploaded file does not match any accepted type, the error message lists all accepted extensions (e.g. "File must be one of: .pdf, .docx, .md matching the schema") rather than showing only the primary type.
* **Per-document type consistency.** Each document retains a single file type across its versions. The multi-type setting controls which types the schema accepts for new uploads, not type conversion between versions.

**What you need to do:**

* **No action required.** Existing single-type document schemas continue to work as before. The "Also accept" option appears automatically when you create a new document schema. To add additional accepted types to an existing schema, recreate the schema with the desired types selected.

</details>

<details>

<summary>v2.169.0 - Developer Console: Workspace Voice Settings and Voice Runtime Controls (July 2026)</summary>

#### Workspace Voice Settings and Voice Runtime Controls <a href="#workspace-voice-settings-and-voice-runtime-controls" id="workspace-voice-settings-and-voice-runtime-controls"></a>

The Developer Console now includes a dedicated Voice tab in Workspace Settings for managing workspace-level voice defaults, and the service edit page exposes voice runtime selection directly.

**What changed:**

* **Voice settings tab in Workspace Settings.** A new "Voice" tab appears alongside General and Retention in the workspace settings page. The tab provides a form for managing workspace-level voice defaults including STT provider, TTS provider, voice ID, tone, speed, volume, and pronunciation dictionary ID. Individual agents can override `voice_id` in their agent config, and services can override pipeline behavior.
* **TTS provider selection with provider-specific configuration.** Choose between three TTS providers using visual card selectors. Selecting a provider reveals its configuration panel - ElevenLabs shows model, voice ID, stability, similarity, style, speed, and speaker boost controls; Groq shows voice selection and speed controls with automatic Arabic dialect support.
* **STT provider selection.** Choose the speech-to-text engine for the workspace, or select "Platform default" to inherit the current production default.
* **Per-language TTS routing.** A new "Per-Language TTS Routing" section lets you route calls to different TTS providers based on language. Add languages from a supported list, choose a provider for each, and configure provider-specific settings per language. Language overrides take precedence over the workspace default provider for matched languages.
* **Domain awareness fields.** Tag-based inputs for keyterms (domain-specific vocabulary for speech recognition), correction categories (categories of audio transcription to verify), and sensitive topics (topics that trigger proactive emotion-aware handling). The Cartesia TTS provider also shows a pronunciation dictionary ID field.
* **Post-call intelligence toggles.** Toggle switches for post-call analysis (quality scoring and keyword extraction) and transcript correction (re-transcription for improved accuracy).
* **Voice runtime selection on service edit page.** When editing a service with a Voice channel type, a "Voice Runtime" dropdown lets you choose which runtime drives calls for that service. The label has been updated from "Voice provider" to "Voice Runtime" throughout the service detail and edit views.
* **Voice runtime displayed on agent versions.** The agent version card now shows the voice runtime when configured, using a human-readable label.
* **Form labels standardized.** All form labels on the service edit page now use consistent label components for improved accessibility.

**What you need to do:**

* **No action required.** The Voice tab appears automatically in workspace settings. Existing voice configurations are loaded and displayed when you open the tab. The voice runtime dropdown appears on the service edit page when the channel type is Voice.

</details>

<details>

<summary>v2.168.0 - Developer Console: Document Version History and Upload New Version in Files UI (July 2026)</summary>

#### Document Version History and Upload New Version in Files UI <a href="#document-version-history-and-upload-new-version-in-files-ui" id="document-version-history-and-upload-new-version-in-files-ui"></a>

The Files list in the Customer Data Intake section now groups uploads by document, displays version information, and lets you upload a new version of an existing document directly from the table.

**What changed:**

* **Files grouped by document.** Uploads that belong to the same document are now collapsed into a single row in the Files table. The row shows the latest version's status, schema, upload time, and error reason. Documents without version tracking (such as standalone CSV uploads) continue to appear as individual rows.
* **Version column.** A new "Version" column displays the current version number and total version count for each document (for example, "v3 - 3 versions"). Documents without version tracking show a dash.
* **Upload new version action.** Each document row with version tracking now has an "Upload new version" button (file-plus icon) in the Actions column. Clicking it opens the Upload dialog pre-configured for that document - the schema selector is locked to the document's dataset, and the dialog title and description reflect that you are adding a new version rather than uploading a new file.
* **Version history preserved.** Uploading a new version adds to the document's version chain. The latest successfully processed version becomes the current version. Previous versions remain in the system.
* **Existing upload flow unchanged.** The "Upload File" button continues to create new documents as before. Only the new "Upload new version" action targets an existing document.

**What you need to do:**

* **No action required.** The version grouping, version column, and upload-new-version action appear automatically in the Files list. Existing uploads and schemas are unaffected.

</details>

<details>

<summary>v2.167.0 - Developer Console: Document Schema Support in Create Schema Dialog (July 2026)</summary>

#### Document Schema Support in Create Schema Dialog <a href="#document-schema-support-in-create-schema-dialog" id="document-schema-support-in-create-schema-dialog"></a>

The Create Schema dialog in the Customer Data Intake section now supports document file types alongside CSV.

**What changed:**

* **File type selector is now active.** The file type dropdown in the Create Schema dialog is no longer locked to CSV. You can now choose from CSV, PDF, DOCX, MD, and TXT file types when creating a new intake schema.
* **Document datasets require only a name.** When you select a document file type (PDF, Word, Markdown, or text), the dialog hides the primary key and fields sections and displays a note explaining that document datasets are extracted to text on upload with no schema to define. You only need to provide a name and file type.
* **CSV schemas unchanged.** Selecting CSV continues to show the full schema editor with primary key, fields, and the "Infer from CSV" option, exactly as before.
* **Validation adapts to file type.** The form validates document schemas (name + file type only) and structured schemas (name + file type + fields + primary key) with appropriate rules for each.

**What you need to do:**

* **No action required.** The new file types appear automatically in the Create Schema dialog. Existing CSV schemas are unaffected.

</details>

<details>

<summary>v2.166.0 - Developer Console: Voice Session Provider Selection on Services (July 2026)</summary>

#### Voice Session Provider Selection on Services <a href="#voice-session-provider-selection-on-services" id="voice-session-provider-selection-on-services"></a>

The service edit page in the Developer Console now lets you choose which voice session runtime drives calls for a voice service.

**What changed:**

* **Voice provider selector on service edit.** When editing a voice service, a new "Voice provider" dropdown appears below the channel type selector. You can choose between the in-house pipeline, the real-time speech-to-speech runtime, or the Atlas runtime. The selection is saved as part of the service's voice configuration.
* **Conditional visibility.** The voice provider dropdown only appears when the service channel type is set to Voice. Text services do not show the selector.
* **Non-destructive save.** Saving the voice provider preserves all other voice configuration fields (latency settings, filler phrases, forwarding rules) that may have been configured through the API or CLI. Only the session provider field is updated.
* **Voice provider shown in service detail.** The read-only service detail view now displays the configured voice provider under Voice Configuration. Services without an explicit provider show "In-house" as the default.

**What you need to do:**

* **No action required.** Existing services continue to use the in-house pipeline by default. You can now change the voice runtime directly from the Developer Console without using the API or CLI.

</details>

<details>

<summary>v2.165.0 - Developer Console: Call Infrastructure Track in Live Observer (July 2026)</summary>

#### Call Infrastructure Track in Live Observer <a href="#call-infrastructure-track-in-live-observer" id="call-infrastructure-track-in-live-observer"></a>

The Live Observer for active calls now includes a Call Infrastructure panel that surfaces the per-call voice isolation lifecycle - allocation, media attachment per leg, and teardown.

**What changed:**

* **Call Infrastructure panel.** When observing a live call, the observer sidebar now shows a "Call infrastructure" card that displays the allocated media server identity, the node it landed on, and the allocation latency. Allocation latency is classified as "warm pool" (sub-250ms, indicating a pre-warmed replica was available) or "cold start" (longer, indicating a scale-up wait).
* **Per-leg media status.** The panel shows real-time media attachment status for both the caller and agent legs. While the call is active, unattached legs display as "pending" with a neutral indicator. Once the call ends, a leg that never attached is flagged as "never attached" with a failure indicator - this is the primary signal for no-audio issues where media never reached the allocated server.
* **Teardown details.** When the allocated server is reaped, the panel shows the teardown reason and total server lifetime. Orphaned servers that were reaped because media never attached are highlighted as failures.
* **New infrastructure events in the event log.** Three new event types appear in the playground and observer event logs: server allocation, media attachment (per leg), and server shutdown. These events are categorized as session events and do not render as standalone timeline entries in the observer - their data feeds the Call Infrastructure panel instead.

**What you need to do:**

* **No action required.** The Call Infrastructure panel appears automatically when observing calls that use per-call voice isolation. Calls on the shared media path do not emit infrastructure events and will not show the panel.

</details>

<details>

<summary>v2.164.0 - Developer Console: Client-Side Validation for Endpoint Path Templates (July 2026)</summary>

#### Client-Side Validation for Endpoint Path Templates <a href="#client-side-validation-for-endpoint-path-templates" id="client-side-validation-for-endpoint-path-templates"></a>

The endpoint builder in the Developer Console now validates path templates inline, catching unsupported placeholder syntax before you save.

**What changed:**

* **Inline path template validation.** When editing an integration endpoint path, the form now checks for RFC 6570 reserved-expansion operators (`{+var}`, `{#var}`, `{.var}`, `{/var}`, `{;var}`, `{?var}`, `{&var}`) and displays an inline error if any are found. Only simple `{var}` placeholders are allowed. Previously, these were rejected by the platform on save with a 422 error - now you get immediate feedback in the form.
* **Updated path field description.** The path field help text now explains that `{var}` placeholders are supported for path parameters (e.g. `users/{id}`) and that IDs containing reserved characters are encoded automatically.
* **Save blocked on invalid paths.** The endpoint form disables saving when a reserved-expansion operator is detected, so invalid templates cannot be submitted.

**What you need to do:**

* **No action required.** The validation appears automatically when editing endpoint paths. If you have existing endpoints with reserved-expansion operators, the platform already rejects them on save - this change surfaces that restriction earlier in the editing flow.

</details>

<details>

<summary>v2.163.0 - Developer Console: Normalize Inferred CSV Field Names to Valid Identifiers (July 2026)</summary>

#### Normalize Inferred CSV Field Names to Valid Identifiers <a href="#normalize-inferred-csv-field-names-to-valid-identifiers" id="normalize-inferred-csv-field-names-to-valid-identifiers"></a>

CSV-inferred field names in the Create Schema dialog are now automatically normalized to valid column identifiers, and the form validates that all field names conform to the required format before submission.

**What changed:**

* **Automatic field name normalization.** When inferring schema fields from a CSV file, header values are now converted to valid column identifiers. The normalization lowercases the header, replaces runs of non-alphanumeric characters with underscores, trims leading and trailing underscores, and prefixes an underscore when the result would start with a digit. For example, a CSV header "Client NPS Response Created Date" becomes `client_nps_response_created_date`.
* **Collision deduplication.** When normalization produces duplicate field names (for example, headers "Date" and "date" both normalize to `date`), subsequent duplicates receive a numeric suffix (`date_2`, `date_3`, etc.) to ensure all field names are unique.
* **Field name validation on submit.** The Create Schema form now validates that every field name matches the required identifier format (letters, digits, and underscores only, starting with a letter or underscore). Invalid field names are rejected with a descriptive error message before the form is submitted to the backend.

**What you need to do:**

* **No action required.** Inferred field names are normalized automatically. If you manually enter field names, the form now validates them before submission and displays a clear error if the name contains spaces or other unsupported characters.

</details>

<details>

<summary>v2.162.0 - Developer Console: Infer Schema Fields from CSV in Create Schema (July 2026)</summary>

#### Infer Schema Fields from CSV in Create Schema <a href="#infer-schema-fields-from-csv-in-create-schema" id="infer-schema-fields-from-csv-in-create-schema"></a>

The Create Schema dialog in the Customer Data Intake section now supports inferring field definitions from an uploaded CSV file, reducing manual data entry when onboarding existing datasets.

**What changed:**

* **Infer from CSV button.** The Fields section of the Create Schema dialog now includes an "Infer from CSV" button. Clicking it opens a file picker that accepts `.csv` files.
* **Automatic field inference.** When you upload a CSV, the platform reads the header row to determine field names, samples the data rows to infer each column's type (string, integer, float, boolean, date, or datetime), and populates the field list automatically. The schema name is also pre-filled from the filename if you have not already entered one.
* **Primary key detection.** The platform makes a best-effort guess at the primary key based on common column naming patterns (such as columns named `id` or ending in `_id` or `_uid`). The guessed primary key is pre-filled but fully editable.
* **Fully editable result.** All inferred fields, types, and the primary key remain editable after inference. The dialog displays a note indicating how many fields were inferred and from which file, so you can review and adjust before saving.
* **Standard CSV support.** The parser handles quoted fields, escaped quotes, commas and newlines inside quotes, CRLF line endings, and byte-order marks.

**What you need to do:**

* **No action required.** The "Infer from CSV" button appears automatically in the Create Schema dialog. You can continue creating schemas manually if you prefer.

</details>

<details>

<summary>v2.161.0 - Developer Console: Fix Identity Bindings Display on Integration Detail Page (July 2026)</summary>

#### Fix Identity Bindings Display on Integration Detail Page <a href="#fix-identity-bindings-display-on-integration-detail-page" id="fix-identity-bindings-display-on-integration-detail-page"></a>

The identity bindings display on the integration detail page now correctly reads bindings from the custom token exchange auth configuration and renders each binding as a key-value pair.

**What changed:**

* **Bindings read from auth configuration.** Identity bindings are now sourced from the custom token exchange auth configuration rather than from a top-level integration field. This fixes cases where bindings were present on the auth config but not displayed.
* **Key-value display format.** Each identity binding is now displayed as a "parameter name → identity attribute" badge (e.g., `patient_id → external_user.subject_key`), making the mapping between parameters and identity sources clear at a glance.
* **Scoped to custom token exchange.** The identity bindings row appears only for integrations using custom token exchange authentication. Other auth types show "No identity bindings" as before.

**What you need to do:**

* **No action required.** Identity bindings on custom token exchange integrations are now displayed correctly and automatically.

</details>

<details>

<summary>v2.160.0 - Developer Console: Gemini 3.x Models and Experimental Badge in Skill Editor (July 2026)</summary>

#### Gemini 3.x Models and Experimental Badge in Skill Editor <a href="#gemini-3.x-models-and-experimental-badge-in-skill-editor" id="gemini-3.x-models-and-experimental-badge-in-skill-editor"></a>

The model picker in the skill editor now includes four additional models from the next-generation Gemini family, and preview models are flagged with an "experimental" badge.

**What changed:**

* **Four new models added.** The model dropdown in the skill editor now includes four additional models from a newer generation, covering both production-ready and preview variants. All new models appear alongside existing options with their respective provider icons.
* **Experimental badge on preview models.** Models that are still in preview display an "experimental" badge next to their name in the model picker, so you can distinguish generally available models from preview models at a glance.
* **Sampling parameter warnings apply.** Models that reject sampling parameters continue to show the dynamic amber warning on the temperature and top-p fields, consistent with the behavior introduced in v2.157.0.

**What you need to do:**

* **No action required.** The new models and experimental badges appear automatically in the skill editor model picker. Preview models are functional but may change before general availability.

</details>

<details>

<summary>v2.159.0 - Developer Console: New Models in Skill Editor Model Picker (July 2026)</summary>

#### New Models in Skill Editor Model Picker <a href="#new-models-in-skill-editor-model-picker" id="new-models-in-skill-editor-model-picker"></a>

The model picker in the skill editor now includes two additional models, expanding the set of models available when configuring a skill.

**What changed:**

* **Two new models added.** The model dropdown in the skill editor now includes two additional models: one smaller-footprint model optimized for fast inference, and one lightweight model suited for cost-sensitive workloads. Both models appear alongside existing options with their respective provider icons.
* **Sampling parameter warnings apply.** Models that reject sampling parameters continue to show the dynamic amber warning on the temperature and top-p fields, consistent with the behavior introduced in v2.157.0.

**What you need to do:**

* **No action required.** The new models appear automatically in the skill editor model picker. You can select them when creating or editing a skill.

</details>

<details>

<summary>v2.158.0 - Developer Console: Identity Bindings on Integration Detail Page (July 2026)</summary>

#### Identity Bindings on Integration Detail Page <a href="#identity-bindings-on-integration-detail-page" id="identity-bindings-on-integration-detail-page"></a>

The integration detail page in the Developer Console now displays identity bindings configured on an integration.

**What changed:**

* **Identity bindings row.** The Authentication section on the integration detail page now includes an "Identity Bindings" row. If the integration has identity bindings configured, each binding is displayed as a badge. If no bindings are configured, the row shows "No identity bindings."
* **Applies to all integration types.** The identity bindings row appears for both built-in (platform-managed) and custom integrations.

**What you need to do:**

* **No action required.** Identity bindings are displayed automatically on the integration detail page if they are configured on the integration.

</details>

<details>

<summary>v2.157.0 - Developer Console: Updated Model Selector with Provider Icons (July 2026)</summary>

#### Updated Model Selector with Provider Icons <a href="#updated-model-selector-with-provider-icons" id="updated-model-selector-with-provider-icons"></a>

The model selector in the new-skill editor now displays the current set of supported models with provider icons, and shows a dynamic warning when the selected model does not support sampling parameters.

**What changed:**

* **Expanded model list.** The model dropdown in the Agent step of the new-skill editor now lists all currently supported models across all providers, replacing the previous hardcoded two-model list.
* **Provider icons.** Each model in the dropdown displays a provider icon alongside the model name, making it easier to distinguish models from different providers at a glance.
* **Dynamic sampling parameter warning.** When you select a model that rejects sampling parameters, the temperature and top-p fields display an amber warning indicating that sampling parameters will be ignored for that model. Previously, this guidance was a static note. Now it responds to the selected model.

**What you need to do:**

* **No action required.** The model selector automatically reflects the current set of supported models. If you previously selected a model that is no longer listed, update your skill configuration to use a currently supported model.

</details>

<details>

<summary>v2.156.0 - Developer Console: Intake Files List, Upload, Schemas List, and Create Schema (July 2026)</summary>

#### Intake Files List, Upload, Schemas List, and Create Schema <a href="#intake-files-list-upload-schemas-list-and-create-schema" id="intake-files-list-upload-schemas-list-and-create-schema"></a>

The Intake tab under Data Sources now includes fully functional Files and Schemas segments, replacing the previous placeholder views.

**What changed:**

* **Files list.** The Files segment displays all uploaded files with columns for file name, schema, status, error reason, upload timestamp, and a download action. Status is shown as a badge: Success (curated), Failed (rejected or failed), Processing (received, scanned, or processing), or Needs review (held). The list supports search by file name or schema name, filtering by status, and manual refresh.
* **Upload File dialog.** Upload a CSV file against a registered schema. The dialog validates that a schema is selected, a file is chosen, the file extension matches the schema's file type, and the file size is within the schema's configured limit. After upload, the file appears in the Files list with its processing result.
* **Schemas list.** The Schemas segment displays registered schema contracts with name, version, and field count columns. The list supports search by schema name.
* **Create Schema dialog.** Define a new schema contract by specifying a name, file type (CSV), a primary key (single or composite), and one or more typed fields. Supported field types: string, integer, float, boolean, date, and datetime. Validation requires a non-empty name, at least one named field with unique names, at least one primary key column, and all primary key columns must exist in the field list.

**What you need to do:**

* **No action required.** The Intake tab now provides full schema management and file upload capabilities. If you previously used placeholder views, the new segments replace them automatically.

</details>

<details>

<summary>v2.155.0 - Developer Console: Intake Tab Enabled by Default on Staging and Preview (July 2026)</summary>

#### Intake Tab Enabled by Default on Staging and Preview <a href="#intake-tab-enabled-by-default-on-staging-and-preview" id="intake-tab-enabled-by-default-on-staging-and-preview"></a>

The Intake tab under Data Sources in the Developer Console is now visible by default on staging and preview environments.

**What changed:**

* **Intake tab on by default for staging and preview.** The Data Sources Intake tab is now enabled for all workspaces on staging and preview tiers without requiring a feature gate. Previously, the tab was hidden on all environments until explicitly enabled.
* **Production unchanged.** On production, the Intake tab remains gated behind the existing feature flag and must be enabled independently.

**What you need to do:**

* **No action required.** If you are on a staging or preview environment, the Intake tab is now visible automatically. Production workspaces are unaffected.

</details>

<details>

<summary>v2.154.0 - Developer Console: Per-Skill Sampling Parameters in Skill Editor (July 2026)</summary>

#### Per-Skill Sampling Parameters in Skill Editor <a href="#per-skill-sampling-parameters-in-skill-editor" id="per-skill-sampling-parameters-in-skill-editor"></a>

The new-skill editor in the Developer Console now supports setting per-skill temperature and top-p sampling parameters.

**What changed:**

* **Temperature field.** The Agent step of the new-skill editor now includes an optional Temperature field (0-1). Controls sampling randomness for the skill's model. Leave blank to use the model default.
* **Top-p field.** The Agent step now includes an optional Top-p field (0-1). Controls nucleus sampling for the skill's model. Leave blank to use the model default.
* **Validation.** Both fields accept values between 0 and 1 inclusive. Invalid values are flagged inline. Blank values are omitted from the skill configuration, preserving the model's default behavior.
* **Mutual exclusivity guidance.** The editor advises setting at most one of temperature or top-p. Models that reject sampling parameters ignore them silently.
* **Model-gated note.** The field descriptions note that some models (those that reject sampling parameters) ignore these values.

**What you need to do:**

* **No action required.** Existing skills are unaffected. Both fields default to blank (model default). To use sampling parameters, set temperature or top-p (not both) when creating a new skill.

</details>

<details>

<summary>v2.153.0 - Developer Console: Agent Memory Dimensions Page (July 2026)</summary>

#### Agent Memory Dimensions Page <a href="#agent-memory-dimensions-page" id="agent-memory-dimensions-page"></a>

The Developer Console now includes an Agent Memory page for inspecting and configuring how the agent remembers patient information across structured dimensions.

**What changed:**

* **Agent Memory page.** A new page under the workspace navigation (demo preview) displays all configured memory dimensions - both built-in and custom. Each dimension card shows the dimension name, description, extraction mode (LLM or static), event sources, patient coverage, total facts, average confidence, and last-updated time.
* **Dimension configuration.** Each dimension can be toggled active or inactive and assigned a weight (0-10) that influences how prominently its facts appear in the agent's context. Changes are tracked as unsaved until explicitly saved.
* **Memory summary.** A summary section at the top of the page shows overall memory coverage (percentage of patients with memory), total facts, facts added in the last seven days, active dimension count, per-dimension coverage bars, and a breakdown of data sources contributing to memory.
* **Custom dimensions.** You can add custom dimensions by specifying a name, description, event types, and optional extraction paths. Custom dimensions can also be removed. Built-in dimensions cannot be deleted.
* **Navigation entry.** The Agent Memory page is accessible from the workspace sidebar under a new "Agent Memory" link (demo preview).
* **Example mode link.** The example mode home page now includes a link card for inspecting patient memory.

**What you need to do:**

* **No action required.** This is a new demo preview page. The page uses demonstration data and does not modify production memory configuration.

</details>

<details>

<summary>v2.152.0 - Developer Console: Text Playground Sending State Indicator (July 2026)</summary>

#### Text Playground Sending State Indicator <a href="#text-playground-sending-state-indicator" id="text-playground-sending-state-indicator"></a>

The Text playground in the Developer Console now shows a clear status indicator while a message is being sent and the agent response is pending.

**What changed:**

* **"Awaiting agent response" indicator.** After sending a message in the Text playground, the chat input now displays "Awaiting agent response..." as placeholder text and is disabled until the agent responds. Previously, the input showed no visual feedback between sending a message and receiving the response, which could make it unclear whether the message was sent.
* **Distinct status states.** The chat input now reflects three states: ready (accepting input), sending (awaiting agent response, input disabled), and ended (chat ended, input disabled). Each state shows appropriate placeholder text.

**What you need to do:**

* **No action required.** This is a UI enhancement to the existing Text playground experience.

</details>

<details>

<summary>v2.151.0 - Developer Console: Text Conversation Detail View (July 2026)</summary>

#### Text Conversation Detail View <a href="#text-conversation-detail-view" id="text-conversation-detail-view"></a>

The Conversations section in the Developer Console now provides a rich detail view for text conversations, with per-turn audit information, tool call inspection, and metadata.

**What changed:**

* **Text conversation detail view.** Text conversations now display a full detail view with metadata, transcript, and an audit strip. Voice conversations retain the previous summary view and link out to the call detail page for the rich per-turn experience.
* **Audit strip.** Text conversations with anomalies - failed tool calls, escalations, or failed conversation status - display an audit strip above the transcript with labeled chips identifying each issue by tool name, turn number, or escalation type.
* **Expanded metadata.** The text conversation detail view shows additional metadata fields: completion reason, escalation status, quality score, and total tool call count, alongside the existing fields (turns, duration, created, updated, entity, service, caller, final state).
* **Transcript with inline agent trace.** The transcript renders user and agent chat bubbles with inline agent traces showing state transitions, selected actions, and tool calls (including failures). Each turn has an expandable inspector that shows the full action trace with tool inputs, outputs, and available actions.
* **System message interleaving.** System-role turns - which are not present in live sessions - are displayed as centered notices interleaved at the correct position in the transcript.
* **Tool call details on conversation detail.** The conversation detail API request now includes tool call details by default, so per-turn tool calls (inputs, outputs, duration, success status, and failure messages) are available in the detail view.

**What you need to do:**

* **No action required.** This is a UI enhancement to the existing conversation detail page. Text conversations automatically use the new detail view; voice conversations continue to show the summary view.

</details>

<details>

<summary>v2.150.0 - Developer Console: Copy Link on Surface Detail Page (July 2026)</summary>

#### Copy Link on Surface Detail Page <a href="#copy-link-on-surface-detail-page" id="copy-link-on-surface-detail-page"></a>

The Surface detail page in the Developer Console now includes a **Copy link** button for sharing active surface links.

**What changed:**

* **Copy link action.** Web surfaces and other surfaces with an active link now display a **Copy link** button on the detail page. Clicking it copies the patient-facing URL to your clipboard. The button is available while the surface is active - it is hidden for surfaces in `expired` or `archived` status.
* **SDK bump.** The Developer Console now uses Platform SDK v0.71.0.

**What you need to do:**

* **No action required.** This is a UI enhancement to the existing surfaces detail page.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.concurrence.com/api-reference/change-logs/web-platform/web-platform-history-03.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
