A chatbot, a voice interface and an agentic workflow
A chatbot may provide text answers. A voice interface adds listening and speaking. An agentic workflow uses permitted tools to carry out a defined task. These categories can overlap; they do not imply that one approach is universally better than another.
The important question is which actions the system may take. Reading an order status and changing its delivery address require different permissions even when both requests sound ordinary. This page explains a control model; it does not announce a separate OMO cross-channel product.
Two tasks and their decision rights
This table is an illustrative design. The actual identity checks and approval policy must be agreed with the business. Review the entire chain, including how the caller is informed when an action cannot proceed.
| Control | Read a request status | Change an appointment time |
|---|---|---|
| Model proposal | Retrieve the request status | Check a new time and propose a change |
| Trusted source | Current service-system record | Calendar and existing appointment record |
| Permitted scope | Necessary fields belonging to the authorized customer | Only this customer’s permitted appointment |
| Validation | Identity, organization and permitted fields | Authority, service, date and current availability |
| Confirmation or approval | Checks required by the access policy | Fresh caller confirmation; employee approval where required |
| Completion signal | Permitted status returned by the authoritative system | Confirmed backend change and updated record state |
| Fallback | Verify identity or involve a human without exposing data | Retain the existing appointment, reconcile status or involve a human |
What does that sound like in a conversation?
“What is happening with my request?” The agent first performs the applicable access checks, then reads the record and returns only permitted status information. Nothing is changed. If identity cannot be verified, personal information found during a lookup must not appear in the answer.
“Move my appointment to four tomorrow.” The agent identifies the relevant appointment and exact date, checks the new time and obtains the required confirmation. An authorized request performs the change. If the response is lost, the agent neither claims success nor creates another booking: it checks the original operation’s status.
When should a person approve the next step?
Human involvement depends on risk, authority and agreed policy. A small reversible change and approval of a significant contract should not be governed by identical controls. Define who can approve an action, what that approval covers and when it expires.
Escalate when the action exceeds the system’s authority, evidence is insufficient or the caller requests a person. An unavailable employee does not erase an approval requirement. The action remains pending, or the system creates only an authorized follow-up request.
- Recheck approval when a previously confirmed field changes.
- Keep retrieved documents and caller instructions separate from trusted policy.
- Do not treat a model-generated permission claim as authorization.
Handle refusal and uncertainty differently
An invalid field needs clarification; a prohibited action must not execute. A technical timeout is different from a refusal. When the result of a write is unknown, reconcile its status before making another request.
Observability connects intent, proposed tool arguments, validation outcome, backend response and the spoken answer. Retain only necessary information under the agreed access and retention policy. A transcript containing “done” is not a completion metric.
- Measure correctly completed tasks and correctly refused actions separately.
- Test wrong-tool selection, stale data and recovery after an unavailable system.
- Compare models using the same tasks and conditions, not a model name alone.
Where is this approach a good fit?
A suitable first task has a defined outcome, verifiable data, bounded tools and a responsible human owner. That makes success and failure behavior testable before a wider rollout.
If there is no trusted source, permissions are unclear or completion cannot be verified, organize the process first. Agentic AI is not a shortcut around approval, privacy or high-risk professional decisions.
Common questions
Does the agent act independently?
Only within configured permissions and agreed rules. A request expressed in natural language does not create additional authority.
Is an LLM enough?
No. State management, trusted data, tools, authorization and backend verification are essential parts of the system.
Can it override policy?
It must not. Proposed actions pass application checks; instructions in caller speech or retrieved content do not replace the business policy.
Does every step need a human?
Not necessarily. Controls depend on action risk and agreed rules, but any required approval must still be obtained.
Is this a separate OMO product?
No. It is an educational guide. Specific implementations are assessed through OMO’s existing voice-agent and custom-workflow offerings.
Primary sources and scope
Checked on September 17, 2026. These sources explain technical mechanisms, not the availability of every capability in an OMO implementation. Proposed connections and examples require a separate assessment.
- Google AI — function calling
Model-proposed tool calls and application-side execution.
- OWASP — prompt injection
Untrusted input, least privilege and controls for high-risk actions.
- LiveKit — call transfers
Transfer mechanisms require compatible, configured telephony.

