Conversational AI: Trace One Turn Through Six Stages

Conversational AI is software that holds a working conversation with a person, in text or speech, by interpreting what they meant rather than matching what they typed, then answering from data it retrieves and, increasingly, acting on their behalf. That last clause is where deployments live or die.

Our position, and the reason this piece exists: the standard explanation of conversational AI stops one stage too early. "Natural language processing plus machine learning" described the category accurately in about 2018. It does not describe a system that reads your CRM, calls your billing API, and puts a sentence in front of a customer that your company is legally answerable for. A modern conversational turn runs through six stages, and only one of them is a language problem. The other five are access, authority, evidence and cost problems.

The clearest statement of the gap we have seen came from an e-commerce store owner posting on Hacker News in February 2026 under the handle shotwellj. He had deployed agents to handle customer communications; they "started sending wrong information, making promises we couldn't keep." Then the part that matters: when he tried to reconstruct what had gone wrong, he had "no way to prove what the agents actually said." Nothing in his stack failed at understanding language. What failed was stages three, four and six.

The short answer: Conversational AI is a six-stage pipeline (capture, interpret, retrieve, decide, respond, record) and the language model only owns stage two; whether your deployment works is decided by what you let stages three and four touch, and whether stage six can prove it afterwards.

Last updated: July 30, 2026.

We have not run a production conversational AI deployment of our own and are not reporting one here. Everything measured in this article comes from named published research and from practitioners describing their own systems in public, each linked at the point of use.

The Turn Trace. Stage 2 is the language problem everyone describes; stages 3, 4 and 6 are the ones that determine whether the deployment holds.

What conversational AI actually is

Conversational AI is the branch of applied artificial intelligence concerned with systems that carry on a multi-turn exchange in natural language by inferring intent from an utterance, rather than matching the utterance against a fixed script. Practically, that means it can handle a question it has never seen phrased that way before, and it can carry context forward: if you say "and the second one?", it knows what the first one was.

That is the whole definition. Everything else in the category is implementation: voice or text, retrieval or fine-tuning, a customer service widget or a contact centre phone line. The label attached to it varies too: virtual assistant, AI agent, support copilot, digital worker. Those are packaging decisions, and none of them changes what the system reads or what it is allowed to do.

It helps to be precise about the boundary, because vendors are not. A decision-tree bot that says "I didn't catch that, please choose from the options below" is not doing conversational AI, no matter what the pricing page says; it is doing menu navigation with a chat skin. The tell is generalisation. Ask it something adjacent to but outside its scripted paths. A scripted system falls back. A conversational system attempts an answer — which is both the capability you wanted and, as the rest of this article argues, the risk you inherited.

The word "conversational" also does more work than people notice. Human conversation has a rhythm, and it is measured. Research led by Tanya Stivers at the Max Planck Institute for Psycholinguistics, published in PNAS in 2009, sampled ten languages from indigenous communities to major world languages and found a universal pattern: speakers avoid overlapping talk and minimise the silence between turns, with cross-language average gaps varying only within about 250 milliseconds of the shared mean. That finding predates the current technology by fifteen years, and it sets the bar every voice deployment is quietly judged against. It is not a UX preference. It is what humans are built to expect.

The Turn Trace: six stages between a sentence and an answer

A single conversational AI turn passes through six stages: capture, interpret, retrieve, decide, respond, record. Naming them separately is the whole trick, because every stage has a different owner, a different failure mode, and a different control. Bundle them into "the AI" and you cannot fix anything; separate them and each failure has an address. We call the exercise of walking one real turn through all six the Turn Trace, and the diagnostic version of it is at the end of this article.

Two observations follow immediately, and they are the reason we think the standard explainer is misleading rather than merely incomplete.

First, stage 2 is the language model, the part the entire category is named after, and it is the only stage where "natural language processing plus machine learning" is the right description. Stages 3 and 4 are permission systems. Stage 6 is an evidence system. You can swap the model underneath one of these deployments in an afternoon. You cannot swap the answer to "what is this thing allowed to read about a customer" in an afternoon, because it is a decision about your data, not your vendor.

