What Should an AI Phone Agent Do When It Does Not Know the Answer?

An AI phone agent should not hide uncertainty behind a polished guess. It should identify what is missing, say that the answer is not verified, ask a targeted question only if that could resolve the gap, provide the confirmed part, and use an approved next step. It should promise a person, channel, or response time only when each is operationally true.

The short answer: disclose the limit, constrain the answer, and route the unresolved request. “I don’t know” is honest but incomplete if it leaves the caller stranded. A useful recovery either makes the answer verifiable or gives the caller a truthful way forward.

Practical rule: Never turn missing, conflicting, stale, or unavailable information into a confident answer. Never turn a hoped-for handoff into a promise.

This guide is an editorial operating framework for small-business owners. It is not a universal script, a validated scoring model, legal advice, or a statement of current LucidChat product behavior. It covers recovery when an answer is unverified. It does not define general call routing, scheduling, lead qualification, contact-channel design, website chat, channel comparisons, or how to design fictional test calls.

Table of contents

• Why a fluent guess is the wrong fallback
• What “does not know” can mean
• Use the six-step uncertainty sequence
• Choose the response by state, impact, and caller intent
• Build a useful human handoff
• Be truthful when no human is available
• Learn from five illustrative calls
• Preserve accessibility and caller choice
• Test the policy before launch
• Settle the operating questions
• Frequently asked questions
• Conclusion
• Author and evidence disclosure

Why a fluent guess is the wrong fallback

A phone response can sound calm and certain even when its content is wrong. NIST calls the production of confidently stated false or erroneous generative-AI content “confabulation.” Its Generative AI Profile also identifies information-integrity risks when content fails to distinguish fact from opinion or acknowledge uncertainty. (NIST AI 600-1, page 7 and MG-2.2)

That establishes a risk, not a phone script. The practical inference for a call is simple: vocal confidence is not evidence. If the approved source does not support the answer, the response should expose that limit instead of smoothing it over.

NIST’s AI Risk Management Framework calls for documenting knowledge limits and human oversight, describes safe failure beyond knowledge limits, and addresses human-oversight and disengagement processes. (NIST AI RMF Core, Map 2.2, Map 3.5, Measure 2.6, and Manage 2.4) The framework is voluntary and use-case-agnostic; it does not prescribe the sequence in this article. (NIST AI RMF 1.0 publication record)

The distinction matters:

• Verified fact: knowledge limits, safe failure, oversight, feedback, and disengagement are recognized AI risk-management subjects in the cited NIST material.
• Editorial inference: a phone interaction should reveal an answer limit rather than convert it into a fluent assertion.
• Editorial recommendation: design a bounded recovery sequence before the agent handles calls.
• Product confirmation required: whether any particular system detects, discloses, logs, or routes these states must be proven separately.

An uncertainty statement and an AI-identity statement also solve different problems. “You are speaking with an automated assistant” identifies the interface. “I cannot verify that closing time” calibrates a specific answer. One does not replace the other, and this article does not claim that either sentence satisfies every law or use case.

For covered outbound calls, FCC 24-17 applies specified rules to artificial or prerecorded voices, including AI-generated voices. That ruling should not be generalized into a universal inbound-call formula. (FCC 24-17, paragraph 9) Deployment-specific disclosure, recording, consent, telemarketing, privacy, and sector questions need appropriate review.

What “does not know” can mean

“Uncertain” is not one state. Treating it as a single score can hide the action the caller actually needs. The following taxonomy is an original editorial tool, not a NIST classification.

These states should not be inferred from tone alone. A caller’s accent, speech disability, relay use, background noise, or request for repetition is not proof that the caller is confused or that the question is unsafe. Classification should focus on the information and action required.

Use the six-step uncertainty sequence

The following sequence is an editorial recommendation derived from the cited risk principles. It is not an official agency procedure and does not describe a verified LucidChat implementation.

1. Detect and classify the limit

Determine why the answer is not verified. Is one caller detail missing? Is the source empty, inconsistent, or stale? Did a lookup fail? Is the requested decision outside the agent’s authority? Did the caller ask for a person?

