Full-Duplex Voice Agents: When to Commit Parameters? Eager, Conservative, Two-Phase Compared

01 Align Four Terms

Before comparing commit modes, the article defines four key concepts:

Draft : candidate parameters held in session memory; changing them costs almost nothing.

Commit : parameters cross the executable boundary, triggering real API calls, database writes, or order placement.

Confirm : explicit user approval or an equivalent strong confirmation signal.

Rollback : discarding the draft after a user correction, or compensating for side effects that have already taken effect.

The author notes that evaluation benchmarks often struggle with "self-correction" because the commit happens too early, leaving no clean rollback path.

02 Why Full-Duplex Amplifies the Problem

Turn-based systems can wait until the user finishes speaking. Full-duplex systems, optimized for low latency, tend to "act after hearing half". As speed increases, so does the probability of locking in parameters prematurely. Typical failures include: the tool is correct but the parameters are stale (pre-correction values), or the old call has already taken effect, forcing the new intent to rely on compensatory transactions.

03 Three Modes, Different Commit Points

Mode A | Eager (Early Commit)

As soon as slots "look filled", the real API is invoked. The commit point is extremely early. Suitable for read-only, idempotent, retryable queries; highest risk for order placement or appointment changes where side effects occur. Fast but not resilient to self-correction.

Mode B | Conservative (Late Commit)

Parameters stay in draft for a long time. Only after the endpoint stabilizes—and sometimes after explicit verbal confirmation—does the single commit point occur. Corrections only mutate memory, never touch the real world. Safe and auditable, but the first tool result is slower; voice interactions often need explicit confirmations like "Shall I check now?"

Mode C | Two-Phase (Two-Stage Commit)

Split into two phases: Phase-1 performs a reversible probe (quote, pre-reserve, validate); Phase-2 executes the hard commit. On correction, the prepare phase is discarded without touching the hard commit. This is the most common engineering compromise between speed and correctness, and aligns well with "voice frontend keeps talking, backend processes asynchronously".

04 How to Compare: Four Dimensions

First useful result : Eager fastest, Conservative slowest, Two-phase in the middle (can stream probe results early).

Resilience to self-correction : Conservative strongest, Two-phase second, Eager weakest.

Side-effect safety : Conservative and Two-phase good; Eager relies on compensation, whose complexity can backfire.

State-machine weight : Eager appears simple but compensation logic adds complexity; Two-phase has more nodes but clearer boundaries.

Mechanism cross-reference : Eager commits at first real call; Conservative commits after confirmation; Two-phase's true commit occurs only at the Hard phase, while Prepare can be dropped.

05 Selection: Route by Side Effect, Not Dogma

In practice, three default rules suffice:

Read-only / idempotent → Eager, or short-TTL prepare.

Reversible reservation → Two-phase (default skeleton for most businesses).

Irreversible write → Conservative, or Two-phase with mandatory strong confirmation at Phase-2.

A single conversation can mix modes: checking ticket availability can use Eager/Prepare, while actual booking must use Conservative/Hard. Routing by tool is more reliable than routing by model brand.

06 Invariants All Three Modes Must Guard

Interruption ≠ automatic task cancellation ; cancellation policy must be explicit.

Before re-injecting results, verify topic version / delegation ID ; expired results default to not broadcasting business conclusions.

Draft, reservation, and hard commit must all have TTLs to prevent zombie tasks.

Observability : session ID, topic version, delegation ID, prepare_id, current phase—linked end-to-end in a single trace.

Without these invariants, any commit mode will suffer race conditions and out-of-order execution under concurrency and user corrections.

Summary

Full-duplex makes agents "more human" and turns commit timing into a first-class design problem. If reversible, use two-phase; if irreversible, be conservative; only when provably harmless, go eager. Designing the commit moment clearly determines stability in real calls more than polishing synthesis voices.