Hi team, We have a query tool for with a kb called 'appointment_types'. We're currently seeing an inconsistent response when the agent calls the tool to retrieve the appointment type. Eg. When the agent queries for checkup, the tool should return the details for the 'checkup' appointment type like in this call id: 019bc537-1510-7332-a862-2c1d5df5d2fe However, the query will occassionally retrieve no results like in this call id: 019bc528-5e5e-799d-9f4b-161ee7f33d94 This happens frequently enough such that we need to find a workaround as the results contain crucial data for appointment bookings. As there's no vis into how the agent is querying the tool with the tool arguments showing '{"knowledgeBaseNames":["clinic_appointment_type"]}' it's difficult to fix any prompt related issues or otherwise. Could I please get assistance triaging how the tool is being called behind the scenes or any other suggestions? Thanks in advance!

To triage how the query tool is being called, navigate to your Vapi dashboard and go to Observe > Call Logs. There, you can review the tool execution section for each call, compare the arguments and results for both successful and failed queries, and identify any discrepancies. This will give you visibility into the tool's behavior and help pinpoint prompt or configuration issues. Example:

1. Go to Vapi dashboard
2. Click "Observe" > "Call Logs"
3. Select the relevant call ID and review the tool execution details

For more, see the [debugging documentation](https://docs.vapi.ai/debugging). Source: - [Debugging voice agents](https://docs.vapi.ai/debugging)

Hey totally get how painful this is, especially since it breaks booking flows. This usually happens when embedding similarity dips due to phrasing, casing, or partial matches, even though the intent is the same. A solid workaround is forcing deterministic lookup (exact key → record) before falling back to semantic search. If you can log raw tool inputs or lock the query schema, you’ll likely eliminate the inconsistency fast. Are these queries coming directly from user speech or being generated by the agent internally? @Jimmy

Thanks for the reply @Jarrah - not sure if deterministic lookup is possible sine a patient might look ask for 'checkup' rather than 'checkup/clean' or any other variation. I'll have a go with logging, that sounds like it would be a helpful next step. They're coming from user speech, which is where the variations would come into play.

Thanks for clarifying, with user speech, variations like “checkup” vs “checkup/clean” definitely explain the inconsistencies. A practical fix is adding a lightweight normalization or alias mapping layer before the KB query, so common variations reliably hit the right record. Combined with detailed logging, we can quickly spot patterns and edge cases, turning these inconsistencies into actionable insights. This approach keeps flexibility for users while stabilizing results for bookings, which is crucial for avoiding missed appointments. If you want, I can jump in directly, set this up, let's discuss more in privatein to get it working fast.. @Jimmy

Hey there, there have been some ongoing rate limit issues from Google Gemini models. Can you try - 1. Use

gemini-2.0-flash-lite

- This model is confirmed working (as of Jan 23) 2. BYOK (Bring Your Own Key) - Users can add their own Google API key to bypass Vapi's rate-limited infrastructure 3. Switch to alternative models - Use GPT-4o mini or other non-Google models (though some customers resist this) Team is working on a fix.