Treat a missing source, a source conflict, an inconclusive tool result, and a failed action as unverified. Do not infer that a likely answer is a confirmed answer.

2. Disclose the uncertainty plainly

Use one direct sentence. For example:

“I don’t have a verified answer to that.”

Add the known reason only when it helps:

“The schedule I can check does not show that date.”

Avoid vague reassurance, invented policies, guessed prices, implied availability, predicted approvals, made-up timing, internal system jargon, or any suggestion that a failed lookup succeeded. The FTC has taken enforcement action concerning deceptive AI claims and has emphasized that AI does not create an exemption from existing law. (FTC AI-claims enforcement release) That is a reason to keep capability statements accurate, not a substitute for deployment-specific legal advice.

3. Clarify only when clarification can help

Ask a targeted question tied to the missing field. “Which service do you need?” may unlock the correct schedule. “Can you tell me everything again?” usually does not identify the gap.

Set a clear limit on clarification attempts. The exact number of retries is an owner and product decision; no universal count is supported here. If the targeted repair fails, change paths instead of repeating the same question.

4. Give the safe, useful subset

An incomplete answer can still be useful when its boundary is visible. Offer, in this order:

1. a confirmed fact that directly helps;
2. an approved process or limitation; and
3. a choice among proven next steps.

Do not stretch a partial fact into a complete answer. If the source confirms the office location but not today’s closing time, share the location only if relevant and keep the time unresolved.

5. Route according to impact and caller intent

Escalation should reflect the consequences of being wrong, the caller’s goal, and the paths that actually exist – not a confidence score alone.

An owner-reviewed policy may designate immediate human or specialist handling for emergency-like statements, health, legal, or financial advice, identity-sensitive changes, payments, complaints, threats or harm, material policy exceptions, and explicit requests for a person. These are issue categories for policy design, not a universal legal list. Exact definitions, words, destinations, hours, and safeguards require qualified review and operational proof.

6. Confirm the next step and close the loop

Tell the caller what remains unresolved and what will happen next. Name the responsible person or team, contact channel, and response window only when each is current and supported.

If the action completes, confirm the completed action. If it does not, say so. Leave a clean exit rather than trapping the caller in a loop.

Choose the response by state, impact, and caller intent

This decision table is an original editorial aid based on the sequence above. It is not an official NIST, FTC, FCC, or DOJ table.

The table deliberately separates uncertainty from impact. A missing service name may need one question. A request for a policy exception may be perfectly clear yet still require an authorized decision-maker.

Build a useful human handoff

A transfer is not automatically a resolution. The operational question is whether the next owner receives enough accurate, permitted context to continue – and whether the caller understands what will happen.

Subject to caller permission and privacy/security review, a minimized handoff packet can contain:

• the caller’s stated goal;
• facts already verified during the interaction;
• the exact unresolved question;
• urgency in the caller’s own words, without an invented severity label;
• the preferred response channel and an approved contact detail; and
• the interaction state, such as a failed lookup or conflicting source.

Do not collect detail merely because a field exists. Confirm what the destination needs, is permitted to receive, and can protect. Do not claim that a ticket, message, callback, or transfer exists until the underlying action succeeds.

NIST’s AI RMF includes defined and documented human-oversight processes and feedback routes for reporting problems. (NIST AI RMF Core, Map 3.5 and Measure 3.3) The handoff packet above is an editorial translation for phone operations, not a NIST requirement.

Common failure modes include:

• transferring without context and forcing the caller to start over;
• saying “someone will call” without a real owner;
• copying an unverified response time from a script;
• sending information the destination cannot use or should not receive; and
• continuing automated questioning after an explicit request for a person.

Be truthful when no human is available

“I’ll transfer you now” is false if no transfer path is open. “Someone will call shortly” is unsupported if no owner or response window is proven.

A truthful fallback has five parts:

