[FEATURE] voice-driven agentic control

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Feature request: voice-driven agentic control as a half-duplex dialog, with a two-pane review and a trivial mode switch (as written by Claude on my prompt)

Context / who this is for
I'm a software engineer with 40y of experience. I have essentially zero appetite for the current agentic modes. But there is one thing that would pull me (and, I suspect, a large and underserved segment of cautious users) into agentic use: talking to it. Dialog mode. Speaking an intent, seeing it interpreted, correcting it, confirming it. That, to me, is the natural entry point to the whole agentic world, and I'm surprised it isn't already a top priority.

The strategic argument
Voice isn't just a feature, it's the funnel. A slow, conversational, confirmation-gated voice interface on low-stakes tasks is how you onboard hesitant users into agentic power without throwing them straight into an agent that takes irreversible actions. It builds trust incrementally. The people most resistant to agents are often the ones most receptive to simply talking to their computer — capture them there first and the rest of the roadmap becomes adoptable.

The interface: two panes, edit at the right layer
The screen shows two things side by side: the raw speech-to-text of what I said, and the LLM's interpretation — what it intends to do about it. This restores the checkpoint that voice otherwise removes: I see both what it heard and what it's about to do, before either commits. Splitting them matters because they're two different failure modes, corrected at different layers:

• Transcript wrong → edit the transcript, re-interpret from corrected text.
• Transcript right, plan wrong (heard me fine, inferred the wrong action) → edit the interpretation directly, leave the transcript alone.

Collapsing these into one "that's wrong" forces re-dictation when only the plan was off, or argues with the plan when it was just a mis-hear. Keeping them separate targets the actual fault.

Why the "hard mode-detection problem" doesn't exist
The usual objection is that it's hard to reliably tell, in continuous speech, when the user is commanding vs. correcting vs. thinking aloud. That objection dissolves once you make this a half-duplex, start-stop dialog — like a telegraph or one-way radio, strict turn-taking. There is no continuous stream to disentangle. Execution holds, and the held state waits on a tiny closed vocabulary of continuation commands:

• go — commit and execute the interpretation
• edit — switch to editing the interpretation
• fix prompt — switch to editing the transcript

That's it. Maybe a few more later, but not dozens. With a handful of mutually distinct tokens, the STT only has to resolve which one was said — the words don't even need to be hard to tell apart, because there are so few. This isn't ML. It's a switch statement on a keyword: a small deterministic state machine wrapped around your existing model. The model's intelligence stays confined to the interpretation pane, which I review before committing. Dumb where it touches execution, smart where it plans.

Safe-by-default
While held, nothing executes, so a mis-recognition costs nothing — worst case I repeat the word. All the risk concentrates on the single commit token rather than being smeared across open speech. Risky actions are largely enumerable (delete, send, place order), so a confirmation gate on those is straightforward and doesn't need to be clever.

Optional refinements (not required for v1)

• User-defined tokens rather than fixed wake-words, so nobody trips the switch by accident.
• Prosody as a second signal: a committing "go" (terminal fall, pause after) is acoustically nothing like a conversational "go back to the first one." Cadence is learnable and lives in the audio, not the transcript. You can't set those thresholds a priori because they're per-language and per-person, so instrument and learn them — a metered free beta (say four weeks) would harvest how people actually speak and let you tune from real distributions instead of guessing.

The ask
Not "add a mic." Add a half-duplex voice dialog mode: two-pane view (transcript + interpretation), a closed set of spoken continuation commands driving a trivial mode switch, and a confirmation gate on risky actions. It's a small deterministic machine around the model you already have, and it's the wedge that makes the broader agentic roadmap something cautious users will actually adopt.

Proposed Solution

see above

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_