Release notes

The Data Export API now includes a new message type, tool_call, that records when an AI Agent selects a tool during a conversation. It currently covers Actions and Handoffs configured on the AI Agent.

See the message object reference for the schema.

The Conversations endpoint in the Data Export API (v2) now exposes a new used_coaching field.

The field returns a list of Coaching events that were applied during the conversation. Each entry includes the coaching event id, entity_name, coaching_type, coaching_instructions, and coaching_intent. Conversations without Coaching return an empty array.

For more details, see the conversation object reference.

Coaching is now supported on simulated conversations so you can proactively adjust AI Agent behavior.

Coaching applied to a simulated conversation will be available for the AI Agent to use in production conversations. All coaching types are supported: send a message, handoff, use knowledge, actions, process, and run a playbook.

Learn more in the Simulations documentation.

The Messages endpoint in the Data Export API (v2) now exposes additional message data:

• A new sms_consent_asked message type, indicating that an end user was asked to consent to receiving SMS messages.
• A new sms_text field on the csat_shown message, returned when the CSAT survey was delivered via SMS. The field contains the exact text that was sent to the end user.

For more details, see the message object reference.

The End Users API now supports an external_id field, letting custom-channel integrations identify end users by their own stable identifier (for example a CRM contact ID or a phone number) across conversations.

What’s new

• Look up by external ID. GET /v2/end-users/?external_id=<value> returns the matching end user, or 404 if no mapping exists.
• Idempotent create. POST /v2/end-users/ accepts an optional external_id. If the identifier is already mapped, the existing end user is returned with 200. A new end user returns 201. Safe to retry.
• Set, update, or clear on PATCH. PATCH /v2/end-users/{end_user_id} accepts external_id to set or change the value. Passing null clears the mapping and frees the value for reuse. 409 is returned if the value is already assigned to a different end user.

Constraints

• Maximum 36 characters; < and > characters are not allowed.
• Values are stored and matched case-insensitively.
• external_id is unique per AI Agent.
• Available for custom channel integrations only (V1).

Get started

• End Users API overview
• Reuse end users across conversations with external_id
• Identify end users with a stable external ID — developer guide

Native LLM generation and Knowledge ingestion now cover all 60 of Ada’s supported languages, up from 9. The Reasoning Engine generates responses directly in the end user’s language for every supported language, and Knowledge articles in those languages are ingested by default and visible in the Knowledge page of the dashboard.

Newly supported languages

The following 51 languages now support both native LLM generation and Knowledge ingestion:

Afrikaans, Albanian, Belarusian, Bosnian, Bulgarian, Burmese, Catalan, Chichewa (Nyanja), Chinese (Traditional), Croatian, Czech, Danish, Estonian, Filipino (Tagalog), Finnish, Greek, Haitian Creole, Hebrew, Hindi, Hungarian, Icelandic, Indonesian, Japanese, Kazakh, Khmer, Kinyarwanda, Korean, Latvian, Lithuanian, Macedonian, Malay, Ndebele (South), Norwegian, Polish, Punjabi, Romanian, Russian, Serbian, Sesotho, Shona, Slovak, Slovenian, Swahili, Swedish, Tamil, Thai, Turkish, Ukrainian, Vietnamese, Xhosa, Zulu.

These join the 9 languages already supported: English, Arabic, Chinese (Simplified), Dutch, French, German, Italian, Portuguese, Spanish.

What this means for end users

End users in the newly supported languages benefit from the following improvements:

• Faster responses, because the Google Translate round-trip is removed and responses can stream in the end user’s language.
• Higher-quality replies generated directly in the end user’s language rather than translated from English.
• More accurate handling of tone, idioms, and honorifics.
• More faithful adherence to tone and style instructions provided through Coaching and Custom Instructions.

Changes to Knowledge articles

Knowledge articles in the newly supported languages now appear in the Knowledge page of the dashboard, including articles from existing knowledge integrations that were previously hidden because the AI Agent did not have multilingual ingestion enabled.

To preserve existing AI Agent behavior, all existing non-English articles for AI Agents that did not previously have multilingual ingestion enabled are set to Inactive. Review these articles in the dashboard and set them to Active to make them available for the AI Agent to use in responses.