Second, the stages fail independently, which means they must be tested independently. A support conversation can be perfectly understood (stage 2 fine), grounded in the wrong article (stage 3 broken), and delivered in flawless prose (stage 5 fine). To the customer this looks like one failure: the bot lied. To you it is one stage, and a fixable one.

Stages 1 and 2: capture and interpret

Capture and interpret are the stages the field has genuinely solved to a usable standard, and the stages that consume most of a build team's attention anyway. In text channels capture is trivial. In voice it is an engineering problem with a hard budget, because the Stivers finding above means a customer feels a gap before they consciously notice one.

The voice path is a chain: voice activity detection, then automatic speech recognition, then the model, then text-to-speech, and every link spends milliseconds you do not get back. A 2025 arXiv paper on a low-latency telecom voice agent pipeline built exactly this stack, using streaming automatic speech recognition, a 4-bit quantized domain-specific language model and real-time speech synthesis. It evaluated the result it against 500 human-recorded telecom questions drawn from RFCs. Its headline result is stated as real-time factors below 1.0 for the speech recognition, language and synthesis components, which is the minimum bar for interactive use: each component finishes its work faster than the speech it corresponds to takes to say. Below 1.0 is not "fast". It is "not falling behind". The paper is a preprint, and the models are the authors' own, so read it as an engineering report rather than an independent benchmark.

This is the part of conversational AI where a ten-minute technical walkthrough is worth more than a page of prose. LiveKit, whose infrastructure a lot of production voice agents run on, published a clear breakdown of the voice pipeline and where the latency actually accumulates:

Stage 2, interpretation, is where the language model earns its keep. It takes the captured text plus the conversation so far plus your system instructions, and produces something structured: what the user wants, which entities they named, and what state the conversation is now in. Older systems did this with explicit intent classifiers and entity extractors, and the vocabulary survives — intent recognition, entity extraction, dialogue management. Current systems fold most of it into one model call, which is why the older architecture diagrams look busier than the code does now.

The failure mode of stage 2 is specific and worth naming, because teams misattribute it constantly: the right sentence, the wrong intent. "I want to cancel" is understood perfectly and mapped to subscription cancellation when the customer meant a single order. Nothing about the language was misread. The mapping from meaning to business action was wrong. That failure is not fixed by a better model; it is fixed by narrowing the set of actions the turn is allowed to reach — which is stage 4, and which is why the stages are worth separating.

Stage 3: retrieve, the stage that decides whether the answer is true

Stage 3 is where the system fetches the facts its answer will rest on: knowledge-base articles, the customer's own record, a policy document, a shipment status. It is the stage that most decides whether the answer is right, and it gets the least attention in explainers, because it is not glamorous: search, plumbing and permissions.

Two numbers frame how well it works. The first is how much of the answer stays anchored to retrieved evidence even when a team builds a serious pipeline for exactly that purpose. A 2026 arXiv study on domain-grounded tiered retrieval built a four-phase pipeline specifically to intercept ungrounded claims — intrinsic verification with early exit, adaptive search routing, context filtering, then regeneration with atomic claim-level verification — and evaluated it across 650 queries drawn from five benchmarks including TimeQA v2, FreshQA v2 and TruthfulQA. Win rates against zero-shot baselines peaked at 83.7% on TimeQA v2. Groundedness scores held between 78.8% and 86.4% across what the authors call factual-answer rows. They identify a persistent failure they name "False-Premise Overclaiming", and close by recommending pre-retrieval answerability checks to narrow what they call the reliability gap in conversational AI. It is a preprint rather than a peer-reviewed result; treat the numbers as indicative of the ceiling, not as a certified one.

Read those numbers the way a buyer should. That is a system engineered end to end for groundedness, and somewhere between one answer in five and one in seven still is not fully anchored to its evidence. Any plan whose risk model assumes stage 3 approaches certainty is not a plan.

