Thanks — I hear you: your deployed voice agents are hallucinating frequently, and you want clear, practical guidance to reduce that. Below I’ll walk through focused strategies you can implement now, with concrete examples and next steps. Quick summary of the approach • Ground responses with real data and tools so the model doesn’t invent facts. • Constrain scope by splitting responsibilities across specialized agents and adding explicit guardrails. • Make memory/state deterministic using structured session data. • Continuously test, evaluate, and monitor to catch regressions early. Practical steps you can apply 1) Give the agent reliable tools for facts (use external data) • Add function-style tools the agent must call to retrieve facts (search KB, query APIs, fetch documents). • Example pattern:

@function_tool()
async def search_knowledge_base(query: str) -> str:
    return await query_my_db(query)

• Benefit: the agent returns verified data instead of fabricating answers. 2) Break the agent into specialized roles • Create small agents with single responsibilities (FAQ agent, billing agent, escalation agent). • Use explicit handoffs so each agent uses only the instructions and tools for its domain. • Example: a

SupportAgent

handles account questions and calls

fetch_account_data

tool only. 3) Strengthen instructions and guardrails (prompt engineering) • Add firm, short rules in the system prompt: ◦ “If you are not certain, say ‘I don’t know’ and offer to fetch data.” ◦ “Never invent internal process or customer data.” ◦ “When in doubt, call the

search_knowledge_base

tool.” • Add refusal templates for out-of-scope requests to avoid speculation. 4) Use structured session state instead of free-form history • Store critical facts in

session.userdata

(IDs, verified account fields, previously-confirmed facts). • Make the agent read

session.userdata

first rather than searching conversation history. • This reduces mistaken recall and invented details. 5) Implement deterministic verification steps before answering • Require the agent to validate uncertain facts: a. Check

session.userdata

and local tools. b. If not found, call a data-fetch tool. c. If still uncertain, reply with an explicit uncertainty statement and a safe next step (e.g., ask to confirm, escalate, or offer to look it up). • Example reply when uncertain: “I don’t have that on hand — can I look it up from your account now?” 6) Add automated evaluation and monitoring • Run evaluation agents that simulate typical user queries with known correct answers and flag deviations. • Log incidents where the agent provides unsupported claims; use those logs to refine prompts/tools. • Create small behavioral tests that verify the agent refuses to answer when it lacks evidence. 7) Improve input quality (STT → LLM pipeline) • If using STT, reduce noise by using punctuation/clarification steps or re-asking quick clarifying questions before answering. • When confidence from STT is low, have the agent ask a short clarification rather than answer immediately. 8) Tune model selection and inference strategy • If you have multiple model options, test more conservative models or configure decoding settings that reduce creative completions (lower temperature, use beam search where supported). • Consider realtime/voice-optimized models designed for fewer hallucinations in conversational contexts. 9) Rollout and feedback loop • Start with a small percentage of traffic routed to the updated agent (canary). • Measure hallucination rate (e.g., % of responses flagged as inaccurate by evaluators or users). • Iterate on tools, guardrails, and prompts based on the metrics. Short checklist to get started (high-impact, quick wins) • Add at least one data-fetch tool for the agent to use for factual answers. • Update system prompt with explicit “don’t hallucinate” guardrails and uncertainty templates. • Store important verified user/account info in structured

session.userdata

. • Add a simple evaluation test that checks factual responses for 10 high-frequency queries. • Deploy to a small percentage of users and monitor logs. If you want, I can help next by: • Reviewing one of your agent prompts and suggesting guardrail wording. • Drafting a small

search_knowledge_base

tool and a sample handoff flow. • Creating a short evaluation test suite for your top 10 user intents. Which would you like me to start with? Sources: External data and RAG | LiveKit Documentation | Building multi-agent architectures with LiveKit agents | LiveKit | Prompting guide | LiveKit Documentation | Troubleshooting STT not picking up utterances | LiveKit | Testing and evaluation | LiveKit Documentation