Articles created or synced after this date follow standard behavior and default to Active.

AI Agents that already had multilingual ingestion enabled before this date are not affected by the activation change.

How the AI Agent selects Knowledge by language

When Knowledge articles exist in the end user’s language, the AI Agent uses only those articles to generate the response. English articles are not mixed in. If coverage in a specific language is partial, options include:

• Translating the remaining articles into that language.
• Setting the partial-coverage articles to Inactive so the AI Agent falls back to English.
• Contacting your Ada team to enable language-agnostic Knowledge search, which lets the AI Agent search across all languages regardless of the end user’s language.

For the full list of supported languages, see About multilingual support.

A single AI Agent can now automate multiple support email addresses through Bring Your Own Domain. Each address is configured as a separate email channel and can be managed, filtered, and routed independently.

What’s new

• Multi-address BYOD setup. Add multiple email addresses to one AI Agent through the existing BYOD flow. Addresses can be on the same domain or different domains. Each inbox has its own Ada-provisioned internal address; BYOD is optional but recommended.
• Reply-from routing. The AI Agent always replies from the same address the end user originally contacted. Email Handoffs and human-agent replies follow the same rule.
• Per-channel configuration. Sender name, email templates, launch controls, and reply-all are configurable per email channel. Blocked senders remain global.
• Channel-based filtering. Filter Conversation View and Analytics by individual email channel. Scope Playbooks, Actions, and Handoffs to a specific channel.
• email_recipient_address meta variable. The address the end user wrote to is now exposed as a meta variable, available at conversation start for routing logic.
• Conversations API multi-inbox support. GET /v2/channels/?modality=email returns every email channel configured on the AI Agent. POST /v2/conversations/email/ routes outbound replies through the channel that matches the reply_as address.
• Per-domain Zendesk SMTP Connector. SMTP credentials are now scoped per BYOD domain, with each inbox’s settings page as the configuration surface. Inboxes that share a domain share the same SMTP configuration; each new BYOD domain requires its own setup. Required for AI Agents that need shared-thread human-agent replies on multiple domains.

Get started

• Bring Your Own Domain
• Using Variables — Email channel

Webhook endpoints can now be filtered by Conversations API custom channel ID. Events from a specific custom channel can be routed to a dedicated endpoint without application-side filtering.

What’s new

• Channel ID tagging. v1.conversation.created, v1.conversation.message, and v1.conversation.ended events from a Conversations API custom channel are now tagged with the channel’s ID.
• Endpoint-level filtering. Add a custom channel ID to an endpoint’s Channels field to scope delivery to that channel. Unmatched events are filtered before delivery.
• Combined with handoff filtering. When a Conversations API conversation is in an active handoff, events carry both the channel ID and the handoff integration name, so subscribers using either tag continue to receive matching events.

For details, see Webhook channel filtering.

The Simulations feature (formerly Testing at Scale) now runs test cases as multi-turn conversations by default. This brings dashboard testing closer to real end-user interactions and expands what can be validated before deployment.

What’s new

• Multi-turn by default: Every test case runs as a multi-turn simulation, up to 40 turns per simulation.
• Scenario field: Each test case now requires a Scenario that guides the simulated end user’s goal, context, and responses across turns.
• Up to 10 expected outcomes: The per-test-case limit on expected outcomes increased from 3 to 10.
• Multi-turn execution via MCP Server: Simulations executed through the MCP Server now run as multi-turn conversations. Creating and updating test cases (including Scenarios and Expected outcomes) via MCP is also supported.

Greetings are still excluded from simulated conversations. Other limitations are unchanged.

Existing test cases remain runnable. The Customer inquiry set on each test case is used as the Scenario until the Scenario is updated. The next time a pre-existing test case is edited, updating the Scenario is required before saving.

Learn more in the Simulations documentation.

Ada’s web import scraper now identifies itself with a static User-Agent: AdaWebCrawler header on every request. Websites that restrict crawling with an allowlist can add AdaWebCrawler to keep Ada’s scraper authorized — previously the user agent was dynamic and could not be reliably allowlisted.

Learn more in our Web import documentation.