The second number is that stage 3 is now measurable on enterprise-shaped data, which was not true two years ago. The WixQA benchmark, released as a 2025 preprint with its datasets under an MIT licence, is built from Wix.com customer support interactions and ships alongside the actual knowledge-base snapshot the answers came from: 200 real user queries with expert-authored multi-step answers, 200 expert-validated pairs distilled from user dialogues, and 6,222 pairs generated systematically from every article in the knowledge base. Publishing the corpus with the questions is the methodological point. Without the snapshot you can measure whether the model sounds right; with it you can measure whether the retrieval found the right document and whether the answer stayed inside it.

Then there is the part of stage 3 nobody puts on an architecture slide: retrieval scope is an access-control decision wearing an engineering costume. Whatever you index, the conversational system can surface — to whoever is talking to it. Point it at "the support knowledge base" and you have made an implicit claim that every document in that store is safe to paraphrase to an anonymous customer. Point it at the CRM to personalise answers and you have connected an unauthenticated text box to a database of other people's personal data, mediated only by a prompt.

A practitioner building voice agents described this collision precisely. Posting on Hacker News in December 2025, aperi, who was pitching his own retrieval product, so read the claim with that in mind, wrote that spending "200ms+ on a Vector DB lookup" was eating the voice latency budget, and that stateless retrieval meant their agents "were constantly hallucinating permissions and accessing data they shouldn't". Hallucinating permissions is a good phrase for a real thing. The model does not know what it is entitled to see; it only knows what came back.

That is also why stage 3 is the main entry point for attacks. The OWASP GenAI Security Project's LLM01:2025 Prompt Injection entry distinguishes direct injection, where the user's own input alters behaviour, from indirect injection, where the system "accepts input from external sources, such as websites or files" whose content changes what the model does. A retrieved document is external content. OWASP lists the possible consequences plainly, including disclosure of sensitive information and "providing unauthorized access to functions available to the LLM", and states directly that retrieval-augmented generation and fine-tuning "do not fully mitigate prompt injection vulnerabilities". If your mitigation plan for stage 3 is "we use RAG", the people who wrote the standard have already told you that is not a mitigation. Masking sensitive fields before they reach a model is a separate control, and one we have written about in our earlier analysis of inline data-loss prevention at the gateway.

Stage 4: decide, and the line between answering and acting

Stage 4 is where the system chooses between two very different outcomes: return words, or take an action in a real system. Issue the refund. Update the address. Cancel the order. Once a conversational AI deployment can do the second thing, it stops being a communication channel and becomes a credentialed actor inside your business — with a token, a scope, and the ability to change records.

The size of that step is easy to understate because the code change is small. Adding a tool to a conversational system is a schema and a credential. The consequence is that a sentence typed by an anonymous member of the public can now cause a write. Every control that matters at stage 4 follows from taking that sentence seriously: which tools are exposed to which intents, whether the tool is scoped to this customer's own records or to the table, what value threshold triggers a human approval, and what the system does when it is uncertain.

We have covered this boundary in depth rather than re-derive it here. Our analysis of where the write-access line falls between chatbots and agents works through the tiers and the controls each one needs, and our piece on how agents actually work — the loop, the tools, and the reach covers how a model chooses a tool call and what it can touch when it does. The short version for this article: read access and write access are different products with different review requirements, and most deployments that got into trouble had crossed that line without anyone recording the decision.

If you take one rule from this section, take this one. Every tool exposed to a conversational turn needs three things written down before it ships: the intents allowed to reach it, the scope it runs under, meaning this customer's own records rather than the table, and the value or sensitivity threshold above which a person approves. Any tool missing one of the three is not scoped, it is merely unused so far.

One control at stage 4 deserves a caveat, because it is oversold. "A human approves the action" is genuinely the strongest guardrail available, and it is also the one most likely to decay in production: approval queues that arrive faster than they can be read become rubber stamps, and a rubber stamp is a log entry, not a control. We have written about when approval is actually control and when it is theatre. Design the approval for the volume you will have in month six, not the volume in the pilot.

Stage 5: respond, where fluency is mistaken for accuracy

