Distinguish a Prompt-Only Voice Demo from a Connected Workflow

A prompt-only voice demo can sound like a complete business workflow. The assistant may ask good questions, repeat the caller's details and announce a successful result. To distinguish a prompt-only voice agent from a connected workflow, inspect the action behind that announcement.

The distinction matters because speech and external state can disagree. A conversation can be useful practice without having permission to save anything. Conversely, a real action might complete even if the final spoken confirmation is interrupted. A buyer needs evidence for both the system action and the caller experience.

Start with the claim being demonstrated

Ask the presenter to name the exact capability. “Answers questions about our opening hours” can be demonstrated using approved information. “Updates a customer record” requires an authenticated connection, appropriate permission and evidence of the resulting record.

Write these as separate claims. Do not let a general “works with your systems” statement cover every action an integration might theoretically support. A connection capable of finding a contact does not automatically prove it can create one, update every field or modify other object types.

Burki's demo buyer checklist is a useful starting point for deciding what to observe. Keep a demo's fictional or simulated scope explicit.

Understand the role of tools

Tools give an agent a way to request work beyond generating a reply. LiveKit's tool documentation describes function calls to external systems. The presence of a tool definition alone does not establish that the account is connected, the permission is enabled or the destination accepted the request.

For a supported action, trace four steps: the caller supplied the necessary information; the action was permitted; the destination returned a meaningful result; and the final state matches the intended request. The assistant's spoken sentence is a fifth, separate observation.

A hypothetical contact-note demonstration

Suppose a business wants a short note attached to an existing contact. A useful test begins with a known test contact and a clearly scoped request. The caller gives an enquiry summary, corrects one detail and confirms the final version.

After the conversation, inspect the actual contact record. Check that the note is attached to the intended person, contains the corrected fact and does not invent a promised outcome. A tool log saying “success” is helpful, but the record itself resolves whether the right object was changed.

Now repeat a bounded failure case. If the contact cannot be matched, the assistant should follow its supported fallback rather than attach the note to a plausible stranger. This tests the workflow's limits, not just its clean path.

Ask who can reproduce the demonstration after the presenter leaves. Retain the configuration reference and test record, not just a promotional recording. If access is limited to a demonstration account, that restriction belongs in the acceptance notes because it affects what the business can independently verify.

Use an evidence ladder

Classify demonstrations into prompt practice, simulated tool execution, real provider execution and end-to-end caller acceptance. Each stage can reveal useful information. Problems arise when a lower stage is described as a higher one.

A browser practice session may show tone, turn handling and instruction following. A simulated result may show how the assistant reacts to an unavailable service. A real provider response may show account permission. A final record plus caller-heard confirmation gives stronger evidence of the intended experience.

No single stage substitutes for every other stage. In particular, a telephone deployment needs its actual route checked; a browser microphone does not traverse the carrier connection.

Record what remains outside scope

List unsupported actions alongside the demonstrated ones. If the current workflow can create a record but cannot cancel or reverse it, that matters to the operating procedure. If a provider account is in a test environment, retain that qualification when sharing the recording.

Use Burki's testing guide to turn a persuasive demonstration into a bounded acceptance exercise. Choose one real business outcome, verify its final state and describe the evidence at the level it actually supports.