Thanks — this is clear and helpful. I’m responding to your question about how to structure the system prompt and function/tool descriptions so that a “Yes” to the opening greeting “May I speak with {customer_full_name}?” reliably triggers the

correct_customer

tool (instead of being treated as a generic presence check). Summary of the fix • The root cause is prompt ambiguity: the agent’s instructions only list “Am I speaking with {customer_full_name}?” as the identity-verification trigger, and presence-check guidance is too broad. A positive reply to “May I speak with X?” is being treated as ambiguous. • Solution: explicitly teach the model that a positive response to the exact opening connection request counts as identity confirmation, and scope the

correct_customer

tool to the connection (first) phase only. Concrete changes to make 1. Revise the agent’s system prompt (greetings_agent_instructions.txt) ◦ Add the exact greeting wording as a valid trigger. Example wording to add: ▪︎ “When you open with ‘May I speak with {customer_full_name}?’, treat any affirmative reply (e.g., ‘Yes’, ‘Yes, this is me’, ‘This is X’) as an identity confirmation and immediately call the

correct_customer

tool. Do not re-ask ‘Am I speaking with X?’ after receiving this confirmation.” ◦ Narrow the “presence check” guidance so the model does not conflate presence-check replies with identity confirmations. Example: ▪︎ “Presence checks such as ‘Are you still there?’ or ‘Are you with me?’ are not identity checks. Only treat affirmative replies to the initial connection request (‘May I speak with…’) or explicit identity-verification questions (‘Am I speaking with…?’, ‘Can you confirm your full name?’) as identity confirmation triggers.” 1. Update the

@function_tool

docstring for

correct_customer

◦ Make the docstring mirror the system prompt and explicitly reference the exact opening phrase you use. This helps ground the model at the moment the tool should be used. ◦ Example docstring language: ▪︎ “Call this tool when the customer affirms (e.g., ‘Yes’, ‘Yes, this is me’) in direct response to the agent’s opening connection request ‘May I speak with {customer_full_name}?’. This confirmation is sufficient to proceed to identity verification steps. Do NOT call this tool for presence checks or for unrelated confirmations later in the call.” 1. Phase the conversation flow in the system prompt ◦ Define distinct phases so the model knows which actions belong to which phase: i. Connection Phase — Resolve whether you’ve reached the intended person. Positive reply -> call

correct_customer

. ii. Verification Phase — Once

correct_customer

runs, proceed with your identity verification workflow (e.g., ask for DOB, account number) if required. iii. In-Call Phase — Normal call interactions; do not re-invoke

correct_customer

here. ◦ This prevents the model from re-asking or re-invoking the tool after the Connection Phase is resolved. Why these changes work • Explicit mapping between the agent’s exact spoken text and the tool’s trigger removes the model’s need to infer equivalence between different phrasings (e.g., “May I speak with X?” vs “Am I speaking with X?”). • Mirroring the same rule in both the system prompt and the function docstring reinforces the instruction at two places the model consults when deciding to call a tool. • Phasing the flow reduces accidental tool calls later in the conversation and keeps the

correct_customer

tool tightly scoped. Additional best practices • Include examples in the system prompt showing sample exchanges that should and should not trigger the tool. Short examples are very effective. ◦ Trigger example: Agent: “May I speak with Jane Doe?” Customer: “Yes.” -> call

correct_customer

. ◦ Non-trigger example: Agent: “Are you still there?” Customer: “Yes.” -> do NOT call

correct_customer

. • Prefer short, explicit rules over long, ambiguous prose. The model follows clear, concrete instructions better. • If multiple greeting variants exist (e.g., “Is this Jane Doe?”, “Am I speaking with Jane?”), list them all or state: “Any affirmative reply to the opening connection request (regardless of slight wording differences) should trigger

correct_customer

.” • If you log the call phase/state in context (e.g., a small

phase: connection

flag), include that in the tool decision flow so the model knows the current phase without re-parsing the whole history. If you’d like, I can: • Draft the exact lines to add to greetings_agent_instructions.txt and a ready-to-paste docstring for the

correct_customer

function. • Produce a few short “should trigger / should not trigger” example exchanges you can include in the prompt. Which would you prefer? Sources: Function tool definition | LiveKit Documentation, with interactive elements