Conversational AI development combines a language model with state, approved knowledge, business tools, safety controls, and testing. This guide shows what each layer should do and how to build a chatbot that can be evaluated before it reaches users.
AI for chatbots is most useful at the language boundary: understanding a user's request, deciding which approved capability can help, and phrasing a clear response. It should not be the final authority for access control, business rules, payments, or other consequential actions.
A production chatbot therefore needs more than a prompt and a large language model (LLM). It needs conversation state, trusted knowledge, narrowly defined tools, deterministic safeguards, an escalation path, and evidence that the whole system works across real conversations.
What is conversational AI development?
Conversational AI development is the process of building systems that interpret natural-language input and respond over text or voice. An AI chatbot is the user-facing part of that system. The complete application usually includes:
- a channel, such as a website chat, mobile app, messaging service, or phone call;
- a model that interprets requests and generates language;
- state that preserves the useful parts of a multi-turn conversation;
- retrieval that finds relevant passages in approved content;
- tools that read or change data in external systems;
- application code that enforces permissions and business rules; and
- testing, logs, monitoring, and human escalation.
This distinction matters. A model can produce a plausible answer, but your application must decide what information the model may see, which actions are available, and whether an action is allowed.
A practical AI chatbot architecture
Treat the chatbot as a set of separable layers. That makes failures easier to diagnose and lets you change a model without rebuilding the rest of the product.
1. Channel and input handling
The channel receives the user's message and returns the response. Text chat mainly needs session handling, rendering, and authentication. Voice adds speech recognition, speech synthesis, turn-taking, interruption handling, and latency constraints.
Keep channel details out of the core business logic. The same order-status capability, for example, should be callable from web chat or voice without implementing the policy twice.
2. Conversation state
Model requests do not automatically know what happened earlier. Your application must supply or persist the relevant context. OpenAI's current conversation-state guide describes both manually passing prior items and using a durable conversation object.
Do not treat the full transcript as the only state store. Keep important fields explicitly, such as:
- authenticated user ID;
- current task and its status;
- confirmed values, such as an order number;
- permissions and consent;
- tool results that remain valid; and
- whether a human handoff has been requested.
This structured state is easier to validate than asking the model to infer everything from an increasingly long transcript. It also helps control what is retained and for how long.
3. Dialogue policy and orchestration
The orchestration layer decides what happens next: answer directly, retrieve knowledge, ask a clarifying question, call a tool, refuse, or escalate. The model can help choose among these routes, but application code should enforce hard constraints.
For example, the model may recognize that a user wants to cancel an order. Code should still verify identity, check whether the order is eligible for cancellation, require confirmation, and record the result.
4. Knowledge retrieval
Retrieval-augmented generation (RAG) searches an approved knowledge base and gives relevant passages to the model. Use it for product documentation, support procedures, policies, and other factual material that changes independently of the model.
Retrieval is not the same as training the model on your data. During ingestion, systems commonly chunk documents, compute embeddings, and add the resulting vectors to an index. At request time, they embed the query and search that index for relevant passages. OpenAI's retrieval guide explains vector stores and semantic search; Dasha's knowledge-base guide shows how the same pattern is configured for an agent.
Grounding makes the source material available, but it does not guarantee a correct answer. Test whether the right passage is retrieved, whether the answer stays within it, and what happens when no strong match exists.
5. Tools and business actions
A tool lets the model request data or an action from your application. Typical examples include get_order_status, find_available_appointments, or create_support_ticket.
In function calling, your application gives the model a tool name, description, and input schema. The model returns a tool request; your code validates the arguments, executes the operation, and sends the result back for the final response. The OpenAI function-calling guide documents this multi-step flow. Dasha also supports external API tools defined with JSON Schema and webhooks.
Treat every tool request as untrusted input. Validate types and allowed values, authorize the user, apply timeouts, make write operations safe to retry, and log both the request and result. Require explicit confirmation before destructive or costly actions.
6. Safety, privacy, and escalation
Safety is an application design problem, not a final line in the system prompt. Define what the chatbot may discuss, what data it may retrieve, which actions it may initiate, and which situations need a person.
At minimum:
- moderate or otherwise classify inputs and outputs against your policy;
- test prompt injection and attempts to reveal hidden instructions or data;
- isolate untrusted retrieved content from system instructions;
- minimize personal data in prompts, logs, and transcripts;
- provide a clear path to a human when the system is uncertain or the request is consequential; and
- fail closed for actions the application cannot validate.
OpenAI's safety guidance recommends adversarial testing and human review for high-stakes uses. The NIST Generative AI Profile provides a broader framework for identifying and managing generative-AI risks.
7. Observability and evaluation
Chatbot testing must cover conversations, not just isolated responses. Models can produce different outputs for the same input, so a single successful demo is weak evidence.
Build a versioned evaluation set with:
- common successful tasks;
- ambiguous and incomplete requests;
- unsupported questions;
- tool errors and slow responses;
- permission failures;
- prompt-injection attempts;
- handoff scenarios; and
- long, multi-turn conversations.
Score the behavior that matters: task completion, factual support, correct tool selection, argument accuracy, policy compliance, escalation quality, and response time. Review traces when a score changes. OpenAI's evaluation guidance recommends task-specific tests, logging, and continuous evaluation rather than relying only on general model benchmarks.
What should the model decide?
The safest design assigns each kind of work to the component best suited to it.
| Need | Best owner | Example |
|---|---|---|
| Interpret varied language | Model | Map "Where is my package?" to an order-status intent |
| Answer from approved documents | Retrieval plus model | Explain a return policy using the current policy page |
| Read current or private data | Tool plus application code | Retrieve the authenticated user's order status |
| Enforce a business rule | Application code | Decide whether the order can still be cancelled |
| Perform a consequential action | Application code, often with confirmation | Cancel an eligible order after explicit approval |
| Resolve an exception | Human | Handle a disputed charge or policy exception |
The model can coordinate the conversation without becoming the system of record.
How to build an AI chatbot step by step
1. Start with one bounded job
Choose a task you can define and measure, such as answering approved product questions, checking order status, or collecting information for a support ticket. Write down what the chatbot will not do.
Define success before selecting a model. A useful first scorecard might include correct resolution, unsupported-answer rate, successful tool calls, appropriate escalations, and latency by conversation step.
2. Map the conversation and explicit state
List the information required to complete the task, where it comes from, and which values require user confirmation. Design the happy path, but also cover missing details, changed intent, repeated questions, authentication failure, and user requests for a person.
Keep critical state in typed fields. Use the transcript for conversational context, not as a substitute for application state.
3. Add knowledge before adding more prompt text
Put changeable factual material in an owned knowledge source. Give documents clear headings, one topic per section, and enough context for a retrieved passage to make sense on its own.
Test retrieval separately from response generation. If the system finds the wrong passage, rewriting the final-answer prompt will not solve the underlying problem.
4. Add narrow tools
Create one tool per clear purpose. Use descriptive names and constrained schemas. Separate read tools from write tools, and return structured results with explicit error states.
For an order-status chatbot, a safe sequence is:
- authenticate the user in the application;
- collect or confirm the order identifier;
- let the model request get_order_status;
- validate that the user may access that order;
- return a structured status from the commerce system; and
- let the model explain that result without inventing unavailable details.
5. Define failure and handoff behavior
Specify what happens when retrieval finds nothing, a tool times out, authentication fails, or the model is uncertain. A good fallback explains the limitation, preserves useful context, and offers the next valid step. It does not repeatedly rephrase an answer it cannot support.
For high-impact workflows, keep a person accountable for the final decision. Pass the transcript, verified fields, and tool results into the handoff so the user does not have to start over.
6. Test the system as a system
Run the same scenario set against every material change to prompts, models, tools, retrieval settings, and policies. Inspect the full trace: retrieved passages, tool arguments, tool results, state changes, final response, and timing.
In Dasha, you can test text or voice conversations in the browser. Completed conversations can be reviewed in the Call Inspector, including transcripts, model interactions, tool executions, and timing information. Those artifacts are useful for turning real failures into regression cases.
7. Release gradually and monitor real conversations
Begin with a limited audience or a narrow share of traffic. Track failed tasks, weak retrieval, tool errors, escalations, policy violations, abandonment, and latency. Sample complete conversations rather than judging quality from aggregate metrics alone.
Create a regular review loop: classify failures, fix the responsible layer, add the example to the evaluation set, and retest before expanding exposure.
Where Dasha fits
Dasha is a managed platform for teams building conversational AI products, with a current strength in real-time voice. For a chatbot evaluation, our documentation provides a concrete path: embed a web chat or voice widget, connect approved knowledge, add external API tools, test conversations in the browser, and inspect completed interactions.
That path does not replace application design. Dasha supplies the documented conversation channel, knowledge, tools, browser testing, and call-inspection components; your team still owns permissions, business rules, data handling, evaluation criteria, and escalation policy.
Frequently asked questions
What is the difference between a chatbot and conversational AI?
A chatbot is an interface that exchanges messages with a user. Conversational AI is the broader system that interprets language, manages state, retrieves knowledge, calls tools, applies policy, and produces the response. Some chatbots use simple rules; others use a complete conversational AI stack.
Does every AI chatbot need RAG?
No. Retrieval-augmented generation is useful when answers depend on a meaningful body of approved, changing information. A narrow transactional chatbot may rely mainly on tools and structured data. If the required facts fit in a small, stable configuration, a knowledge base may add unnecessary complexity.
When should a chatbot use a tool instead of retrieval?
Use retrieval to find explanatory content in documents. Use a tool for current, private, or transactional data and for actions. An order policy belongs in retrieval; a particular user's order status belongs behind an authenticated tool.
How do you stop a chatbot from taking the wrong action?
Do not let the model directly execute privileged operations. Expose narrow tools, validate every argument, authorize in application code, require confirmation where appropriate, and make risky operations reversible or subject to human approval.
How should an AI chatbot be tested?
Use a repeatable conversation set that includes normal tasks, edge cases, adversarial inputs, tool failures, unsupported questions, and handoffs. Evaluate the full trace and the final outcome, then add production failures to the regression set.