Corey James- 699 msfrom a spoken request to the synthesiser admitting the quick opener
- 2models: a light one keeps speech fast, the heavy brain does the work
- 4identities: operator, employee, seat, voice session
Talking to Helix and typing to Helix reach the same conversation and the same history. That sounds like a feature. It is a constraint, and it ruled out the obvious design. The obvious design points the voice engine's model endpoint at the control centre, so speech becomes just another client. I rejected it because it discards turn identity: the voice engine generates speculatively, retries, and interrupts, and each of those would have become a duplicate piece of durable work in the conversation.
One utterance, one turn
What I built instead is a control-only bridge. The voice engine keeps sole authority over audio and over the floor, who is speaking and who may interrupt. When it takes an utterance, the bridge turns it into exactly one durable Helix turn in the same control-centre conversation the operator would reach by typing. The full written answer is committed and published in the attached channel or thread. A separately fenced, concise projection is what gets spoken. An interruption cancels that exact turn, so stale text is never spoken after the person has moved on.
A spoken projection can never outrun the written answer.
By voice, the operator can navigate between locations, address a particular seat, open and run a council, and delegate work.
Speed and depth are split between the two models. The spoken opener arrives while the full answer is still being written.
What the measurement showed
I tested the claim directly. A typed request and a spoken request were fed through the text-recognition seam. The physical microphone path was outside that measurement.
The same engine in a Teams call
The Teams surface, described in A self-hosted colleague in a Teams call, runs the same voice engine, the same delegation transport and the same provider sessions. The difference is identity. Each Microsoft identity has its own selected voice model and working model, set in the Teams management app independently of the chat workspace. So the exact claim is this: one engine and one brain contract across chat, voice and Teams, and literally one conversation spanning chat and voice inside the workspace, while each Teams employee carries its own working configuration.
Choosing the brain
Helix's reasoning backend is one persistent setting, either a local model profile or an eligible frontier profile. Changing it changes nothing else: persona, voice, conversation tiles and history all stay. The runtime never substitutes a nearby model or a different account when the chosen one is unavailable; it reports the gap instead.
Four identities that never merge
The operator, the acting digital employee, the executing seat and the voice session are distinct identities at every step. The digital employee is one governed Microsoft 365 identity that acts through the meeting action surface, where every call names the acting employee and the server mints that employee's scoped tokens; the identity design is in Solving the digital-employee identity. Keeping the four apart is what lets a voice session be cancelled, a seat be swapped, or an employee be removed without touching the others.
the person in control
removed alone
swapped alone
cancelled alone, a new one opened
Who may interrupt
In chat, the operator can cancel an active turn. In a council, an operator's post takes priority and wakes idle seats, and pausing after the current turn is a different action from cancelling the active one. In voice, the person always wins the floor.
What this demonstrates
I can join real-time speech to a durable conversation system without letting the two corrupt each other: one turn per request, and identities that stay separate under cancellation and failure.
I set the one-turn rule and the identity model and directed AI coding agents, a mix of frontier and open-source models, that implemented the bridge under my governance system.