1. Availability: say that a person is not available through the call now.
2. Choices: offer only channels or actions that exist and are monitored.
3. Timing: provide a response window only when current operating evidence supports it.
4. Context: confirm the unresolved question and the caller’s chosen path.
5. Completion: distinguish between an offered action and a successfully created message, ticket, or callback request.

If no approved alternate exists, say that clearly and permit the call to end. A disappointing truth is more useful than transfer theater.

Learn from five illustrative calls

Every dialogue below is fictional. None is a customer transcript, tested result, product demonstration, or statement of current LucidChat behavior.

Illustrative call 1: a missing scheduling detail

Caller: “Can you fit me in Tuesday?”

Unsafe pattern: Invent a time or imply that availability exists before the required lookup.

Better pattern: “I can check after I know which service you need. Which service is this for?”

If the lookup remains inconclusive, disclose that and offer only a proven scheduling path.

Illustrative call 2: a policy exception

Caller: “Can you waive the cancellation fee?”

Unsafe pattern: Predict approval or invent a policy.

Better pattern: “I can’t approve an exception. If the review path is available, I can record the reason for your request and route it to the team that reviews exceptions.”

Omit timing unless it is verified.

Illustrative call 3: conflicting business information

Caller: “Your message says you close at six, but the booking page says five. Which is right?”

Unsafe pattern: Pick either source without knowing which is current.

Better pattern: “I can’t confirm which time is current. I can pass along the conflict and your question through the approved contact path.”

Illustrative call 4: a human is unavailable

Caller: “Just transfer me to a person.”

Unsafe pattern: Force more questions, simulate a transfer, or promise a callback.

Better pattern: Acknowledge the request, state current availability honestly, and present only proven alternatives. The exact words must match the real operating state.

Illustrative call 5: a high-impact request

Caller: “Tell me whether this symptom is serious.”

Unsafe pattern: Diagnose, reassure, or predict an outcome.

Better pattern: Use owner-approved boundary and routing language. If emergency-like cues are present, follow the separately approved safety policy.

This example intentionally does not supply medical advice or invent a safety script.

Preserve accessibility and caller choice

DOJ guidance explains that effective-communication choices depend on the nature, length, complexity, and context of the communication and on the person’s communication methods. (DOJ, Communicating Effectively with People with Disabilities) The guidance does not decide what is legally sufficient for a particular business.

For an uncertainty policy, accessibility is part of the fallback – not an appendix. Test what happens when a caller:

• uses a relay service;
• asks for slower speech, repetition, keypad input, text, or a person;
• speaks with an accent or dialect the system handles inconsistently;
• has a speech disability;
• calls with background noise or a poor connection; or
• needs an alternate language or channel.

Do not label difference as caller failure. Do not ask someone to repeat an entire story when a focused repair or alternate path is available. Offer another channel only when it is current, accessible, monitored, and permitted to receive the request.

Test the policy before launch

Testing should use defined risk tolerances and include human intervention where the system performs poorly, consistent with the direction in NIST’s GenAI Profile. (NIST AI 600-1, MG-2.2, MG-2.4, and MG-3.2) The following cases are editorial recommendations for phone-agent evaluation:

• a missing answer is disclosed instead of guessed;
• conflicting and stale sources remain unverified;
• a failed lookup is described honestly;
• an explicit request for a person changes the path;
• handoff context is accurate, minimized, and permission-aware;
• a transfer, callback, message, or ticket is claimed only after completion;
• high-impact boundaries trigger the approved path;
• a bounded repair avoids repeated loops;
• relay and other accessibility cases reach a usable alternative;
• caller corrections can be captured; and
• any response-time statement matches operating reality.

Candidate measures include the rate of unresolved questions, verified resolutions, completed escalations, failed handoffs, repeated turns, source conflicts, corrections, and time to an owned next step. These are measurement ideas, not benchmarks or promises. Metric definitions, retention, access, purpose, and privacy safeguards need owner, product, privacy, and security review before collection.

NIST currently reports that AI RMF 1.0 is being revised, so the cited status and source language need release-day rechecking. (NIST AI RMF status page)

