I'm having issues with variables being passed in and used correctly by the assistant. We are passing in certain keys, values, and addresses and the assistant is not using them. 019eaf7e-f4c4-744e-9fe8-1733c0e38e0a Didn't even try to use the tool 🙁 019eae73-c11a-7ddc-abec-c9209f75e049 no or little hallucinations on this call. still not perfect usage. 019eae76-c35f-7446-b075-6d631131015c said different address than variable. We expect them to use the catalog and send the id in the job tool. The assistant makes up addresses and service types. Doesn't use our ids. Other weird issues.

Hi, Thanks for sharing those call IDs. I pulled the logs and found the root cause. Your system prompt correctly tells the assistant to use workspaceId, referralId, and causeCatalogJson from variableValues, but the actual values from those variables are never injected into the text the LLM receives. The model is being told those values exist but it cannot see what they are, so it falls back to guessing. In Vapi, variable values only appear in your prompts if you reference them using double curly braces. You need to explicitly inject them somewhere in your system prompt where the model can read them, for example: Workspace ID: {{workspaceId}} Referral ID: {{referralId}} Cause catalog: {{causeCatalogJson}} Once those placeholders are in the prompt, the LLM will receive the real values on each call and can use the catalog to select the correct causeId and serviceType IDs, and will use your actual workspaceId and referralId when calling the tool. The call on 019eaf7e not attempting the tool at all is consistent with this too. If the model never receives a valid catalog to parse, it may never reach the point of building a complete set of required fields, so it holds off on calling submit_job_form_secure. Give that change a try and let me know how the next test calls go. Happy to help review your updated prompt if needed.

Thanks so much! I sure will.