Voice Daemon Session-Loop Unification

[noanflaherty]

Summary

Move voice call turn execution off the bespoke CallOrchestrator LLM loop and onto the same daemon/session pipeline used by other channels. Voice calls now have memory, tools, skills, runtime injections, and guardian context parity with chat channels.

Changes

• M1: Voice -> Run/Session Bridge — Extended RunOrchestrator to support streaming event sink (VoiceRunEventSink) for real-time TTS token streaming and run cancellation for barge-in. Created voice-session-bridge.ts module with dependency injection via daemon lifecycle. Run abort handles are scoped to their originating run to prevent stale cancellation.
• M2: Replace CallOrchestrator — Replaced CallOrchestrator (direct provider.sendMessage() loop) with session-backed CallController that routes voice turns through the bridge. Preserved all call UX behavior: control markers, barge-in, state machine, guardian verification. generation_cancelled events are forwarded to the event sink and turnComplete promise always settles on abort.
• M3: Guardian Context & Side-Effect Parity — Voice turns now pass sourceChannel: 'voice', turnChannelContext, guardianContext, and forceStrictSideEffects matching channel ingress behavior. Non-guardian/unverified voice actors get tool confirmations auto-denied immediately (not 300s timeout).
• M4: Legacy Cleanup — Removed stale orchestrator references, updated ARCHITECTURE.md diagrams to reflect new voice -> session loop path.

Milestone PRs (merged into feature branch)

• M1: Add Voice -> Run/Session Bridge #8222: M1: Add Voice -> Run/Session Bridge
• M2: Replace CallOrchestrator with Session-Backed Voice Controller #8275: M2: Replace CallOrchestrator with Session-Backed Voice Controller
• M3: Guardian Context and Side-Effect Policy Parity #8299: M3: Guardian Context and Side-Effect Policy Parity
• M4: Clean Up Legacy Orchestrator Artifacts + Docs #8304: M4: Clean Up Legacy Orchestrator Artifacts + Docs

Feedback PRs (merged into milestone branches)

• Fix: Scope run abort handles to originating run #8238: Fix: Scope run abort handles to originating run
• Fix: Resolve voice turn promise on abort/exception #8280: Fix: Resolve voice turn promise on abort/exception
• Fix: Increment llmRunVersion in destroy() before abort #8290: Fix: Increment llmRunVersion in destroy() before abort
• Fix: Auto-deny tool confirmations for non-guardian voice turns #8302: Fix: Auto-deny tool confirmations for non-guardian voice turns
• Fix: ARCHITECTURE.md Mermaid diagram rendering issues #8307: Fix: ARCHITECTURE.md Mermaid diagram rendering issues

Project issue

Closes #8181

Test plan

• Voice inbound guardian call can invoke tools/skills and access memory
• rg -n "provider.sendMessage\(.*\[\]" assistant/src/calls returns no active voice turn path call sites
• Interrupt (barge-in) during assistant speech aborts in-flight run and accepts next caller utterance
• [ASK_GUARDIAN] still creates pending question + cross-channel guardian dispatch
• [END_CALL] still terminates relay/call session correctly
• answerCall and instruction APIs still function for active call controller
• Non-guardian voice turns enforce strict side effects with fast auto-deny
• Guardian verification upgrades context for subsequent turns

Generated with Claude Code

---

[noanflaherty]

👀 Where to focus your review

• assistant/src/runtime/run-orchestrator.ts: New VoiceRunEventSink interface, RunHandle return type change (breaking for any callers not updated), voiceAutoDenyConfirmations flag that intercepts confirmation requests — this is the core architectural change that enables voice to use the session pipeline.
• assistant/src/calls/call-controller.ts: Entirely new file replacing call-orchestrator.ts. Preserves all control marker behavior, state machine, and barge-in handling while routing through session loop. The turnComplete promise settlement on abort is the trickiest part.
• assistant/src/calls/voice-session-bridge.ts: New bridge module with forceStrictSideEffects derivation from guardian context — security-sensitive logic.

Risk level: High — This replaces the entire voice LLM execution path. While all existing call UX behaviors are preserved and the approach was extensively reviewed per-milestone, end-to-end voice call testing is essential before shipping.

[noanflaherty]

Addressed in #8352

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 12 additional findings in Devin Review.

[devin-ai-integration]

🟡 [CALL_OPENING] marker replaced before reaching LLM, but voiceCallControlPrompt still references it as a trigger

In voice-session-bridge.ts, the [CALL_OPENING] marker is replaced with benign text '(call connected — deliver opening greeting)' before being sent to orchestrator.startRun(). This means the LLM never sees [CALL_OPENING] in the user message. However, the voiceCallControlPrompt injected alongside the message still instructs the model to match on [CALL_OPENING].

Root Cause and Impact

The replacement at voice-session-bridge.ts:198-199:

const persistedContent = opts.content === CALL_OPENING_MARKER
    ? '(call connected — deliver opening greeting)'
    : opts.content;

Means the persisted (and runtime) user message is '(call connected — deliver opening greeting)', not [CALL_OPENING].

But buildVoiceCallControlPrompt at voice-session-bridge.ts:137-144 generates instructions referencing the original marker:

10. If the latest user turn is [CALL_OPENING], greet the caller warmly and ask how you can help.

(or for outbound: "...briefly introduce yourself once as an assistant, state why you are calling using the Task context, and ask a short permission/check-in question.")

Since the model sees (call connected — deliver opening greeting) — not [CALL_OPENING] — rule 10 won't match as intended. The model will likely still generate a greeting from the descriptive text, but will miss the specific protocol guidance (e.g., "state why you are calling using the Task context", "ask a short permission/check-in question", "vary the wording").

Impact: Opening greeting quality may be degraded for both inbound and outbound calls. The model falls back to general behavior instead of following the specific greeting protocol in rule 10/11.

Prompt for agents

The [CALL_OPENING] marker is replaced with benign text before being sent to the LLM, but the voiceCallControlPrompt rules still reference [CALL_OPENING] as the expected user turn content. Fix this mismatch by either:

1. In voice-session-bridge.ts (line 198-199): Keep [CALL_OPENING] as the content sent to startRun, and instead strip it during session history persistence (similar to how other runtime injections are stripped).

2. OR in voice-session-bridge.ts buildVoiceCallControlPrompt (lines 137-144): Update rules 10 and 11 to reference the replacement text '(call connected — deliver opening greeting)' instead of [CALL_OPENING].

Option 1 is preferred because it preserves the exact marker-matching protocol that the old CallOrchestrator used, while the stripping ensures the marker doesn't leak into persisted history.

---

Was this helpful? React with 👍 or 👎 to provide feedback.