Stage 5 turns retrieved facts and tool results into the sentence the customer reads or hears. It is the only stage the customer perceives, and the mismatch between how good it looks and how much it guarantees is the central perceptual problem of the whole category.

NIST names the failure directly. Its Generative AI Profile, NIST AI 600-1, lists confabulation among the risks unique to or exacerbated by generative systems, defining it as "the production of confidently stated but erroneous or false content" — noting in a footnote that the colloquial alternative, "hallucination", itself anthropomorphises the system. The same document lists a second risk with a bland name and sharp teeth: Human-AI Configuration, meaning arrangements between a human and a system that lead the human to inappropriately anthropomorphise it, or to experience "automation bias, over-reliance, or emotional entanglement". Conversational interfaces are the most anthropomorphising interface ever shipped at scale. The confident register is not a bug in the wording; it is the product working as designed, applied to content that happened to be wrong.

This is where the legal exposure lands, and there is a decided case to point at rather than a hypothetical. In February 2024 a Canadian tribunal ordered Air Canada to compensate a passenger, Jake Moffatt, after its chatbot gave him incorrect guidance on bereavement fare refunds. The Guardian's report, which describes the case as the first of its kind in Canada, records that the airline argued the chatbot was a "separate legal entity" responsible for its own actions, and that tribunal member Christopher Rivers rejected it: "It makes no difference whether the information comes from a static page or a chatbot." Air Canada was ordered to pay C$650.88 in damages, plus C$36.14 in pre-judgment interest and C$125 in fees.

The award is small. The holding is not. What a conversational AI system says in stage 5 is a representation by your company, and "the model generated it" is not a defence anyone has yet made work. Note also which stage caused it: the tribunal's problem was that a customer had no way to know which surface was authoritative. That is a stage 3 grounding failure that became a stage 5 liability.

Stage 5 is also where a regulatory obligation applies specifically to conversational systems, not to AI generally. Article 50(1) of the EU AI Act requires that AI systems "intended to interact directly with natural persons" be designed so that those persons are informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person in the circumstances (full text; that page is a machine translation of the official text, so verify wording against the Official Journal before relying on it for compliance). The timing is immediate rather than distant: Article 113 sets the Regulation's general application date at 2 August 2026, with a short list of exceptions that does not include Article 50. In practice: the disclosure is a design requirement at stage 5, not a legal footer, and "obvious from context" is a judgement your counsel makes, not your vendor. Deployment-side obligations more broadly are covered in our guide to EU AI Act compliance for deployers.

Stage 6: record, the stage every explainer omits

Stage 6 writes down what happened: the utterance, the retrieved documents, the tool calls attempted, the tool calls refused, the response, the model used, the cost. No mainstream explanation of conversational AI includes this stage, which is exactly why the store owner quoted at the top of this article had a problem he could not solve.

Re-read his situation with the stages named. His agents sent wrong information, which is some mix of stages 3 and 5. They made promises the business could not keep, which is stage 4: an intent granted more authority than it should have had. But the sentence that made his post worth citing is about neither: he had "no way to prove what the agents actually said", with logs scattered across services. That is a stage 6 absence, and it is the one that turns a bounded incident into an unbounded one. Without a record you cannot tell a customer what happened, cannot tell a regulator, cannot tell whether the same fault is still live, and cannot tell whether it happened a hundred times before you noticed.

Three properties separate a real stage 6 from application logs:

The refusals row is the one teams skip and later regret. If your conversational system declined to process a refund above a threshold four hundred times last quarter, that is the strongest evidence you have that the threshold is doing work — and if you only log completions, you have thrown it away. We take the same view in our earlier analysis of audit trails and proving what an agent actually did, and it is why our own observability and audit surface records refused calls alongside executed ones.

A worked trace: one refund question, end to end

Abstractions about stages are cheap. Here is one conversational AI turn, traced. The scenario is composed to illustrate the mechanism — it is not a customer engagement of ours.

A customer opens a support chat on a retailer's site and types: "my order came damaged, can I get money back on the second item".