Settle the operating questions

Before an uncertainty policy is treated as complete, the business should be able to answer:

• What counts as a verified source for each assigned call job?
• Which states trigger clarification, escalation, or a stop?
• Which paths actually exist during open hours, after hours, and during outages?
• Who owns each escalation category?
• What can the interaction truthfully say about timing?
• Which handoff fields are necessary, permitted, stored, and deleted?
• How are identity-sensitive actions, payments, complaints, and high-impact topics separated from general intake?
• How are caller corrections, accessibility needs, and failed handoffs handled?
• Who reviews uncertainty patterns and updates the source or workflow?
• What change triggers retesting, temporary disablement, or incident review?

The practical next step is to write the answers for one recurring call reason, then test every uncertain branch, including the branch where no human is available.

Frequently asked questions

Should an AI phone agent ever guess when it is uncertain?

No. The practical recommendation is to disclose that the answer is not verified, provide only the confirmed part, and use an approved next step. A fluent delivery does not make an unsupported answer reliable.

Is saying “I don’t know” enough?

Usually not. It reveals the limit, but a useful interaction also asks a targeted clarification when that can help or offers a proven human or alternate path. The next step must not become an invented promise.

When should an AI phone agent transfer a caller to a person?

Use an owner-approved policy based on impact, required judgment, caller intent, and available routes. Likely policy candidates include high-impact or sensitive requests, exceptions, identity-sensitive changes, complaints, failed automation, and any explicit request for a person. The exact categories are business- and deployment-specific.

What should happen if no human is available?

Say that a person is not available through the call, then offer only a proven fallback. Give a response window only when staffing or policy evidence supports it, and never simulate a transfer or callback.

Should the agent tell callers that it is AI?

AI identity and answer-specific uncertainty address different expectations. Opening identity wording should be owner-approved and reviewed for the intended call direction, use case, and jurisdictions. This guide does not propose one sentence as universally sufficient.

How many clarification attempts should the agent make?

There is no universal number supported here. Set a clear limit on clarification attempts based on the call job, impact, caller experience, and available alternatives. When a targeted repair fails, change paths instead of looping.

What information should be passed to a human?

Subject to permission and privacy/security review, pass only what the next owner needs: the caller’s goal, verified facts, unresolved question, urgency in the caller’s own terms, preferred response channel, and relevant interaction state. Do not collect unnecessary sensitive detail.

How should the agent handle emergency-like or professional-advice questions?

It should follow separately approved boundary and routing language, not improvise advice, reassurance, or outcomes. Exact triggers and scripts require the appropriate operational and qualified review for the business and use case.

How can a business test uncertainty handling?

Create cases for missing, stale, conflicting, and unavailable information; failed tools and handoffs; explicit human requests; high-impact boundaries; repeated misunderstandings; corrections; and accessibility needs. Verify both the spoken response and the underlying action.

What should a business measure after launch?

Possible measures include unresolved questions, verified resolutions, completed and failed handoffs, repeated turns, source conflicts, corrections, and time to an owned next step. Define each measure and its privacy controls before collecting it; do not assume a benchmark.

Conclusion

An AI phone agent does not need to know everything to be useful. It does need a truthful boundary and a working recovery path.

The operating rule is: identify the uncertainty, disclose it, clarify only when useful, give the confirmed subset, route by impact and caller intent, and promise only what the business can prove. Build that policy for one real call reason, test the failure states, and treat every missing owner or fallback as a hold.

Author and evidence disclosure

LucidChat Editorial Team creates practical guidance from cited sources and editorial analysis. AI tools may assist with drafting, research organization, and visuals. Claims, sources, formatting, and publication decisions require responsible human review before publication.

This private source draft was authored with AI assistance from an accepted, human-directed evidence brief. Its phone-specific taxonomy, sequence, decision table, examples, and recommendations are editorial synthesis. They are not agency prescriptions, legal advice, current product claims, or proof of implementation. This draft has received an independent review of its source claims and release evidence for the website scheduling gate.