> 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/amigo-api/amigo-api-history-01.md).
# API History: Archive 1
Retained API history, archive 1, 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 [API](/api-reference/change-logs/amigo-api.md) for the recent history and archive index. An older entry does not establish current availability.
Platform: Metric Store Setup, Refresh, and Run Status Endpoints (August 2026)
#### Metric Store Setup, Refresh, and Run Status Endpoints
Three new endpoints provide workspace-scoped control over Metric Store initialization and on-demand data refresh.
**What changed:**
* **Setup endpoint added.** `POST /v1/{workspace_id}/metric-store/setup` triggers the one-time Metric Store schema and registry initialization for a workspace. The operation is idempotent. Returns `202 Accepted` with a `run_id` for status polling.
* **Refresh endpoint added.** `POST /v1/{workspace_id}/metric-store/refresh` triggers an on-demand refresh of the canonical Metric Store models. Returns `202 Accepted` with a `run_id` for status polling.
* **Run status endpoint added.** `GET /v1/{workspace_id}/metric-store/runs/{run_id}` returns the lifecycle state, result state, and a human-readable message for a setup or refresh run. Returns `404` if the run does not belong to a Metric Store job.
* **Workspace-scoped models.** All canonical Metric Store models now enforce workspace-level scoping. Records without a valid workspace identifier are excluded during materialization.
* **Asynchronous execution.** Both setup and refresh are asynchronous. The triggering endpoint returns immediately with a run identifier; use the status endpoint to poll for completion.
* **Environment gated.** Each endpoint returns `503 Service Unavailable` when the backing job has not been configured for the current deployment environment.
* **Permission requirements.** Setup and refresh require the workspace update permission. Run status requires the workspace view permission.
**What you need to do:**
* **No action required for existing integrations.** These are new endpoints with no effect on existing API behavior.
* **To use Metric Store control-plane operations**, call the setup endpoint once per workspace to initialize the schema, then use the refresh endpoint for on-demand updates between scheduled pipeline runs. Poll the run status endpoint with the returned `run_id` to track completion.
Platform: Entity Overlay Available on Text and Web Session Open (August 2026)
#### Entity Overlay Available on Text and Web Session Open
Text and web sessions now bind a known subject entity at session open, giving the first turn access to the overlay-merged enrichment projection when the workspace enrichment read flag is enabled.
**What changed:**
* **Open-time entity binding on text and web.** When a text or web session is created with a known entity identifier, the platform binds that entity to the session context at open time rather than waiting for a mid-session tool call. This means the synchronous enrichment overlay - the same overlay used on voice sessions - is merged into the context available from the first conversational turn.
* **Feature-flag gated.** The bind only activates when the workspace enrichment overlay read flag is enabled. Workspaces without the flag retain the previous static-render behavior with no change.
* **Operator sessions excluded.** Operator-anchored sessions do not bind the entity at open. This prevents the operator's own record from being treated as the subject of care. Operator sessions continue to resolve the subject mid-session through lookup or create tools.
* **Caller context override respected.** If an explicit context string is passed at session creation, the open-time bind is suppressed to avoid silently discarding the caller-supplied override.
* **Fail-open behavior.** If the data layer is temporarily unavailable during the bind attempt, the session opens normally with its existing static context render. A transient error on the open-time read does not block session creation.
**What you need to do:**
* **No action required for most integrations.** Sessions that already pass an entity identifier at creation automatically benefit from richer first-turn context when the enrichment read flag is enabled.
* **Review caller-supplied context overrides.** If your integration passes both an entity identifier and an explicit context string, the context string takes precedence and the overlay bind is skipped, preserving your override.
Platform: Cost-to-Serve Endpoints for LLM Inference and Infrastructure (August 2026)
#### Cost-to-Serve Endpoints for LLM Inference and Infrastructure
Two new endpoints provide workspace-level cost-to-serve visibility, split by cost domain so each figure carries its own accuracy caveats.
**What changed:**
* **LLM inference cost endpoint added.** `GET /v1/{workspace_id}/cost-to-serve/llm-inference` returns per-model token usage and dollar cost for a closed month. Each model reports input, output, and cached token counts. Models without a rate-card entry are surfaced with a null cost and flagged, and the response indicates when the total understates actual spend due to unpriced usage.
* **Infrastructure cost endpoint added.** `GET /v1/{workspace_id}/cost-to-serve/infrastructure` returns per-component infrastructure cost for a closed month. Components report whether the cost is a usage-weighted share of a pooled resource or directly tagged spend. Components with no spend are omitted.
* **Monthly close sourced.** Both endpoints read from the monthly cost-allocation close, which reconciles the full bill to zero residual. Only closed months can be queried. When multiple close runs exist for the same month, only the latest is returned.
* **Amigo staff only.** Both endpoints require an Amigo administrator identity and reject API-key-authenticated callers. This is not a workspace permission - the data represents Amigo's cost structure, not the customer's bill.
**What you need to do:**
* **No action required for most integrations.** These endpoints are restricted to Amigo staff and are not available to workspace administrators or machine-to-machine API keys.
Platform: Workspace Region and Environment Are Now Deployment-Derived (August 2026)
#### Workspace Region and Environment Are Now Deployment-Derived
Workspace responses no longer store a per-workspace region or environment. Both values are now derived from the deployment serving the request.
**What changed:**
* **Region is deployment-derived.** The `region` field in workspace responses now reports the region of the platform deployment handling the request rather than a stored per-workspace value. The field remains present on the wire for compatibility.
* **Environment is deployment-derived.** The `environment` field in workspace responses continues to reflect the deployment stage (e.g., `production` or `staging`), unchanged from the earlier removal of the stored environment column.
* **Create and update accept and ignore both fields.** Sending `region` or `environment` in create-workspace or update-workspace request bodies is accepted for backward compatibility but has no effect. Region is determined by the deployment endpoint you call, and environment is determined by the deployment stage.
* **Region immutability enforcement removed from update.** Previously, sending a non-null `region` value in an update request returned a 422 error. The field is now silently ignored instead, consistent with the `environment` field.
* **No change to data residency.** Workspaces continue to be served by the regional deployment whose endpoint created them. Data residency guarantees are unchanged.
**What you need to do:**
* **No action required for most integrations.** The `region` and `environment` fields remain present in responses with the same shape. If your integration writes to these fields on create or update, the values are accepted and ignored.
* **Remove region-update error handling.** If your code handled the 422 error from sending `region` on workspace update, that error is no longer returned. You can remove the handling, though the field is still a no-op.
* **Derive region from your endpoint.** If you need the workspace's region, use the regional hostname you are calling (e.g., the regional API endpoint) rather than reading the `region` response field, which reflects the same information.
Platform: Canonical Metric Store Models (August 2026)
#### Canonical Metric Store Models
The Metric Store now includes a set of canonical models that normalize platform data into consistent, workspace-scoped projections for metrics, dashboards, and downstream analytics.
**What changed:**
* **Canonical models added.** Twelve governed models are now available: Entity Dimension, Conversation Fact, Interaction Fact, Decision and Tool Execution Fact, Conversation Outcome Fact, Call Intelligence Fact, Topic Classification Fact, Appointment Workflow Fact, Event and Clinical Evidence Fact, Data Source and Model Health Fact, and Metric Output.
* **Pointer-driven source resolution.** Each model resolves its physical source tables from configuration at runtime. The same transformation logic runs across environments without modification.
* **Cross-channel conversation lifecycle.** The Conversation Fact model merges run-level metadata with session and voice activity into a single row per workspace conversation, providing start and end timestamps, status, run counts, and interaction counts.
* **Normalized interactions.** The Interaction Fact model unions text turns, voice turns, and non-session events into a common shape with interaction type, channel, timestamps, and source evidence.
* **Call intelligence and evaluation evidence.** The Call Intelligence Fact model merges call-quality records with evaluation scores covering quality, duration, emotion, risk, and tool execution.
* **Outcome and clinical evidence.** Outcome, appointment, topic classification, and clinical evidence models provide attributable evidence with confidence scores, review status, and FHIR resource references where available.
* **Health observability.** The Data Source and Model Health Fact model provides a unified view of connector health, event throughput, and metric freshness.
* **Canonicalization timestamp.** Every model includes a timestamp indicating when the projection was last materialized.
**What you need to do:**
* **No action required.** The canonical models are available automatically. Workspaces using Metric Store dashboards and analytics benefit from the normalized projections without configuration changes.
Platform: Workspace Data Query Tools Available in Trigger Actions (August 2026)
#### Workspace Data Query Tools Available in Trigger Actions
Trigger actions can now invoke workspace data queries that are explicitly listed in the action configuration.
**What changed:**
* **Workspace data query tools in actions.** Trigger actions can now call workspace data queries when those queries are declared as static tools in the action configuration. Each tool is identified by a `wsq_` prefix and exposed to the action's reasoning loop alongside existing world model read and integration tools.
* **Authorization-bound queries blocked.** Workspace data queries whose parameters are bound to an authorized session cannot be invoked from trigger actions. If an action attempts to call such a query, it receives an error indicating the query is not callable from this context.
* **Only configured queries available.** The action can only invoke workspace data query tools that are explicitly listed in its configuration. Attempts to call an unconfigured query tool return an error.
* **Audit trail.** Each workspace data query invocation from a trigger action is recorded in the workspace audit log, including the query name, read-only status, and outcome.
**What you need to do:**
* **Configure workspace data query tools in action definitions.** To use a workspace data query from a trigger action, add it as a static tool with a `wsq_` prefixed name in the action configuration. Provide a description and input schema so the action can supply the correct parameters.
* **Review authorization bindings.** Queries with authorization-bound parameters are not available in trigger actions. Use only queries with unbound parameters.
Platform: Ringless Voicemail Channel Removed (August 2026)
#### Ringless Voicemail Channel Removed
The ringless voicemail channel has been removed from the platform. Use cases, sending, listing, and status tracking for ringless voicemail are no longer available.
**What changed:**
* **Ringless voicemail channel removed.** The `ringless_voicemail` channel type is no longer accepted when creating or updating use cases. Existing use cases on this channel were migrated as part of the removal.
* **Send and list endpoints removed.** The endpoints for sending ringless voicemails and listing sent voicemails have been removed from the API.
* **Status webhooks removed.** The platform no longer receives or processes delivery-status callbacks for ringless voicemails. The `channel.voicemail_status` event type is no longer emitted.
* **Triggerable event removed.** The `channel.voice.voicemail_status` event is no longer available as a trigger in workflow automation.
* **Use case channel values updated.** The set of valid channel values for use cases is now: `outbound_voice`, `inbound_voice`, `sms`, `email`, and `imessage`.
* **Phone number assignment unchanged.** Voice-channel phone number assignment continues to work for `inbound_voice` and `outbound_voice` use cases. The country restriction that applied only to the removed channel has been lifted.
**What you need to do:**
* **Remove ringless voicemail integrations.** If you created use cases with `channel: ringless_voicemail`, sent voicemails, or consumed `channel.voicemail_status` events, remove those integrations. The endpoints and event types no longer exist.
* **Update channel enumerations.** If your code validates against the set of allowed channel values, remove `ringless_voicemail` from the list.
Platform: Cross-Entity Projection Parity and Retraction Correctness (August 2026)
#### Cross-Entity Projection Parity and Retraction Correctness
World model projections that span entity boundaries - such as a person's appointment summary - now handle ownership changes and stale-data retraction correctly across all incremental and reconciliation paths.
**What changed:**
* **Cross-entity dirty tracking.** When an appointment event changes, the person referenced by that appointment is now automatically re-evaluated. This ensures that person-level appointment rollups reflect the current state without waiting for a full refresh.
* **Ownership reassignment retraction.** When an appointment is reassigned from one person to another, the previous owner's rollup retracts the stale appointment data and the new owner's rollup picks it up. Both sides are handled in a single incremental pass.
* **Reconciliation for lost history.** A dedicated reconciliation path replays the current person map on a fresh checkpoint, so every person is re-evaluated even when intermediate change records are unavailable. This closes the gap where a reassignment could leave stale data on the old owner.
* **Deterministic projection ordering.** Scalar projections now use a deterministic tiebreaker when multiple events share the same business timestamp, eliminating non-deterministic row selection that could cause value flicker across refreshes.
* **Safer array access in projections.** Array element access in entity projections now uses safe indexing. Projections that extract values from structured arrays - such as telecom entries, identifiers, or extensions - no longer raise errors when the filtered array is empty. Instead they return null, matching the expected behavior for entities that lack the targeted element.
**What you need to do:**
* **No action required.** These changes improve data correctness automatically. Person-level appointment summaries, call intelligence, and other cross-entity projections are now more reliable without configuration changes.
Platform: Remaining World Model Readers Migrated to Current Serving Projection (August 2026)
#### Remaining World Model Readers Migrated to Current Serving Projection
All remaining platform read paths - including run history lookups, outbound eligibility queries, memory pipelines, and enrichment readers - now resolve against the current-generation world model serving projection. This completes the third and final round of the reader migration.
**What changed:**
* **Run history name resolution migrated.** The run history page now resolves entity and service display names from the current serving projection. The data returned is unchanged.
* **Outbound eligibility queries migrated.** The outbound caller notebook now reads candidate entities from the current serving projection instead of the previous-generation table.
* **Memory pipelines migrated.** The memory consolidation and extraction pipelines now read enrichment data from the current-generation enrichment projection. The columns consumed are identical.
* **Enrichment view updated.** The enrichment view used by downstream analytics now sources from the current-generation projection.
* **Identity service grants updated.** The identity service now holds read access to the current serving projection.
* **No schema changes.** The columns, data types, and query behavior are unchanged across all migrated readers.
**What you need to do:**
* **No action required.** All platform-managed features - including outbound calling, memory, run history, and analytics - use the new projection automatically. If you use the SQL API or Delta Sharing and reference the world model entity or enrichment tables by name, confirm your queries use the current table names shown in the SQL API schema documentation.
Platform: World Model Read Path Migrated to Current Serving Projection (August 2026)
#### World Model Read Path Migrated to Current Serving Projection
All platform read paths - including agent tools, analytics queries, internal entity lookups, and SQL guard allowlists - now resolve against the current-generation world model serving projection. This completes the second round of the reader migration.
**What changed:**
* **Read queries migrated.** Entity lookups used by agent tools, payer search, research queries, dashboard templates, insights, internal entity checks, and identity verification now read from the current serving projection instead of the previous-generation mirror.
* **SQL guard and tool descriptions updated.** The set of tables available for fallback SQL queries and the allowlist enforced by the SQL guard reflect the current projection name. Queries that reference the previous projection name will be rejected.
* **Databricks catalog references updated.** Both production and staging catalog entries for the entity serving table now point to the current projection.
* **No schema changes.** The columns, data types, and query behavior are unchanged. The projection serves the same data with the same shape.
**What you need to do:**
* **Update any external SQL queries.** If you use the SQL API or Delta Sharing and reference the world model entity table by name, update your queries to use the current table name shown in the SQL API schema documentation. Queries against the previous name will stop working.
* **No action required for standard platform usage.** Agent conversations, dashboards, analytics, and all platform-managed features use the new projection automatically.
Platform: World Model Stateful Projections Upgraded (August 2026)
#### World Model Stateful Projections Upgraded
The world model's stateful projections for call intelligence, per-event enrichment, and appointment relationship edges have been upgraded to the latest pipeline generation. The scheduling pipeline now reads from the upgraded relationship and entity link projections.
**What changed:**
* **Call intelligence projection upgraded.** The materialized call intelligence view - which produces one aggregated intelligence blob per call entity from escalation, safety, human segment, and audit events - now runs on the current pipeline generation. The output shape and the data exposed through the customer data zone are unchanged.
* **Per-event enrichment projection upgraded.** The per-event enrichment view - which retains every enrichment event before winner selection - now runs on the current pipeline generation. The output shape is unchanged.
* **Appointment relationship edges upgraded.** The projection that explodes appointment participant references into per-participant edge rows now runs on the current pipeline generation. Downstream consumers such as the scheduling pipeline's upcoming-appointments view read from the upgraded projection automatically.
* **Retraction correctness preserved.** All three projections rebuild affected keys from remaining current state when a supporting event is superseded or removed, matching the previous generation's behavior.
**What you need to do:**
* **No action required.** The upgrade is transparent. Customer data zone views, scheduling views, and any integration that reads call intelligence, enrichment events, or relationship edges continue to work without changes.
Platform: Legacy Per-Workspace Drive Credential Path Removed (August 2026)
#### Legacy Per-Workspace Drive Credential Path Removed
The per-workspace credential path for Google Drive intake sources has been removed. All Drive intake sources now authenticate exclusively through the platform-managed intake service account - no key material is stored, uploaded, or provisioned.
**What changed:**
* **Per-workspace credential field removed.** The intake source response no longer includes the `credential_ssm_param_path` field. Sources registered before the unified service account carried this field; it is now gone from the API response.
* **Single authentication path.** Every Drive intake source authenticates by impersonating the platform-managed intake service account from the pod's own workload identity. The legacy path that read a per-workspace service-account key from secure storage has been deleted.
* **No flag-based credential switching.** The `intake-pipeline-enabled` workspace flag no longer influences which credential path is used. It now controls only upload routing, as its name implies.
* **Domain-wide delegation unchanged.** Sources that authenticate via domain-wide delegation (DWD) continue to work. The `impersonate_subject` field remains available and behaves as before.
**What you need to do:**
* **Remove references to `credential_ssm_param_path`.** If your integration reads this field from the intake source response, remove that dependency. The field is no longer returned.
* **No credential provisioning needed.** New and existing Drive sources authenticate automatically. There is no service-account key to upload or rotate.
Platform: Auto-Bind Identity Resolution Matches on Data Source Name (August 2026)
#### Auto-Bind Identity Resolution Matches on Data Source Name
The connector runner's auto-bind logic for entity resolution now matches the fold event's source system against the data source name rather than the connector type. This corrects identity attribution in workspaces where the connector type field was unavailable on the serving record.
**What changed:**
* **Matching key changed.** Auto-bind identity resolution now compares the fold event's source system to the data source's name (after shared normalization) instead of the connector type. The connector type was not reliably present on the serving record, so the previous comparison could silently fail to match.
* **Ambiguity detection tightened.** Because data source names have no uniqueness constraint and normalization can collapse distinct raw names onto the same token, the platform now collects all matching data sources before evaluating opt-in status. If more than one data source matches after normalization, the platform refuses to bind rather than picking an arbitrary match.
* **Distinct refusal counters.** Each refusal path - no match, ambiguous name collision, auto-bind flag disabled, and enabled but missing integration identifier - now emits a separate diagnostic counter. Previously, some refusal paths were silent.
**What you need to do:**
* **Review data source names in multi-source workspaces.** If two data sources in the same workspace normalize to the same name (for example, names that differ only in casing or whitespace), auto-bind will refuse to attribute folds for that name. Ensure each data source has a distinct normalized name.
* **No action required for single-source workspaces.** Workspaces with one data source per normalized name are unaffected.
Platform: Guardians Emitted as First-Class Person Entities (August 2026)
#### Guardians Emitted as First-Class Person Entities
Connector-sourced data now emits guardians - individuals related to a patient who are not themselves subjects of care - as their own person entities in the world model.
**What changed:**
* **Guardians are standalone person entities.** A guardian (for example, a parent contacted on behalf of a child) now receives its own entity identifier in the shared person namespace. Memory dimensions, enrichment writes, and subject key bindings all operate per-entity, so a guardian's conversation history and enrichment data are no longer fragmented across the children they cover.
* **Distinct from patients.** Guardians use a separate resource type within the person namespace. Patient-scoped reads exclude guardians automatically, so a guardian does not inflate patient counts or trigger disambiguation against a person record that has no date of birth.
* **Phone number retained on both records.** The guardian's phone number appears on both the guardian entity and the associated patient entity. Existing resolve-by-phone lookups continue to return the correct patients.
* **Child links on guardian entities.** Each guardian entity carries references to the patient entities of the children it covers, so consumers can traverse from guardian to children directly.
* **Mart mapper contract updated.** Connector mart mappers now return a named four-slot structure (appointment, patient, guardian, practitioner) instead of a positional three-slot tuple. Existing marts that carry no guardian data populate the guardian slot as empty with no behavioral change.
**What you need to do:**
* **No action required for most integrations.** Guardian entities appear alongside patients and practitioners in the world model. Patient-scoped queries continue to return only patients.
* **Review subject key bindings if applicable.** If your integration binds subject keys per patient and a guardian converses on behalf of multiple children, the guardian now has a single stable entity rather than a per-child binding. This is the intended behavior for multi-attempt outreach flows.
Platform: Design Agent Collector Gating Moved to Client (August 2026)
#### Design Agent Collector Gating Moved to Client
The design agent session collection endpoint no longer inspects the working directory to decide whether to store a transcript. Every authorized upload is now durably persisted; which sessions to capture is determined by the client.
**What changed:**
* **Server-side directory filtering removed.** Previously the platform checked whether the reported working directory matched a specific project checkout before storing the session transcript. That check has been removed. Every authorized request now results in a durable store, and the response status is always `stored`.
* **Client-side gating.** The client is now responsible for deciding which sessions to upload. It gates on whether the relevant skill is loaded rather than relying on the server to filter by directory.
* **Upload size cap increased.** The maximum accepted transcript size has been raised from 25 MB to 100 MB to accommodate longer sessions, including those run from a global install. Oversized requests are still rejected with a 413 status.
* **Response shape simplified.** The `status` field in the response is now always `stored`. The previous `dropped` value is no longer returned.
**What you need to do:**
* **No action required for most integrations.** If you consume the session collection response, note that `status` is now always `stored` and the `dropped` value no longer appears.
* **Update size assumptions if relevant.** If your integration enforces its own upload size limits, the platform now accepts transcripts up to 100 MB.
Platform: Connector Source Types Consolidated (August 2026)
#### Connector Source Types Consolidated
Three legacy connector source types have been removed. Workspaces that previously used these types should migrate to the supported source types listed below.
**What changed:**
* **Removed source types.** The `rest_api`, `smart_fhir`, and `lakebase_schema` source types are no longer accepted when creating or updating data sources. Existing data sources that referenced these types were migrated in a prior release.
* **Secret provisioning broadened.** When creating a data source, the platform now provisions inline private keys to secure storage whenever a private key value is present in the connection configuration, regardless of source type. Previously this behavior was limited to a single source type.
* **Connector pipeline simplified.** All connectors now use the delta-first write path, where data is streamed directly during the poll and the emitted count is reported back. The legacy raw-record write path has been removed.
**What you need to do:**
* **Update source type references.** If your integration specifies `rest_api`, `smart_fhir`, or `lakebase_schema` as a source type, switch to the appropriate supported type (`ehr`, `fhir_store`, `database`, `snowflake`, `webhook`, `file_drop`, `customer_intake`, `crm`, or `custom`).
* **No other changes required.** The data source API request and response shapes are otherwise unchanged.
Platform: Production Evaluations Limited to Metric Definitions (August 2026)
#### Production Evaluations Limited to Metric Definitions
New production evaluation definitions are now restricted to metric type. Legacy assertion definitions remain readable and executable while they are migrated, but new assertions can no longer be created.
**What changed:**
* **New definitions must be metrics.** The create endpoint for production evaluation definitions now accepts only `metric` as the evaluation type. Attempts to create an assertion-type definition are rejected.
* **Legacy assertions remain functional.** Existing assertion definitions continue to run against live conversations. The update endpoint permits changes to an existing assertion definition only if the definition was already of assertion type - you cannot convert a metric definition to an assertion.
* **Deprecation guidance on update.** If an update attempts to set the evaluation type to assertion on a definition that is not already an assertion, the platform returns an error indicating that assertions are deprecated and a metric definition should be used instead.
**What you need to do:**
* **Use metric definitions for new production evaluations.** When creating production evaluation definitions through the API, set the evaluation type to `metric`.
* **Plan migration of existing assertions.** Legacy assertion definitions will continue to work, but new evaluation criteria should be expressed as metrics. Migrate existing assertions to metric definitions at your convenience.
Platform: Read-Side Observability for Enrichment Overlay (August 2026)
#### Read-Side Observability for Enrichment Overlay
The enrichment read path now emits service-level indicators that measure overlay effectiveness and read latency.
**What changed:**
* **Overlay-served signal.** The platform now tracks how many enrichment keys were served from the synchronous overlay during an entity read. This measures the create-then-converse read-your-write path - when a newly submitted enrichment value is served to the agent before the batch projection has caught up.
* **Projection-wins signal.** The platform also tracks how many keys were won by the batch projection despite a synchronous overlay entry being present. This is a neutral catch-up indicator showing that the projection has already folded the latest event.
* **Read latency measurement.** The total time to resolve enrichment across both sources is measured and reported as a platform-internal histogram.
* **No external API change.** These indicators are internal platform metrics only. The enrichment map returned to callers retains the same shape and content as before.
**What you need to do:**
* **No action required.** These are internal observability improvements. Enrichment reads return the same shape and values as before.
Platform: Synchronous Enrichment Overlay on Entity Read (August 2026)
#### Synchronous Enrichment Overlay on Entity Read
Entity enrichment reads now merge a synchronous overlay over the batch projection, so enrichment updates are visible to the agent before the next projection cycle completes.
**What changed:**
* **Immediate enrichment visibility.** When the platform reads enrichment state for an entity during a conversation, it now merges synchronous overlay entries over the batch-projected enrichment on a per-key basis. Previously, enrichment was served exclusively from the batch projection, meaning a newly submitted enrichment event was not visible until the projection pipeline processed it.
* **Rank-based winner selection.** The merge selects the winner for each enrichment key using the projection's own ranking key. A synchronous overlay entry with a newer rank is served immediately; a projection row that has already folded a newer event is not overridden by a stale overlay entry.
* **Tombstone suppression.** A winning tombstone in either source suppresses the enrichment key entirely. The key is omitted from the result rather than falling through to an older value from the other source.
* **No output shape change.** The enrichment map returned to the rendering layer and downstream consumers retains the same shape. The merge is transparent - callers cannot distinguish whether a value was resolved from the projection or the overlay.
**What you need to do:**
* **No action required.** Enrichment reads return the same shape as before. Enrichment updates submitted through the platform are now reflected in agent context faster, without waiting for the batch projection cycle.
Platform: Structured Metric Verdicts in Evaluations (August 2026)
#### Structured Metric Verdicts in Evaluations
Metric evaluations in both simulation and production paths now use structured tool-based responses instead of free-form text, improving verdict reliability and consistency.
**What changed:**
* **Structured metric verdicts.** Metric grading in simulations and production evaluations now forces a typed structured response for every metric verdict. Previously, metric grading requested free-form output and attempted to parse it, which could fail when the model returned a substantive answer that did not conform to the expected shape. The new approach uses the same structured transport as assertion verdicts.
* **Consistent verdict shape.** Every metric verdict now includes a typed value, a justification grounded in the conversation transcript, and reference indices pointing to supporting turns. This makes metric results more predictable and easier to review.
* **Improved error reporting.** When metric grading is truncated or the model does not return a usable verdict, the platform surfaces a clear failure reason rather than silently producing a malformed result.
**What you need to do:**
* **No action required.** Metric evaluation results retain the same external shape. Existing evaluation definitions, metric configurations, and downstream integrations are unaffected. Verdicts are now more reliably structured.
Platform: Intake Storage Simplified to Per-Tenant Volumes (August 2026)
#### Intake Storage Simplified to Per-Tenant Volumes
Customer data intake now uses exclusively per-tenant volumes. The legacy shared volume, its relative-path resolution, and the startup write probe have been removed.
**What changed:**
* **Per-tenant volumes only.** Every intake upload is written to a dedicated per-tenant volume scoped to the workspace. The former shared volume and any paths that referenced it are retired.
* **No startup write probe.** The platform no longer validates volume write access at boot. Per-tenant volumes are granted individually, so a missing or misconfigured grant now surfaces as a request-time permission error (HTTP 403) rather than preventing the service from starting.
* **Legacy relative paths removed.** Stored file paths are always absolute. The fallback that resolved older relative paths against the shared volume is gone. All surviving intake records already use absolute paths, so no existing downloads are affected.
* **Shared HTTP client.** The intake subsystem now shares the application-level HTTP client instead of creating its own. Per-request timeouts are set for bulk transfers, so ordinary API calls are unaffected.
**What you need to do:**
* **No action required for standard workflows.** All active intake uploads and downloads continue to work. The per-tenant volume grant is the only access requirement.
* **Review custom integrations that referenced the shared volume.** If any out-of-band tooling targeted the legacy shared volume path, update it to use the per-tenant volume path for the relevant workspace.
Platform: Unused Data Connectors Removed (August 2026)
#### Unused Data Connectors Removed
Six data connector types that were not in active production use have been removed from the platform. The connector framework now supports a smaller, actively maintained set of source types.
**What changed:**
* **Removed connector types.** The following connector source types are no longer available: generic REST API polling, SMART FHIR (SMART Backend Services), and Lakebase Schema (cross-schema SQL polling). The following EHR adapters are no longer available: eClinicalWorks, Meditab, and Hazel Health.
* **Remaining connectors unchanged.** EHR adapters for Charm Health, Healthie, and MBP continue to operate as before. FHIR Store (Google Cloud Healthcare API) and Snowflake connectors are unchanged.
* **Connection configuration models narrowed.** Data source connection configuration no longer accepts settings for the removed connector types. Existing data sources configured with a removed type will fail validation on the next configuration refresh.
**What you need to do:**
* **Review active data source configurations.** If any workspace has a data source configured with one of the removed connector types, migrate to a supported connector type or contact your Amigo representative.
* **No action required for other connectors.** Workspaces using Charm, Healthie, MBP, FHIR Store, or Snowflake connectors are unaffected.
Scribe: Canonical ROS-Grid Cell Shape for Structured Notes (August 2026)
#### Canonical ROS-Grid Cell Shape for Structured Notes
The Scribe note-generation pipeline now emits and validates a structured object for each Review of Systems (ROS) grid cell, replacing the previous flat string representation. This aligns generated notes with the canonical field shape expected by downstream serializers and the web ROS-grid viewer.
**What changed:**
* **Structured ROS-grid cell shape.** Each system entry in an ROS-grid field is now an object with a `negative` boolean (pertinent-negative indicator) and an optional `positive` free-text finding string, instead of a bare string value. This applies to all newly generated notes that contain an ROS-grid field.
* **Generation prompt updated.** The instructions provided to the model for ROS-grid fields now describe the expected object cell shape, so generated values conform without post-processing repair.
* **Autosave validation guard.** The structured-note autosave endpoint now rejects ROS-grid cells that are bare values instead of the expected object shape. A note containing a non-object ROS-grid cell receives a 422 response identifying the affected system identifiers. This is a shallow shape check - deeper per-cell validation of field values and system membership remains a finalize-time gate.
* **Bounded repair on generation.** When the model emits a flat ROS-grid cell during generation, the validation failure drives a bounded retry rather than persisting a malformed value.
**What you need to do:**
* **Review custom integrations that read ROS-grid values.** If you consume structured-note ROS-grid data downstream, expect each system cell to be an object (`{ "negative": , "positive": "" }`) rather than a plain string. Existing notes are not retroactively modified.
* **No action required for standard workflows.** Notes generated through the platform UI or standard API paths automatically use the new shape.
Scribe: Raw Note-Generation Output Archived for Debug and Audit (August 2026)
#### Raw Note-Generation Output Archived for Debug and Audit
The Scribe note-generation pipeline now archives the verbatim model completion alongside the parsed structured note, giving workspace operators a durable record of exactly what the model returned before any parsing or validation.
**What changed:**
* **Raw output archived on every full-note generation.** When a structured note is generated, the platform persists the verbatim model completion - the text returned by the model before parsing and template validation - as a separate object in the same storage location that already holds transcript and note artifacts. Each generation produces its own addressable archive entry.
* **Best-effort and fail-open.** The archive write is strictly best-effort. A failure to persist the raw output never affects the note itself: the structured note is committed, dependents (summary, codes, actions) are enqueued, and the session proceeds normally. A missed archive is logged for operational visibility but does not surface as an error to any caller.
* **No new data exposure surface.** The raw output is note content and is stored in the same protected location as existing transcript and note artifacts, under the same access controls. No new storage destination or permission boundary is introduced.
* **Asynchronous and non-blocking.** The archive write runs independently of the generation pipeline. A slow or stalled write cannot delay the next pending generation or any downstream processing.
**What you need to do:**
* **No action required.** This is an additive internal improvement. Archived raw outputs are available for debug, evaluation, and audit workflows. Existing note generation behavior, structured output, and dependent processing are unchanged.
Platform: Automatic External Identity Binding on Person Fold (August 2026)
#### Automatic External Identity Binding on Person Fold
Data sources that opt in can now have external identity bindings materialized automatically when the entity resolution pipeline folds a person, removing the need for a separate administrative write before the person is recognized at conversation start.
**What changed:**
* **Opt-in auto-bind on fold.** When a person fold completes and the originating data source has enabled automatic binding, the platform writes a binding from the raw vendor identifier to the resolved entity using the integration configured on the data source. The binding uses the unprefixed vendor identifier, matching the key format external applications send at conversation start.
* **Best-effort with bounded timeout.** The binding call is best-effort and time-bounded. A failure - whether transient or permanent - is logged and metered but never blocks entity resolution or downstream projection.
* **Conflict detection.** If the raw vendor identifier is already bound to a different entity, the platform records the conflict for operational review rather than overwriting the existing binding.
* **Ambiguity guard.** A workspace with more than one opted-in data source of the same connector type is ambiguous. The platform refuses to bind rather than guess which integration applies, and increments a dedicated metric.
* **Graceful degradation.** When the platform environment for identity binding is not fully configured, the feature is inert. The service starts normally and logs that automatic binding is disabled.
**What you need to do:**
* **To enable:** Set the `auto_bind_external_identity` and `auto_bind_external_integration_id` fields in the data source's connection configuration. Ensure at most one data source per connector type is opted in within a workspace.
* **No action required for existing integrations.** The feature is opt-in. Data sources without these settings are unaffected.
Platform: Shareable Upload Links and Launch DPC Job Removed (August 2026)
#### Shareable Upload Links and Launch DPC Job Removed
The shareable upload-link system for customer data intake and the associated launch DPC processing job have been removed from the platform.
**What changed:**
* **Shareable upload links retired.** The API endpoints for creating, managing, and consuming shareable intake upload links have been removed. File uploads through tokenized links are no longer available. Workspaces that used this feature should transition to the standard intake pipeline, which remains fully supported.
* **Launch DPC intake job removed.** The batch processing job that extracted and summarized uploaded medical records, delivered results to external storage, and generated patient-facing follow-up surfaces has been retired. Workspaces using this workflow should coordinate with their Amigo representative for migration guidance.
* **World-model projection updated.** The entity projection that served upload file metadata is no longer produced. The serving schema retains backward-compatible placeholder columns so downstream consumers are not broken, but no new data is written to them.
* **Database migration applied.** The backing tables for upload links and upload file tracking have been dropped.
**What you need to do:**
* **Remove integrations that create or consume upload links.** API calls to the removed upload-link endpoints will return errors. Switch to the standard intake source and connector workflow.
* **Update automations that depend on the launch DPC job.** The batch extraction, gap analysis, and surface-creation pipeline is no longer available.
* **No action required for standard intake workflows.** The core customer data intake pipeline, intake sources, connectors, and document processing are unaffected.
Platform: World Model Serving Layer Upgrade (August 2026)
#### World Model Serving Layer Upgrade
The platform's world-model serving layer has been upgraded to v3 for all primary read paths, improving data freshness and pipeline reliability. The public query contract is unchanged.
**Entity type accuracy fix (August 2026).** A projection defect could assign an incorrect entity type to a person when the person's most recent activity event was mirrored from a related entity of a different type. Five production person entities were affected and displayed the wrong type. The fix ensures that mirrored activity events carry the related entity's own type rather than the originating entity's type, matching the behavior of the previous serving layer. No API contract or query path changed; affected entities now return their correct type.
**What changed:**
* **Serving layer upgraded.** Entity and canonical-entity-map reads now resolve from the v3 serving projection. The v3 projection is sourced from the latest world-model pipeline generation and is refreshed on the same cadence as the previous projection.
* **Improved freshness for canonical entity maps.** The canonical entity map serving source was experiencing intermittent staleness under the previous pipeline. The v3 source eliminates this issue and delivers strictly fresher results.
* **Public query contract unchanged.** The `GET /v1/{workspace}/query/world/entities_synced` URL path and response shape are unchanged. The URL path segment is a stable public contract and does not reflect the underlying serving table.
* **Column and type compatibility verified.** All mapped columns were verified to have identical names and types between the previous and current serving projections before the cutover.
* **Workspace-scoped reads enforced.** All query paths continue to scope reads by workspace. Entity identifiers are unique only within a workspace, and cross-workspace isolation is maintained.
**What you need to do:**
* **No action required.** Query paths, response shapes, and SDK behavior are unchanged. Data freshness may improve, particularly for canonical entity map lookups.
Platform: Entity Enrichment Read Path Repoint (August 2026)
#### Entity Enrichment Read Path Repoint
The agent engine can now read entity enrichment data from a dedicated per-key projection instead of the legacy pivot projection bundled with the entity record. Both projections derive from the same upstream enrichment data, so the content served to the agent is unchanged.
**What changed:**
* **Workspace-scoped feature flag.** A new feature flag (`entity-overlay-read-enabled`, off by default) controls which enrichment projection the agent reads during a session. Workspaces that do not enable the flag continue using the legacy pivot projection with no behavior change.
* **Fail-open flag evaluation.** The flag check is time-bounded. If the feature flag service is slow or unavailable, the agent defaults to the legacy read path. A flag evaluation failure never delays or prevents session creation.
* **Fail-open enrichment read.** When the dedicated projection is enabled but a read from it fails, the agent falls back to the pivot enrichment already available on the entity record. Enrichment context is never blanked by a transient read failure.
* **Applies to all session types.** The enrichment read path selection applies to voice sessions, text sessions, and operator-anchored sessions that render clinical context.
**What you need to do:**
* **No action required.** The feature flag is off by default. Workspaces enrolled in the entity overlay preview can enable it in coordination with their Amigo contact. Enrichment content visible to the agent is unchanged regardless of which read path is active.
Platform: World-Model Projection Efficiency Improvements (August 2026)
#### World-Model Projection Efficiency Improvements
The world-model projection pipeline now suppresses redundant writes and narrows intermediate reads, reducing change-feed churn and downstream reprocessing volume.
**What changed:**
* **No-op update guard on event resolution.** When an event is re-resolved and the resulting record is byte-identical to the row already stored, the pipeline skips the write. Previously, unconditional updates rewrote unchanged rows and emitted phantom change-feed entries that downstream entity materialization had to read, deduplicate, and discard. In measured production traffic the guard eliminated the dominant source of wasted work in the resolution stage.
* **Workspace-scoped intermediate reads.** Intermediate reference tables used during entity snapshot materialization are now pre-filtered to the workspaces that contain dirty entities, matching the scoping already applied to the resolved event table. This avoids full-table reads of reference data when only a small number of workspaces have changes in a given batch.
* **Empty-delete guard on entity store.** When a materialization batch contains no entities to remove, the delete operation is skipped entirely. This avoids an empty commit and its associated change-feed entry on the entity table, reducing noise for downstream streaming consumers.
**What you need to do:**
* **No action required.** These are internal efficiency improvements. Entity projection correctness and read-path behavior are unchanged. Workspaces may observe lower end-to-end latency between event submission and entity availability.
Platform: Entity Overlay Write Path Wired to Enrichment PUT (August 2026)
#### Entity Overlay Write Path Wired to Enrichment PUT
The synchronous enrichment overlay is now available through the existing enrichment PUT endpoint, gated by a per-workspace feature flag.
**What changed:**
* **Enrichment PUT uses the overlay path when enabled.** When the workspace flag is active, the `PUT` enrichment endpoint writes a durable event and a synchronous overlay row in a single request. The response includes an `overlay_status` field indicating whether the overlay committed successfully or the write fell back to projection latency.
* **Idempotency-Key header.** The endpoint accepts an optional `Idempotency-Key` header (UUID). Retries with the same key and body return the original result without duplicate events. Reusing a key with a different body returns `409 Conflict`. When omitted, the platform generates a key automatically.
* **Deterministic event identifiers.** Each enrichment attribute in a write receives a deterministic event identifier derived from the workspace, idempotency key, and attribute key. Retries produce the same identifiers, and downstream deduplication collapses them to one logical event per attribute.
* **Best-effort overlay with graceful degradation.** If the overlay write fails, the enrichment is still durable and becomes visible at normal projection latency. The `overlay_status` field reports `skipped` in this case.
* **Retry-aware result retention.** Completed writes retain their result in the idempotency store. A retry after an ambiguous failure returns the stored response. If the original overlay was skipped, a retry reattempts only the overlay upsert without re-emitting the event.
**What you need to do:**
* **No action required for existing integrations.** The flag is off by default. Workspaces without the flag continue to use the classic enrichment write path. When the flag is enabled, the overlay is transparent to reads - enrichment queries automatically merge overlay and projected state using standard ranking.
* **To use idempotent writes,** include an `Idempotency-Key` header with a stable UUID on each request. This is recommended for create-then-converse workflows where a retry must not produce duplicate enrichment events.
Platform: Synchronous Entity Enrichment Overlay (August 2026)
#### Synchronous Entity Enrichment Overlay
The platform now supports a synchronous enrichment overlay so that create-then-converse workflows can read a just-written enrichment before the asynchronous projection materializes it.
**What changed:**
* **Write-ahead overlay for enrichments.** When an entity enrichment is written through the synchronous path, the value is stored in a workspace-scoped overlay. Conversation reads that need the enrichment see the overlay value immediately rather than waiting for the projection pipeline.
* **Unified winner selection.** The read path compares the overlay row and the projected row using the same enrichment ranking used everywhere else - confidence tier (descending), effective time (descending), ingestion time (descending), and a deterministic tiebreak. Whichever source wins is returned to the caller.
* **Automatic reaping.** Once the projection catches up and produces an equivalent or higher-ranked value, or after a time-to-live window expires, the overlay row is removed. The overlay does not accumulate indefinitely.
* **Tombstone support.** A removal signal can be written to the overlay to suppress a previously overlaid value without waiting for the projection to process the removal event.
* **Workspace isolation.** Overlay rows enforce the same workspace-scoped boundaries as projections. An overlay row in one workspace is invisible to reads in another workspace.
**What you need to do:**
* **No action required for existing integrations.** The overlay is transparent to callers. Enrichment reads automatically consider both the overlay and the projection and return the winner. Workspaces that do not use the synchronous write path are unaffected.
Platform: Result-Retaining Interactive Write Idempotency (August 2026)
#### Result-Retaining Interactive Write Idempotency
Interactive entity writes in the synchronous overlay path now retain completed results across retries, preventing duplicate downstream effects when a response is lost.
**What changed:**
* **Result-retaining idempotency.** Interactive entity writes accept a caller-supplied idempotency key scoped to the workspace. When a write completes, the platform stores the full result for a window exceeding the supported client retry horizon. A retry with the same key and the same request fingerprint replays the stored result instead of re-emitting events.
* **Four claim outcomes.** The idempotency layer distinguishes fresh (proceed), completed (replay stored result), in-progress (concurrent request holds the key), and conflict (same key, different request body). Conflicts return a 409 status.
* **Fail-closed claim acquisition.** If the idempotency store is unavailable when a claim is attempted, the write is not performed and the caller receives a retryable error. This prevents silent duplicate emission.
* **Fail-open completion and release.** Once the durable write has succeeded, a failure to record the completion only costs a dedup-safe re-emit on the next retry. Claim release after a pre-emit failure is also best-effort - an unreleased claim self-heals after a short expiry window.
* **Deterministic child event identifiers.** Events generated by an interactive write use deterministic identifiers derived from the request, so events delivered before a mid-flight failure are naturally deduplicated downstream even if the claim is re-acquired.
**What you need to do:**
* **No action required for existing integrations.** Callers that already supply an idempotency key benefit automatically. Callers that do not supply one are unaffected.
Platform: Unified Enrichment Winner Selection (August 2026)
#### Unified Enrichment Winner Selection
The enrichment winner comparator - which determines which source wins when multiple enrichments provide the same entity attribute - is now implemented as a single shared definition used consistently across the projection pipeline, the synchronous overlay reader, and the overlay lifecycle.
**What changed:**
* **Single-sourced winner ordering.** The enrichment winner is selected by a fixed ordering: confidence bucket (descending), effective time (descending), ingestion time (descending), and event identifier as a deterministic tiebreak (descending). Null values on any axis rank below present values. This ordering was already used in the projection pipeline; it is now enforced identically in the overlay read path and the overlay reaper.
* **Confidence bucketing.** Confidence values are grouped into four tiers before comparison, so minor confidence fluctuations within the same tier do not cause unnecessary winner flips.
* **No behavioral change for most users.** The ordering matches the existing pipeline behavior. This change eliminates a class of potential divergence between what the synchronous read path returns and what the pipeline eventually materializes.
**What you need to do:**
* **No action required.** This is an internal consistency improvement. The enrichment winner ordering is unchanged from the pipeline's existing behavior.
Platform: Ephemeral Tool Results Honored on Text and Simulation Sessions (August 2026)
#### Ephemeral Tool Results Honored on Text and Simulation Sessions
Tool bindings with `result_persistence: ephemeral` are now fully honored on the inline text and simulation session path. Ephemeral results steer the current reasoning transaction - including continuation turns and completion-gated navigation - without persisting raw arguments or results to durable conversation history.
**What changed:**
* **Ephemeral results active on text and simulation.** When a tool binding declares ephemeral persistence, the agent engine uses the raw result within the active reasoning transaction (engage continuation and navigation decisions) but journals only redacted execution metadata - tool identity, call identifier, timing, success, and routing identifiers - with no raw arguments or result payload. Prompt reconstruction excludes those redacted entries, so ephemeral content never appears in a later turn's context.
* **Modality-specific enforcement.** Voice, background, and external-realtime sessions that reference an ephemeral binding are rejected at session initialization. Those modalities do not silently degrade an ephemeral binding to accumulate; the session fails closed with a clear error.
* **Per-workspace runtime flag.** A workspace-level runtime flag controls whether the raw ephemeral payload is rendered into the current transaction's prompts on honoring modalities. With the flag disabled, the session still runs and still journals the redacted metadata pair, but no raw ephemeral content reaches any prompt. Flag evaluation failures default to disabled (fail-safe).
* **Navigation bridge.** Completion-gated navigation - which runs as a separate reasoning interaction from the engage step - now receives raw ephemeral results through an explicit bridge so navigation decisions can react to ephemeral tool output. Persistent tool results are not duplicated through this bridge because they already render from the journal.
**What you need to do:**
* **No action required for existing workspaces.** Workspaces without ephemeral tool bindings are unaffected. Workspaces that previously had ephemeral bindings rejected at session init can now use them on text and simulation sessions once the workspace runtime flag is enabled.
* **Voice and background sessions.** If your context graph uses ephemeral bindings, those sessions must run on the text or simulation path. Voice, background, and external-realtime sessions will continue to reject the graph at initialization until those modalities add ephemeral support in a future release.
Platform: Improved Circuit Breaker Resilience for Voice Calls (August 2026)
#### Improved Circuit Breaker Resilience for Voice Calls
The voice agent engine now uses more precise failure attribution in its provider circuit breakers, preventing false-positive breaker trips from dropping live calls.
**What changed:**
* **Provider-scoped failure attribution.** The circuit breaker framework now distinguishes between a provider failing to respond and unrelated cancellations such as caller hangups, concurrent task teardown, or pod lifecycle events. Only failures attributable to the provider count toward the breaker threshold. Previously, any cancellation that reached the breaker frame - including routine call teardown - could be misattributed as a provider failure, accumulating false counts that eventually tripped the breaker and rejected subsequent healthy calls.
* **Per-request provider deadlines.** Each outbound provider request now carries its own deadline inside the breaker boundary. A provider that hangs is detected and counted accurately, while cancellations originating outside the request - such as the caller disconnecting - propagate without inflating the failure count.
* **Separate navigation breaker.** The navigation step (state-machine traversal) now uses its own circuit breaker, isolated from the response-generation step. A navigation breaker trip degrades gracefully - the agent stays in its current state - without blocking response generation, which has no equivalent fallback. Previously, both steps shared one breaker, so navigation failures could open-circuit response generation and kill the turn.
* **Graceful degradation on breaker-open.** When the navigation breaker is open, the engine stays in the current conversation state and continues generating a response rather than failing the turn. This applies to primary navigation, fallback navigation, and post-tool-completion re-navigation.
* **Adjusted traversal budgets.** Per-traversal time budgets for multi-hop navigation now accommodate the full hop sequence instead of being sized off single-hop medians. Fallback and retry budgets match the primary budget so retries are not guaranteed to fail when the primary attempt used its full allocation.
**What you need to do:**
* **No action required.** This is a reliability improvement. Voice calls are less likely to be dropped by false circuit-breaker trips, and navigation failures degrade gracefully instead of terminating the turn. No API, configuration, or integration changes are needed.
Scribe: Improved Session Liveness Detection for In-Person Recordings (August 2026)
#### Improved Session Liveness Detection for In-Person Recordings
The Scribe reaper - the background process that finalizes abandoned recording sessions - now uses a more accurate liveness signal to distinguish active sessions from genuinely abandoned ones. Previously, sessions that had not yet produced a finalized transcript segment could be incorrectly classified as abandoned shortly after allocation, even while audio was actively streaming. This caused premature session termination in certain quiet-start scenarios.
**What changed:**
* **Real-time streaming liveness tracking.** In-person recording sessions now maintain a streaming-activity timestamp that is updated when a client connects and periodically while the connection is active. This signal is independent of transcript segment persistence, so sessions that are actively receiving audio but have not yet produced a durable transcript segment are correctly recognized as live.
* **Stronger reaper consistency.** The reaper's finalization step now atomically re-validates both the session's liveness and its identity before transitioning it to a terminal state. If a session becomes active between the reaper's scan and its finalization attempt - for example, because a client reconnects or audio resumes - the finalization safely no-ops instead of terminating the live session.
* **No change to Zoom sessions.** Zoom session lifecycle is unchanged. The liveness improvement applies only to in-person (microphone-based) recording sessions.
**What you need to do:**
* **No action required.** This is a reliability improvement. In-person recording sessions that are actively streaming are no longer at risk of premature termination during quiet-start periods. Existing integrations and session lifecycle behavior are unchanged.
Scribe: Info Section Coding Echo Removed from AMD Note Templates (August 2026)
#### Info Section Coding Echo Removed from AMD Note Templates
All four AMD note templates - psychiatry intake, psychiatry progress, therapy intake, and therapy progress - removed a read-only coding echo from their shared Info section.
**What changed:**
* **Coding subsection removed from Info.** The Info section previously included a read-only echo of diagnosis coding information. This echo has been removed from all four templates, which also removes the "Coding" subsection heading from the Info section. Diagnosis coding remains in its own dedicated section and is not affected.
* **Template versions bumped.** Psychiatry intake and therapy intake moved from 25.5 to 25.6. Psychiatry progress and therapy progress moved from 25.7 to 25.8.
**What you need to do:**
* **No action required.** The removed field was read-only and duplicated information already present in the diagnosis section. Generated notes will no longer include the redundant coding echo in the Info section. No integration or workflow changes are needed.
Scribe: Psych-Progress and Therapy-Progress Emergency/Telehealth Field Updates (August 2026)
#### Psych-Progress and Therapy-Progress Emergency/Telehealth Field Updates
The psychiatry progress and therapy progress note templates updated how emergency contact and telehealth statement fields are sourced.
**What changed:**
* **Psychiatry progress note (template version 25.7).** The emergency contact and telehealth statement fields are now generated from the transcript and clinician-editable, rather than pulled from chart data. This makes them eligible for document generation alongside other transcript-derived sections.
* **Therapy progress note (template version 25.7).** A telehealth statement field has been added and is generated from the transcript.
**What you need to do:**
* **No action required.** Notes generated with the updated templates will automatically use the new field sourcing. Clinicians can edit the emergency contact and telehealth statement fields in the generated document.
Scribe: Psychiatry Intake Vitals Grid and BP Field Updates (August 2026)
#### Psychiatry Intake Vitals Grid and BP Field Updates
The psychiatry intake note template updated its vitals section to use individual clinician-editable text fields and changed blood pressure position and arm fields to be generated from the transcript.
**What changed:**
* **Clinician-editable vitals fields.** The vitals measurement grid in the psychiatry intake template now presents each vital as an individual clinician-editable text field rather than a single grid block. These fields are attestation fields - they are not model-generated and must be completed by the clinician. This mirrors the mechanism already used in the psychiatry progress template.
* **BP position and arm generated from transcript.** The blood pressure position and arm fields are now generated from the transcript and editable, rather than sourced from chart data. Clinicians can review and modify the generated values.
* **Version bump.** The psychiatry intake template version advanced from 25.4 to 25.5. The section count remains at 19. The psychiatry progress template remains at 25.6.
**What you need to do:**
* **Update version references.** Template consumers that reference the psychiatry intake template version should update to 25.5.
* **Review vitals integration logic.** If your integration relies on the vitals grid structure or on BP position/arm being chart-sourced, update to handle individual editable text fields and transcript-generated BP metadata.
Scribe: Psychiatry Intake ROS Header and Option Labels (August 2026)
#### Psychiatry Intake ROS Header and Option Labels
The psychiatry intake note template now presents the Psychiatric Review of Systems gate with a visible header and capitalized option labels, making the field easier to locate and read.
**What changed:**
* **Clear ROS header.** The Psychiatric ROS selection gate now displays a "Psychiatric ROS" header above the radio options, addressing feedback that the field was easy to miss without a distinct label.
* **Capitalized option labels.** The radio options are now labeled "All Areas Negative," "Positive Areas," and "Not documented" (capitalized) instead of the previous lowercase labels.
* **Version bump.** The psychiatry intake template version advanced from 25.3 to 25.4. The psychiatry progress template remains at 25.6.
**What you need to do:**
* **Update version references.** Template consumers that reference the psychiatry intake template version should update to 25.4.
* **Review label-dependent integrations.** If your integration matches ROS option text by exact string, update to the new capitalized labels.
Scribe: Therapy Note Template Updates - Generated Fields, Section Renaming, and Version Bumps (August 2026)
#### Therapy Note Template Updates - Generated Fields, Section Renaming, and Version Bumps
The therapy intake and therapy progress note templates were updated to improve field generation behavior, rename sections for clarity, and align field sourcing with the current clinical workflow.
**What changed:**
* **Therapy intake - generated fields and section changes.** Several fields in the therapy intake template - including telehealth statement, emergency contacts, and next scheduled session - are now generated from the transcript rather than sourced from chart data, making them editable and eligible for AI generation. The Objective section was renamed to "Objective Content." The history-of-past-attempts clinical gate was re-added to the therapy intake template. The template version advanced from 25.4 to 25.5.
* **Therapy progress - field sourcing and section rename.** The emergency contacts field in the therapy progress template now sources from the transcript rather than chart data, matching the intake change. The objective content label and the Objective Content section title were updated for consistency. The template version advanced from 25.5 to 25.6.
* **Psychiatry intake template.** The psychiatry intake template remained at 25.3 at the time of this therapy update. It has since been updated separately (see the Psychiatry Intake ROS Header entry). The psychiatry progress template remains at 25.6.
**What you need to do:**
* **Update version references.** Template consumers that reference the therapy intake template version should update to 25.5. Consumers referencing the therapy progress template version should update to 25.6. Template identifiers are unchanged.
* **Review section-dependent integrations.** If your integration parses therapy note output by section name, verify that it handles the renamed "Objective Content" section in both therapy templates.
* **Review field sourcing assumptions.** If your integration depends on specific fields being chart-sourced (non-editable), verify behavior for telehealth statement, emergency contacts, and next scheduled session in therapy intake notes, and emergency contacts in therapy progress notes. These fields are now generated from the transcript and are editable.
Scribe: Psychiatry Progress Note Restructuring - Field Moves, Editable Vitals, and Field Removal (August 2026)
#### Psychiatry Progress Note Restructuring - Field Moves, Editable Vitals, and Field Removal
The psychiatry progress note template was restructured with field relocations, vitals editability changes, and a field removal. The template version advanced from 25.5 to 25.6.
**What changed:**
* **Emergency contact moved earlier.** The Emergency contact field moved from its previous section into "Session & attendees," immediately after the client location field, making it visible earlier in the note.
* **Blood pressure vitals now clinician-editable.** The BP position and arm fields changed from chart-sourced (non-editable) to clinician-editable blank fields with attestation. BP position also gained a dash ("-") option for cases where the value is not applicable.
* **Treatment modalities field removed.** The "Treatment modalities / interventions used this session" field was removed entirely from the psychiatry progress note.
* **Psychiatry intake and therapy templates unchanged.** The psychiatry intake template remains at 25.3. Therapy intake remains at 25.5 and therapy progress remains at 25.6.
**What you need to do:**
* **Update version references.** Template consumers that reference the psychiatry progress template version should update from 25.5 to 25.6. The template identifier is unchanged.
* **Review section-dependent integrations.** If your integration parses psychiatry progress note output by section name or field order, verify that it handles the Emergency contact field in its new location within "Session & attendees."
* **Review field sourcing assumptions.** If your integration depends on BP position or arm being chart-sourced (non-editable), verify behavior for these fields. They are now clinician-editable.
* **Remove references to Treatment modalities.** If your integration consumes the "Treatment modalities / interventions used this session" field from psychiatry progress notes, remove that dependency. The field is no longer present in the template.
Scribe: Psychiatry Progress Note Field Relocation and Version Bump (August 2026)
#### Psychiatry Progress Note Field Relocation and Version Bump
The psychiatry progress note template was restructured to move a block of clinical fields into a more appropriate section, and the template version advanced.
**What changed:**
* **Treatment modalities through Emergency Contact relocated.** The field run from Treatment modalities to Emergency Contact was moved out of the psychiatry progress note's main clinical section and appended to the "Diagnosis, plan & coding" section. This aligns the note layout with the current clinical review workflow.
* **Template version advanced.** The psychiatry progress template moved from version 25.4 to 25.5. The psychiatry intake template remains at 25.3. Therapy template versions are tracked in their own changelog entry.
**What you need to do:**
* **Update version references.** Template consumers that reference the psychiatry progress template version should update to 25.5. The template identifier is unchanged.
* **Review section-dependent integrations.** If your integration parses note output by section name or position, verify that it handles the Treatment modalities through Emergency Contact fields in their new location under "Diagnosis, plan & coding."
Scribe: Psychiatry Progress Note Section Restructure and Version Bump (August 2026)
#### Psychiatry Progress Note Section Restructure and Version Bump
The psychiatry progress note template was restructured to improve clinical workflow alignment. Section ordering and grouping changed, and the template version advanced.
**What changed:**
* **Safety section repositioned.** The safety assessment section now appears before session details, matching the clinical priority order used in the companion web template.
* **Session and attendees section consolidated.** Session detail and informed consent fields are now grouped under a single titled "Session & attendees" section. The previously standalone informed consent section was removed as a separate heading.
* **Unused fields removed.** The interval history and response to treatment fields were dropped from the psychiatry progress template to match the current web template structure.
* **Template version advanced.** The psychiatry progress template moved from version 25.3 to 25.4. The psychiatry intake template remains at 25.3, therapy intake remains at 25.4, and therapy progress remains at 25.5.
**What you need to do:**
* **Update version references.** Template consumers that reference the psychiatry progress template version should update to 25.4. The template identifier is unchanged.
* **Review section-dependent integrations.** If your integration parses note output by section name or field key, verify that it handles the consolidated session section and the removal of the standalone consent, interval history, and response to treatment fields.
Scribe: AMD Template Parity - Multi-Answer Conditions, Exam Grid Update, Field Renaming, and Version Bump (August 2026)
#### AMD Template Parity - Multi-Answer Conditions, Exam Grid Update, Field Renaming, and Version Bump
The AMD clinical note templates received a parity update that aligns the backend with the latest web template schemas. All four template types have updated structures, condition logic, field identifiers, and version pins.
**What changed:**
* **Multi-answer conditional visibility.** Template fields can now be shown or required based on a controlling field matching any value in a set, not just a single value. For example, a step-down section can open when the controlling field is answered with any of several qualifying responses. Previously, conditional visibility supported only single-value matching.
* **Exam grid answer vocabulary updated.** The third answer option for physical exam grid rows now uses the template-native blank/deferred answer instead of a previously invented "Not Assessed" label. Stored documents that contain the old wording are automatically migrated on read, so existing notes render correctly without manual changes.
* **Field identifier reconciliation.** A number of field identifiers were renamed to match the canonical web template vocabulary. Stored documents that use retired field identifiers are automatically migrated on read. This includes a semantic expansion of the former care-coordination field from a single multi-select into individual per-option fields.
* **Section and layout restructuring.** Sections across all four templates were reorganized - including splits, un-merges, and new sub-fields for safety plan steps, medical review-of-systems, and referral attestation - to match the current web template structure.
* **Template versions advanced.** All four AMD templates received version bumps: psychiatry intake and progress moved to 25.3, therapy intake moved to 25.4, and therapy progress moved to 25.5.
**What you need to do:**
* **Update version references.** Template consumers that reference specific template versions should update to the new version identifiers. The template identifiers themselves are unchanged.
* **No migration action required.** Read-time migration handles previously stored field identifiers and exam grid answers automatically. Downstream consumers do not need to change how they process completed notes.
* **Review care-coordination integration.** If your integration reads or writes the care-coordination field, note that it has been expanded from a single multi-select field into individual per-option fields. Stored values using the old format are migrated on read.
Scribe: AMD MBC Parity - Editable Scores, Treatment Plan Checkboxes, and Version Bump (August 2026)
#### AMD MBC Parity - Editable Scores, Treatment Plan Checkboxes, and Version Bump
The AMD clinical note templates now support clinician-editable Measurement-Based Care (MBC) scores and date-of-review fields, treatment plan assessment checkboxes, and updated gating logic across all four template types.
**What changed:**
* **MBC scores and date-of-review are now clinician-editable.** PHQ-9 and GAD-7 scores and the date-of-review field in all four AMD templates changed from read-only (chart-sourced) to clinician-editable with attestation. Clinicians can now correct or enter scores directly in the note.
* **Treatment plan assessment checkboxes.** The therapy-progress template now includes two assessment checkboxes. Score fields in the treatment plan section gate per checkbox, giving clinicians finer control over which assessments appear in the plan.
* **Revised gating logic.** The therapy-intake MBC section is now gated on the clinician confirming that assessments were reviewed. The psych-progress MBC section removed an unnecessary gate that blocked content when no assessment was reviewed, restoring the instructional note.
* **Unified score field handling.** Score fields across all psychiatry and therapy templates now use a consistent field kind, improving predictability when templates are rendered or validated.
* **Template versions advanced.** All four AMD templates received version bumps: psychiatry intake and progress moved to 25.2, therapy intake moved to 25.3, and therapy progress moved to 25.4.
**What you need to do:**
* **No action required for most integrations.** Template consumers that reference specific template versions should update to the new version identifiers. The template identifiers themselves are unchanged.
* **Review MBC workflows.** If your integration pre-populates MBC score fields as read-only chart data, note that clinicians can now edit those values. Downstream consumers should treat the scores in the completed note as clinician-attested rather than strictly chart-sourced.
Platform: Ephemeral Tool-Result Persistence (July 2026)
#### Ephemeral Tool-Result Persistence
Tool bindings in context graphs now support a third result persistence mode - `ephemeral` - alongside the existing `accumulate` (default) and `override` modes. Ephemeral persistence declares that a tool call's arguments and result may steer the current reasoning transaction but are never journaled to durable conversation context.
**What changed:**
* **New `ephemeral` result persistence mode.** A tool binding can now set `result_persistence` to `ephemeral`. When set, the platform guarantees that the tool's arguments and result are available to navigation and subsequent reasoning steps within the current transaction, but they are never written to the interaction log, never included in session synchronization, and never reconstructed into a later user turn. Execution metadata such as tool name, duration, success status, and integration identifiers may still be traced.
* **Fail-closed at session initialization.** Sessions that reference an ephemeral tool binding are rejected before any tool can execute unless both the workspace-level authoring flag and the runtime capability flag are enabled. An unsupported ephemeral binding is never silently downgraded to `accumulate`.
* **Authoring gate on context graph versions.** Creating a context graph version that includes an ephemeral tool binding requires a workspace-level authoring enablement flag. Workspaces without the flag receive a validation error.
* **Queue delivery rejected for ephemeral tools.** An ephemeral tool binding with `queue` delivery on any axis - success delivery, failure delivery, or per-class failure delivery - is rejected at context graph version creation time. Because an ephemeral result is discarded after the current reasoning transaction, a queued outcome that defers to the next user turn would never re-enter the conversation. Ephemeral tools must use `interrupt` delivery on every axis.
* **Override filter fix.** The override result persistence mode now correctly retains the latest complete start/end pair for each overridden tool, rather than dropping the start entry of the latest call.
**What you need to do:**
* **No action required for existing configurations.** The default `accumulate` behavior is unchanged. The `override` mode continues to work as before, with improved correctness for the retained pair.
* **To use ephemeral persistence,** contact your platform operator to enable the authoring and runtime capability flags for your workspace. Ensure all ephemeral tool bindings use `interrupt` delivery on every axis.
Platform: Production Evaluations On by Default (July 2026)
#### Production Evaluations On by Default
Post-call production evaluations now run automatically for every completed voice and text conversation. The previous behavior required an explicit launch flag to enable evaluation triggers per workspace. The flag remains available as a kill switch but defaults to on.
**What changed:**
* **Automatic post-call evaluation.** Completed conversations on all channels - voice and text - are now automatically submitted for evaluation against the workspace's active evaluation definitions at conversation teardown. Workspaces without active definitions incur no evaluation cost.
* **Daily cap slot refund for no-definition workspaces.** When a conversation is submitted for evaluation but the workspace has no active definitions, the daily cap slot is refunded. This prevents unconfigured workspaces from consuming their daily allowance on no-ops, so workspaces that add definitions later in the day retain their full budget.
* **Kill switch preserved.** The evaluation trigger can still be disabled per workspace or globally through the existing feature flag or an environment-level override. The default is now on rather than off.
* **Resilient flag resolution.** If the feature flag provider is slow or unavailable, the trigger resolves to the environment default rather than failing closed. This prevents transient flag-provider issues from silently disabling production grading.
**What you need to do:**
* **No action required for most workspaces.** If your workspace already has active evaluation definitions, conversations will now be graded automatically without needing a separate flag enablement. If your workspace has no definitions, there is no cost or behavioral change.
* **To disable production evaluations,** use the existing feature flag or contact your platform operator to set the environment-level override.
Platform: HMAC External Upload Path Removed (August 2026)
#### HMAC External Upload Path Removed
The HMAC-signed external file upload endpoint for customer integrations has been removed. This path had no active consumers.
**What changed:**
* **External upload endpoint removed.** The streaming binary upload endpoint that accepted HMAC-signed requests from customer integrations is no longer available. This endpoint was the original landing-zone path for automated data pushes and has been unused since its consumers migrated to other intake surfaces.
* **No replacement endpoint.** Console uploads (authenticated by JWT session or API key) and shareable customer links remain the supported intake paths. Automated integrations should use API-key-authenticated uploads or intake source connectors.
**What you need to do:**
* **No action required for most users.** This endpoint had no active consumers. If you maintained an integration that used HMAC-signed headers (`x-amigo-intake-sha256`, `x-amigo-intake-timestamp`, `x-amigo-intake-signature`, `x-amigo-intake-customer-slug`, `x-amigo-intake-filename`) to upload files, contact your platform operator to migrate to an API-key-authenticated upload or an intake source connector.
Platform: Patient-Only Warehouse Mart Support (August 2026)
#### Patient-Only Warehouse Mart Support
Warehouse connectors now support patient-only marts - data feeds that provide patient demographics and program context without associated appointment or provider records.
**What changed:**
* **Patient-only mart type.** A new mart mapper type handles warehouse feeds that supply one row per patient enrollment rather than one row per visit. The connector projects patient identity, contact information, date of birth, gender, language, address, insurance indicators, and program-specific context into the world model. No appointment or provider entity is emitted.
* **Structured program context as extensions.** Mart-specific context - such as disengagement dates, program names, enrollment identifiers, care focus areas, and primary care provider identity - is carried as structured extensions on the patient entity. This information is available to agents and downstream consumers without a separate data lookup.
* **Phone normalization for outreach readiness.** Patient phone numbers from the mart are normalized to E.164 format when they match standard US patterns. Non-standard numbers pass through unchanged for downstream handling.
* **Confidence tier prevents demographic overwrites.** Patient records from this mart type are emitted at the same lower confidence tier as other warehouse-derived entities. A sparse patient from an outreach mart will never overwrite richer demographics from a primary clinical connector, but it will create the patient entity when nothing else has.
* **No enrollment status persisted.** When the source feed contains a constant status value (such as a filter criterion that applies to every row), that value is intentionally excluded from the projected entity. Persisting a constant status would go stale when the patient leaves the feed and could mislead downstream consumers.
**What you need to do:**
* **No action required for existing data sources.** This is additive to the warehouse connector framework. Existing warehouse and EHR data sources are unaffected.
* **To connect a patient-only mart:** Work with your platform operator to configure a warehouse data source with the patient enrollment mart type and the appropriate connection 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/amigo-api/amigo-api-history-01.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.