Stage 1 — capture. Text channel, so capture is the message plus session metadata: not logged in, second message of the conversation, web widget. Cost so far: nothing. Risk so far: nothing. Note the one fact that will matter later. This person has not authenticated.

Stage 2 — interpret. The model resolves intent to refund request, partial, damage reason, extracts the entity second item, and resolves "the second item" against the first turn, where the customer named an order number. Two ambiguities survive: whether "money back" means refund or store credit, and whether the customer is entitled to speak about this order at all. A well-built system carries both forward as unresolved rather than picking. This is the point where most stage-2 failures happen — not misunderstanding the words, but silently resolving an ambiguity in the direction that makes the conversation flow.

Stage 3 — retrieve. Two retrievals, and they have different risk profiles. The first is policy: fetch the damaged-goods clause from the returns knowledge base. Low risk, public information, and the customer could have read it themselves. The second is record: fetch the order, its line items and its delivery status. That retrieval touches personal data belonging to a specific customer, requested by a browser session that has proved nothing. If your design lets stage 3 fetch that record on the strength of an order number recited in chat, you have built an enumeration oracle with a friendly tone. The fix is not a better prompt. It is that identity resolution precedes record retrieval, and the system says so out loud: I can explain the policy now; to look at your order I need you to sign in.

The objection to that is real and worth stating: forcing a sign-in mid-conversation costs you completions, and every customer experience team knows it. But the split above is what makes it affordable. Policy questions get answered immediately, with no friction and no login; only the record lookup is gated. Teams that gate the whole conversation pay the full UX cost; teams that gate nothing pay it later, once.

Stage 4 — decide. Assume identity is now established. The system has a refund tool. Does this turn get to call it? The honest answer for most retailers is: only inside a scope written down in advance. Say refunds up to a stated value, on orders under a stated age, with damage reason, on the customer's own order, are auto-approved; everything else drafts the refund and routes it to a human queue. The important part is not where the threshold sits, it is that the threshold exists as configuration rather than as model judgement. A model asked "should I refund this?" will answer. It has no basis for the answer.

Stage 5 — respond. The reply states the policy, confirms the specific action taken or queued, gives a timeframe, and, where Article 50(1) bites and disclosure is not already obvious, makes clear the customer is talking to an AI system. It does not say "your refund has been processed" when the truth is "a refund has been queued for approval". The gap between those two sentences is where a large share of complaints about these systems live, and it is a wording decision, which means it is cheap to get right.

Stage 6 — record. One record for the turn: the utterance, the resolved intent, both retrievals with document identifiers, the identity check and its result, the refund tool call with its arguments and outcome, the approval route, the response text, the model, and the cost. If the refund had been declined by policy, the decline is in the record too. That record is what lets you answer, six weeks later, a question in the form: did we tell this customer they would get money back, and on what basis?

Total stages where the language model was the deciding factor: one. Total stages where a written-down policy was the deciding factor: three.

What conversational AI is not

The explainer genre is bad at negative definitions, and the negatives are where buyers get misled. Four boundaries:

It is not a scripted chatbot with better copy. The distinction is generalisation, not tone. If the system cannot handle an unseen phrasing of a known question, adding a friendlier fallback message does not move it into this category. This matters commercially because the two things have different failure profiles: a scripted bot fails visibly and annoyingly, a conversational one fails invisibly and confidently.

It is not search with a chat interface. Search returns documents and leaves the reader to judge. Conversational AI returns an assertion and takes the judging on itself. That is the whole value proposition and the whole risk transfer in one move. Every percentage point of groundedness you do not have at stage 3 becomes an assertion your company made.

It is not an autonomous agent, unless you gave it tools. A conversational system that only reads and answers has a bounded blast radius: wrong information, which is bad, and recoverable. One with write scopes has an unbounded one. The same widget, the same model, the same prompt — one added schema apart. Treating those as one category is the most expensive conflation in this space.

It is not a person, and pretending otherwise is now a named risk. NIST's Human-AI Configuration entry exists because anthropomorphising these systems changes how people rely on them. Naming your bot, giving it a personality and an avatar is a product decision with a documented risk attached, and in the EU it collides with a disclosure obligation.

