Ada turns customer-service procedures into configurable AI agent workflows

Ada is an AI customer-service platform for answering questions and completing support workflows across connected business systems. Its central building blocks include knowledge, customer variables, tools and Playbooks that guide a conversation through a process. That makes it relevant when an answer alone is insufficient: the customer needs an order checked, a subscription updated or an issue routed with the right context. Understanding how those parts fit together is more useful than treating Ada as a generic chatbot.

01 / ProductAda’s current building blocks, explained

Ada’s platform overview¹ presents a managed customer-service agent with capabilities for configuration, automation and improvement. The public documentation adds an important distinction: knowledge explains what is true, an API tool interacts with a system, and a Playbook organises a customer-facing process. A reliable implementation needs all three to agree. A policy article might explain eligibility while the account system decides whether the current customer meets it.

The current Playbooks documentation² recommends structured Playbooks for new automation. It distinguishes these from legacy block-based Processes and the earlier Playbooks Classic experience. New Playbooks use sections and ordered steps with branching. That is material for buyers reading older tutorials: a description of an entirely freeform instruction document does not fully describe the current authoring model, and an old limitation should not automatically be applied to today’s product.

Our interpretation is that Ada’s useful abstraction is an operating procedure that remains understandable to the service team. The process is not simply “answer politely.” It describes what information is needed, which operation to run and what should happen afterwards. A team should be able to explain its intended behaviour to a new support colleague before trying to encode that behaviour for an agent.

02 / AudienceWhen is Ada a sensible fit?

Ada is worth examining for a support organisation with repeatable processes, maintained knowledge and accessible customer systems. A retailer’s delivery investigation, a software company’s subscription support and a service provider’s account troubleshooting all have recognisable stages. The organisation needs somebody who can own those stages as business rules, plus technical support for authenticated integrations. The product can make configuration more accessible without eliminating the underlying system responsibilities.

It is a less natural starting point for a small site that only needs to answer public questions. Our Chatbase guide explores that narrower entry point and its path into connected actions. For a company choosing the human helpdesk at the same time, Intercom’s integrated approach raises a different question: whether to combine the inbox and AI layer. Ada should be assessed against the service architecture you intend to retain, including its escalation destinations.

An especially useful readiness test is to ask who approves a policy change. If support, finance and product teams disagree about the answer, an agent builder cannot resolve the disagreement through better wording. Establish the authoritative rule first. The resulting Playbook should make ownership more visible, so routine edits do not quietly change commercial policy.

03 / WorkflowA worked example of an Ada Playbook

Imagine a customer whose replacement item has not arrived. This is a proposed workflow, not a live Ada test. Begin with the authenticated customer identity and collect the relevant order reference. Retrieve the fulfilment state, distinguish an unshipped replacement from a carrier delay, and present the next step allowed by policy. If the shipment cannot be found, create a structured handoff rather than repeatedly asking the customer to try the same lookup.

Ada’s step reference³ explains how that flow can be expressed. ASK collects a value, SET assigns one, RUN invokes a tool or handoff, and IF/ELSE selects a branch. SEND can use authored wording or generated phrasing. This separation is useful because collecting an order reference and silently deriving an internal variable are different operations. Treating them as interchangeable instructions can produce confusing conversations.

How should customer context enter the flow?

The personalisation documentation⁴ describes profile variables and live data retrieved through integrations. For our replacement example, the application should supply the trusted account identity, while the customer can clarify which eligible order they mean. A typed reference is a search clue, not proof of ownership. The backend should restrict its response to that customer’s records and return a concise status the agent can use.

A practical design would keep carrier status and business policy separate. The carrier may report a delay; your business decides whether that delay warrants a replacement or a manual investigation. Returning an explicit eligibility result from a controlled service makes policy easier to audit than allowing the conversational agent to infer it from scattered timestamps. The customer can still receive a natural explanation of the result.

Ada’s configuration guide⁵ describes how the runtime can pause a Playbook for a knowledge question, respond to a changed intent or exit for a human request. It also documents controls that alter those defaults. Test this behaviour deliberately. A customer asking what the replacement warranty covers should be able to receive an explanation without losing the original task; a customer asking for a person should reach the intended support route.

Test the entry point as well as the steps

The test and publish guide⁶ distinguishes testing a Playbook in isolation from testing whether the full agent selects it. Those answer different questions. A flawless replacement flow is of little use if the agent launches it for a refund request. Build examples with overlapping language, incomplete information and a change of mind, then check both selection and execution.

For a limited launch, inspect the result in the fulfilment or helpdesk system alongside the conversation. Did the right record change? Did the receiving teammate get the delivery status and customer’s requested outcome? That operational read-back is more informative than judging the final message alone. Keep the failed examples as regression cases so a later improvement to one branch does not break another.

04 / PricingHow should buyers approach Ada pricing?

Ada’s public pricing route⁷ leads to a sales discussion rather than a complete self-service price card. We did not find a public numerical rate that would justify an exact subscription comparison on 15 September 2026. The table therefore separates what the public product establishes from the commercial details to request. These are purchasing questions, not claims that every item incurs an extra fee.

A useful request for a quote describes the proposed service workload: channels, recurring intents, required systems, languages and the team responsible for maintenance. Ask for an explicit billing unit and the treatment of retries, unresolved conversations, handoffs and peak demand. A per-conversation offer and a per-resolution offer cannot be compared fairly without knowing how each counts the same customer journey.

Model the cost against completed work rather than total incoming messages. For example, a replacement investigation can reduce repetitive lookup work while still ending with a human decision. That may be worthwhile even if the case is not fully automated. Conversely, a low-cost answer that creates another contact can be expensive in practice. Include internal content maintenance, integration work and quality review in the business case, because these remain real activities under any subscription structure.

05 / DistinctionsWhy structured steps matter to the service team

Ada’s current authoring model makes it possible to discuss different kinds of control explicitly. A fixed customer statement, a variable extracted from conversation and a backend action have different failure modes. That helps a service owner decide which parts should be flexible and which should depend on exact system values. The value is understandable behaviour, not the mere presence of a visual or conversational editor.

There is also a maintainability benefit in reusing an appropriate child Playbook for a common task, such as collecting context before a handoff. Reuse works best when the shared task has a stable contract: clear inputs, expected outputs and a named owner. Otherwise a change intended for one team can unexpectedly affect another. Ada’s documented dependency view is useful context for managing those relationships, but the team still needs a review convention.

06 / QuestionsWhat should the implementation review resolve?

The Ada trust centre⁸ provides the starting point for security and assurance material. Review the actual data path for your intended workflow, including conversation records, customer variables, API access and the human helpdesk. The key operational question is whether the agent sees the least information needed for the job and whether its tools have only the authority that the job requires.

A specific documented limitation deserves attention: Coaching can influence which Playbook is selected but does not govern behaviour during execution in the same way. Changes inside a Playbook should be made in that Playbook. This prevents an easy maintenance mistake: updating general guidance and assuming a detailed flow has adopted the new rule. We have not verified private deployment quality, so selection, policy adherence and successful external actions remain pilot questions.

07 / DecisionChoose a process that can become a maintained service

The most useful Ada evaluation starts with a real support procedure that has clear entry conditions and an observable ending. Build the knowledge, personalisation and tool connections around that procedure. Then judge the customer journey and the maintenance work together. A successful pilot should leave the team with a service it understands well enough to change, rather than an impressive conversation nobody feels responsible for operating.