At a glance
What you need to know.
Design a conversational system around the user's intent and the authority of the result. Answering from approved material, collecting structured information and changing a record are different patterns. Make sources, confirmation and handoff behavior explicit so a fluent response does not conceal uncertainty or incomplete execution.
Separate answers from business actions
A knowledge answer can cite approved information without changing a record. A guided intake collects structured fields, while a transactional assistant proposes or executes an authorized action. Identify which pattern each intent needs. An interface may combine them, but the authority and acceptance rules should remain distinct. For a question about order status, retrieve only the user's authorized order; for changing an address, validate the account, permitted order state and confirmation. A friendly conversation does not make an uncertain identity or unsupported operation acceptable.
Ground knowledge answers in approved sources
Choose source owners, access scope, freshness and update procedures before building retrieval. Show relevant references when the task needs evidence and let the system acknowledge missing information. A retrieved passage can be stale, irrelevant or contain misleading instructions. Keep application rules independent from source text. Evaluate questions whose answer is absent, ambiguous or restricted to another role. A correct-looking answer without an appropriate source may still be unsuitable for support use. Version the sources and retrieval settings with the evaluation cases so a changed answer can be investigated.
Collect structured fields with usable correction
For intake, define required fields, allowed values and the minimum information the receiving team needs. Ask for missing details in the conversation, then show a concise structured review before submission where appropriate. Keep edits attached to the same draft rather than creating a new task every time the user corrects a value. Avoid requesting sensitive information that the task does not require. Validate fields on the server and preserve entered data when saving is unconfirmed. A model extracting a date or identifier does not establish that it is valid for the destination.
Confirm effects and report real progress
For an action, show the target record, proposed change and any conditions that affect it. Bind confirmation to the reviewed proposal and revalidate authority at execution. Distinguish saved, queued, accepted and failed using the destination's contract. In an illustrative address change, the order may become locked while the conversation is open; explain the conflict and offer the supported next step instead of falsely confirming the update. Store a stable reference for retries. A generated statement saying done is not evidence that a write occurred.
Make human handoff preserve useful context
Define when the conversation hands off: unsupported intent, missing evidence, policy exception or repeated failure. Give the receiving role the permitted structured information, source references, current state and next question, rather than an unrestricted transcript by default. Tell the user whether a durable task was saved and what remains unresolved. A handoff needs an owner and a supported queue; saying contact support without transferring the needed context can simply repeat the user's work. Test staff absence and incomplete intake as part of the journey.
Evaluate the interaction as a complete task
Use representative questions, corrections, ambiguous wording, unauthorized records and hostile source text. Include users who change intent mid-conversation and cases where a dependency is unavailable. Measure accepted task completion, wrong answers, false success messages, rework and handoff quality. Review language and accessibility needs for the intended audience. Start with a limited set of supported intents and make their boundaries visible. Expanding the knowledge base or adding a transactional tool requires a new access and acceptance decision, even when the chat interface itself stays familiar.
Keep evidence and execution under separate authority
An AI-generated proposal is not authorization to perform a business action. Validate record ownership, tool arguments and the permitted operation outside the model using the actual requesting identity. Restrict tools to the agreed task and require a reviewed path for privileged or irreversible decisions. Treat retrieved documents and tool responses as untrusted content that can contain misleading instructions. Preserve the evidence a reviewer needs with appropriate access, rather than exposing raw sensitive inputs in general logs. OWASP's prompt-injection guidance supports layered controls; retrieval, fine-tuning and a carefully written prompt do not establish an enforceable security boundary.
Before you start.
- Is the intent an answer, intake or authorized action?
- Who owns and refreshes the permitted sources?
- Can users correct structured fields without duplicate tasks?
- Does confirmation correspond to accepted destination state?
- Is human handoff durable, scoped and owned?
Common questions.
Should a chatbot answer every question?
No. Define supported intents and approved sources. When evidence is absent, access is restricted or the request requires an unsupported decision, explain the limit and use the owned handoff path. Guessing can create more support work and inappropriate actions.
When should the interface say an action is complete?
When the documented destination contract and stored state establish the promised result. Saved intake, queued execution and accepted change may be separate stages. Show the actual stage and a reference, including an unresolved state after an ambiguous response.