Where the technology actually stands in 2026

The honest summary is that adoption has run ahead of reliability, and both are measured.

Stanford HAI's AI Index 2026 report puts organisational adoption of AI at 88%, and generative AI at 53% population adoption within three years, faster, it notes, than the personal computer or the internet. On capability, the same report describes what researchers call the jagged frontier: a model can earn a gold medal at the International Mathematical Olympiad while the top model reads analog clocks correctly just 50.1% of the time. On the agentic side, task success on OSWorld — which tests agents on real computer tasks across operating systems — leapt from 12% to about 66%, "though they still fail roughly 1 in 3 attempts on structured benchmarks".

Hold those two facts together, because they are the state of the art: a fourfold improvement in a year, and a one-in-three failure rate. Both are true. A deployment designed on the first number and not the second is a deployment that will surprise its owners.

The Index's responsible-AI findings sharpen it further. Documented AI incidents rose to 362, up from 233 in 2024. Reporting on responsible-AI benchmarks remains, in its word, spotty, while capability benchmarks are reported by almost everyone. And it cites recent research finding that improving one responsible-AI dimension, such as safety, can degrade another, such as accuracy — which is the empirical version of every argument your product and risk teams are about to have.

A note on what is missing from that table. Market-size and adoption forecasts for conversational AI from Gartner and Forrester are quoted in almost every article on this topic; Gartner's pages returned 403 to us and the underlying reports are paywalled, so we could not verify a single figure at source and have excluded all of them rather than repeat a number we could not read. Reddit, which would ordinarily supply practitioner voices for a topic like this, was unreachable throughout, so the field voices here come from Hacker News and skew technical relative to the customer-service audience most affected.

Do customers want this? The honest version

Vendor pages tend to assert that customers prefer conversational AI self-service for routine issues. The measured public sentiment is more divided than that, and the honest answer is that it depends entirely on whether the system resolves the issue.

Pew Research Center's April 2025 survey of the US public and AI experts found 51% of US adults more concerned than excited about increased use of AI in daily life, against 15% of the AI experts surveyed — and that concern among the public has grown since 2021. Both groups, Pew notes, want more personal control over how AI is used in their lives and worry that regulation will fall short. That is not a mandate for shipping a conversational front door and calling it customer preference.

And yet the counter-case is real, and worth taking seriously rather than dismissing. A commenter posting as jlokier described in May 2026 what he called the best customer support experience he had ever had — from an AI chatbot. He had opened the chat on an EV charger supplier's site with a deliberately non-standard request involving reconfiguring an installed public unit and intercepting its network traffic, expecting to be escalated to a human over days or weeks. Instead the first response answered every part of the question, including the parts he had left implicit.

Both things are true, and the reconciliation is not mysterious. People do not have a preference about the channel; they have a preference about resolution. A system that answers the question is better than a queue. One that confidently answers it wrongly is worse than a queue, because it costs the customer the time plus the trust. Which of those you ship is decided at stage 3 and stage 4, not at stage 5 where the personality lives. Customer experience teams tend to own stage 5 and to be handed stages 3 and 4 as fixed constraints, which is roughly the wrong way round.

Run a Turn Trace on your own system in one sitting

If you already have a conversational AI deployment, or a pilot, this takes about ninety minutes and does not require engineering time. Pick one real conversation from last week, ideally one that went wrong, and fill in the six rows.

1. Capture. What channel, and was the input text or speech? If speech, what was the measured end-to-end latency from the customer finishing speaking to the first audio back? Write the number, not an impression.
2. Interpret. What intent did the system resolve, and what did the customer actually want? If they differ, note which ambiguity got silently resolved.
3. Retrieve. List every data source this turn read. For each, answer one question: would you be comfortable if the full contents of that source were readable by whoever was on the other end of that conversation? Any source where the answer is no needs an identity check ahead of it.
4. Decide. List every tool this turn could have called, not just the ones it did. For each, note whether the scope is written down as configuration, and what the value or sensitivity threshold for human approval is. "The model wouldn't do that" is not an entry.
5. Respond. Read the actual response aloud. Does it distinguish what has happened from what has been requested? Does it disclose that the customer is talking to an AI system, where that is required and not obvious?
6. Record. Try to reconstruct all of the above from your logs alone, without asking anyone. Time how long it takes. If you cannot do it, you have found your highest-priority gap, and it is not a model problem.

