Please read: this tutorial describes the voice path as it worked in March 2026. The voice capability survives in NAOMS today — there's still on-device speech recognition and synthesis — but the exact commands and tool names shown here are from the March implementation and have since changed. Use this to understand the shape of the pipeline, not as a current command reference. Every step maps to a real commit from this week.

Most "talk to your assistant" features work by shipping your voice to someone else's servers. You speak, your audio leaves your machine, a company transcribes it, a company runs the model, a company speaks back. Convenient — and the entire conversation is now somebody else's data.

In March 2026 NAOMS shipped a voice path built on the opposite assumption: every link in the chain stays on your machine. This is a walk-through of how that pipeline fit together. Think of it as understanding a circuit, not memorizing a remote API.

The whole chain, in one breath

The commit that names the design is wonderfully literal. It's titled "Local Voice Path — mic → whisper → NAOMS → TTS → speakers" (2026-03-20). That arrow chain is the tutorial. Let's take it one hop at a time.

flowchart LR
  A[mic] --> B[whisper: speech to text] --> C[NAOMS] --> D[text to speech] --> E[speakers]

  microphone  →  whisper  →  NAOMS  →  TTS  →  speakers
  (your voice)  (speech→text) (your memory) (text→speech) (the reply)

Five stages. Not one of them needs the internet. That's the entire point, and it's worth saying slowly: you could do this on a laptop in a cabin with no signal, and it would work exactly the same.

Stage 1 — the microphone

The first hop is just capture: your microphone turns sound into samples. Nothing exotic. The thing to notice is where the samples go next — not up to a cloud endpoint, but to a transcriber running locally.

Stage 2 — whisper (speech → text), on-device

This is the stage people assume has to be in the cloud, and it doesn't. NAOMS used whisper, the open speech-recognition model, running as a local program. You can even watch the system pick the right binary name in the log: "whisper-cpp → whisper-cli (Homebrew binary name)." That's a tiny, almost funny commit — someone discovering the Homebrew package renamed its executable — but it's a fingerprint of the real thing: this transcription is a program on your computer, installed like any other local tool, not a web service.

Teacher's aside: the moment your speech-to-text is local, the privacy story for the whole feature is basically solved. Transcription is the stage where raw audio would otherwise have to travel. Keep it on-device and the rest of the chain only ever handles text you already trust your machine with.

Your spoken words come out of this stage as plain text.

Stage 3 — NAOMS (the memory itself)

Now the text reaches NAOMS proper. This is where "voice assistant" becomes "voice into your memory system." The query — "what did I decide about the budget?", "remind me what that person's name was" — runs against your own local memory store, the same one your other NAOMS clients use. There's no separate cloud brain. The intelligence and the data are the same on-device system you already own.

Two follow-on commits show how conversational this got:

• "voice:talk — multi-turn voice conversation with awakened NAOMS" — multi-turn, meaning it holds context across exchanges, not one-shot Q&A.
• "Voice mode — 'let's switch to voice'" — you could literally say "let's switch to voice" and the session would change modality.

A reminder: voice:talk was the March command. That exact name isn't in NAOMS anymore — the surface evolved. The ability to hold a multi-turn local voice conversation is what survived; the spelling of the command did not.

Stage 4 — TTS (text → speech)

NAOMS produces a textual answer; text-to-speech turns it back into sound. Again local: the reply is synthesized on your machine. The audio you hear was never assembled on a server somewhere.

Stage 5 — speakers

The last hop is trivial and the most satisfying: the synthesized reply comes out of your speakers. You spoke, your own computer understood, your own memory answered, your own computer spoke back. The loop closed without a single byte of your voice leaving the building.

Why build it this way at all

Because of the Wholeness axiom: a NAOMS instance is supposed to be complete in itself. A voice feature that breaks the second your Wi-Fi drops would violate that — it would make the system depend on something outside itself for a core function. By insisting every stage runs locally, the voice path stays true to the same promise as the rest of NAOMS: pull the plug, and it still works.

The deeper version even folded voice into the memory layer directly — a "Local Voice Plugin — 6 tools, 41 tests, memory integration" — so that speaking to NAOMS and remembering with NAOMS were the same system, not a bolt-on.

What to take away

You don't need to remember the March commands. Remember the chain — mic, transcribe, query-your-memory, synthesize, speak — and remember that the whole thing fits on one machine. The next time someone tells you a voice assistant has to live in the cloud, you'll know that's a business decision, not a technical one.

Related: Search That Never Phones Home.

Written by AI agents from real project logs; owned and edited by Mujo.