Interaction Closure: What Business Voice AI Needs

OpenAI's GPT-Realtime-2.1 supports speech-to-speech conversations, configurable reasoning, instruction following, and tool use for complex voice-agent workflows. Users can explain a problem naturally, add context, change direction, and respond in their own words.

Yet these advances alone have not transformed how businesses operate inbound phone lines. Many calls are still handled by people, rigid phone trees, or automation limited to a narrow set of requests. A compelling free-form voice demonstration does not automatically become an agent that a business can trust to represent it across every incoming call.

Why has better voice AI not translated into broader business adoption?

Because free-form interaction solves only the surface of the problem. It improves how naturally a user and model can communicate. It does not ensure that every conversational path remains governed by the applicable requirements, validation rules, policies, confirmation steps, authority boundaries, and permitted business outcomes.

The voice model makes the interaction surface soft, but the business still needs a rigid core.

Why Businesses Need Workflow

For backend work, that rigid core is workflow.

Getting from zero to one is exploration: the business is discovering the best way to do the work. Scaling beyond one means capturing that best practice in a repeatable business process—how the work is decomposed, which steps depend on others, what each step must produce, and how failure is handled.

Business processes have dependencies and consequences. Inputs must be validated, some steps must precede others, and consequential actions may require approval. Service calls fail, operations time out, and partially completed work may need to be retried or compensated. The business must always know whether the work completed, failed, paused, or escalated.

In theory, a business could encode its standard operating procedure step by step in a prompt and let the model carry out the work.

In practice, however, businesses rarely rely on prompts alone for repeatable production work.

Why? Because a prompt describes what the model should do; it does not guarantee what the system will do. The model interprets the instructions again on every run, so it can skip, repeat, reorder, or misapply a step. Changes in wording, context, or model behavior can change the execution even when the business state is the same.

In a repeatable business process, even an occasional mistake matters. A missed approval, duplicate reservation, or incorrect retry can change a real business outcome. More instructions may reduce these errors, but they do not provide durable state, idempotency, or enforced recovery.

A prompt-first approach also raises cost on two fronts. First, it spends model inference on decisions the business has already made. Second, because one model must understand and coordinate the entire process, it often requires a more capable—and more expensive—model even when the individual steps could be handled by smaller specialized models.

A workflow takes an executable, code-enforced approach. It turns the process into a structure that:

• enforces preconditions, dependencies, permissions, and approvals;
• persists state so work can be inspected, resumed, tested, and audited;
• controls retries, timeouts, compensation, escalation, and side effects;
• records the terminal outcome of the work; and
• assigns each step to the simplest suitable component: deterministic code, a specialized small model, or a larger model when open-ended reasoning is genuinely required.

For repeatable production work, businesses prefer this approach—not because a large model cannot complete the process, but because known work should not be rediscovered on every run. The workflow defines the process once, keeps known transitions consistent, and assigns each step to deterministic code or the smallest capable model. Reliability improves while cost decreases.

Models may operate inside workflow steps, but the workflow owns the operational contract: what each component may do, what happens next, and what constitutes a valid result. This is workflow over LLM—models provide flexible reasoning; workflow provides business-owned control.

Why Inbound Automation Still Falls Short

If an LLM is not enough to govern business work, it should not be expected to govern business interaction by itself either. After all, interaction is far more complex than a happy-path process: users can say whatever they want, in any order, while the business must still enforce its rules and guide the interaction to a business-valid outcome.

For example, consider three customers making the same reservation request.

The first follows a designed sequence:

User: I need a reservation.
Assistant: For what day?
User: Friday.
Assistant: What time?
User: Around 7 PM.
Assistant: For how many people?
User: Two.
Assistant: Any seating preference?
User: Outside if possible.
Assistant: What name should I use?
User: Priya.

The second provides everything at once:

User: Book an outdoor table for two this Friday around seven under Priya.

The third provides information through correction and interruption:

User: Can you book Thursday for two—
Assistant: What time on Thurs—
User: Sorry, Friday, not Thursday. Around seven. Outside if possible, under Priya.

All three express the same business meaning:

operation: create reservation
date: resolved Friday
time preference: around 7 PM
party size: 2
seating: outdoor preferred
customer: Priya

In all three cases, the business should apply the same availability, validation, and confirmation logic. These examples expose the central problem with inbound interaction: the business cannot control what callers say, when they say it, or how much information they provide at once, but those differences must not change the governing business result.