The output is a one-page table with six rows and, usually, two or three empty cells. The empty cells are the roadmap. Our prediction, which the exercise will confirm or refute for you rather than for us, is that the gaps land in rows 3, 4 and 6, the stages nobody was assigned, while rows 1 and 2, the ones teams arrive braced to fix, come back clean.

The Turn Trace is deliberately not a maturity model. It produces no score. Scores invite arguing about the rubric; a table with empty cells invites filling them.

What still goes wrong when all six stages are right

This section exists because the previous fourteen might read as though the stages are the whole problem. They are not.

Groundedness has a ceiling, and it is not 100%. The tiered-retrieval study above topped out at 86.4% groundedness with a pipeline built for nothing else, and named False-Premise Overclaiming as a residual failure — the system answering a question that contained a false assumption instead of challenging the assumption. Plan for a residual error rate. Decide in advance which conversations are allowed to carry it.

Prompt injection is not solved, by anyone. OWASP states plainly that retrieval and fine-tuning do not fully mitigate it. Any conversational system that retrieves content it did not author is exposed, and any system with tools converts that exposure into action. This is a live research area, not a checkbox.

Safety and accuracy can trade off. The AI Index's citation of research showing that improving one responsible-AI dimension can degrade another means "make it safer" and "make it more accurate" are not the same instruction and sometimes conflict. Someone has to own that trade-off explicitly. If nobody does, it gets made implicitly by whoever tunes the prompt last.

Measurement is genuinely hard on your own data. Benchmarks like WixQA exist because evaluating a conversational system requires the knowledge-base snapshot as well as the questions. Most companies do not have a versioned corpus snapshot to evaluate against, which means their "it works well" is an impression. Building the evaluation set is unglamorous and is usually the thing that unblocks a stalled pilot.

We have not tested this ourselves. Restating the note at the top: LeapForce has not run a production customer-facing conversational AI deployment and reports no first-hand latency, containment or accuracy figures here. Every number in this article is attributed to a named published source, and where we could not reach a source we said so rather than working around it. Treat the Turn Trace as a structure we argue for, not as a result we measured.

And the honest uncertainty about the framework itself. The six stages are a decomposition, not a law. A system using an end-to-end speech model collapses stages 1, 2 and 5. A system with no retrieval has no stage 3 and a much smaller problem. The value of the decomposition is that it gives each failure an owner; where it stops mapping to your architecture, change the map.

The layer a conversational deployment implies

Once you have run a Turn Trace, the shape of what is missing is usually the same. Stages 3, 4 and 6 are not features of a conversational AI product; they are properties of the layer underneath every AI system in the company. Which data a conversation may read, which actions it may take, who owns the agent doing it, what got recorded, and what it cost — those questions have the same answers whether the interface is a support widget, an internal assistant, or a workflow with no conversation in it at all. That layer is what we build.

Concretely, that means an agent gets a non-human identity with a named owner, minimum scopes and a budget before it is shared with anyone, following the coworker lifecycle published on our AI Coworkers page: Build, Scope, Review, Share, Improve. The Review step exists so that "who allowed this agent?" always has an answer. It means data protection and routing decisions happen in the request path at the AI Gateway rather than in each application, and that refusals are recorded alongside executions. One honest caveat: LeapForce does not sell a conversational AI product, a support bot or a contact-centre platform, and per-capability build status on our platform is published as LIVE, IN DEV or ROADMAP rather than claimed uniformly — check the page for the capability you need. If you are choosing a conversational AI vendor, choose one; then ask it the six Turn Trace questions, because the answers are yours to own either way.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.