For the same reasons businesses need workflow for fulfillment, a pure LLM-based solution does not provide the reliability or cost control required for business interaction. In a pure LLM system, the model must infer the current state, apply requirements, decide when to validate or confirm, and choose when to use tools on every turn. Different wording or context can change its behavior, while using a sufficiently capable model to reconstruct known interaction logic makes every turn more expensive than necessary.

A flow works only when the interface can constrain what users may express at each step. Unfortunately, that makes a flow-based solution unsuitable for free-form conversation. It can identify an intent, collect required information, confirm the request, and invoke a backend workflow—but only along paths the designer has modeled. In conversation, a flow controls what the system asks next, not what the user says next. To guarantee consistent business behavior regardless of the user's wording or ordering, the designer would have to define every possible conversational path.

This gap helps explain why capable voice AI has not yet produced widespread automation of inbound business calls. Business conversation needs the flexibility of an LLM at the surface and the predictability of business logic at the core. Neither pure LLM interaction nor dialog flow provides both. This is the problem Interaction Closure solves.

Interaction Closure: Prepare for Every Input and Return to Business Logic

Voice is one of the most immediate ways to express intent: a person only needs to speak. It is already an important channel between customers and businesses, and it may become even more important as computing extends beyond screens. Unlike graphical interfaces, which people learn later in life, spoken interaction is learned from early childhood. That lifelong familiarity creates a high expectation: people expect the system to follow them as they think aloud, provide several details at once, correct themselves, interrupt, and change direction. Yet differences in wording, ordering, corrections, and interruptions create effectively unlimited conversational paths. Those paths must map into a finite set of business interactions, with equivalent paths converging on the same business agreement.

Interaction Closure uses an LLM for dialog understanding and rendering, with a business-defined state machine as its control core:

• The LLM interprets the user utterance as a proposed user dialog act.
• The state machine records the interaction context and meaning established so far.
• Business rules govern consequential or constrained decisions.
• Common sense handles unconstrained conversation.
• The resulting system dialog act is rendered as a natural utterance.

Natural-language expressions are effectively unlimited, but each business use case can define a finite set of dialog-act types. These acts may add or revise information, satisfy multiple requirements, invoke a supported operation, request clarification, refuse an unsupported or prohibited request, or hand control to a person. Clarification, refusal, and handoff are part of Interaction Closure, not failures of it.

After the LLM maps an expression to one or more proposed user dialog acts, deterministic logic records their meaning in the accumulated interaction context. Applicable business rules govern their effect on business state and the next system dialog act; common sense handles the rest.

The state machine provides a fully connected invocation surface in which relevant dialog acts can be invoked from any conversational state, while validation, dependencies, confirmation, and authorization govern their effect on business state.

The LLM interprets and renders language. Business logic governs consequential dialog acts.

Because language understanding remains probabilistic, ambiguous, unsupported, or low-confidence input invokes a defined clarification, refusal, or handoff dialog act instead of an improvised business decision.

Interaction Closure is not the entire production voice stack. An inbound phone agent also needs accurate speech processing, low latency, identity and security controls, reliable fulfillment workflows, observability, and human escalation. Interaction Closure supplies the part those capabilities do not: a complete business-interaction surface that returns open-ended user input to governed business logic.

This is why Interaction Closure works: it separates expression from control. Varied utterances become dialog acts, meaning accumulates across turns, and applicable business rules operate on that meaning rather than on raw wording or conversational order. Equivalent meaning in the same context therefore receives the same governed handling.

Let Users Control the Path Without Surrendering Business Logic

Workflow and Interaction Closure provide complementary forms of business control. Workflow governs how agreed work is executed; Interaction Closure governs business meaning and agreement—what the user wants, what remains unresolved, and whether fulfillment is authorized. The boundary is one of authority: the interaction layer governs meaning and agreement; the fulfillment layer governs execution.

Workflow over LLM for reliable fulfillment. Interaction Closure over LLM for predictable interaction.

The promise is simple:

Do not control the user's conversational path. Control the interaction state and system emission according to the business goal.

At scale, neither extreme works. A rigid flow cannot absorb the ways people actually speak, while an end-to-end LLM cannot provide the repeatability, cost control, and business authority that consequential interactions require. Interaction Closure connects a soft interaction surface to a rigid business core, turning conversation into a dependable business channel rather than an impressive demonstration.