---
id: mobile-apps/the-mobile-recorder-app-and-the-dispatcher
title: "The mobile recorder app, and the dispatcher agent behind it"
theme: mobile-apps
status: open
created: 2026-08-21
date_source: stated
order: 2
---

**The mobile recorder app, and the dispatcher agent behind it.** Wanted 2026-08-21. The owner is
building a recorder for the phone. **Every audio lands in one central place** — one inbox, not a
folder per purpose — and a **dispatcher agent** decides where each one goes.

Routing has two modes and both are wanted:

- **Told.** The recording opens with the destination — "send this to my todo guy", or just
  "todo" — and the dispatcher obeys. An explicit address always wins.
- **Inferred.** Nothing is named, and the dispatcher works it out from the content. This is the
  one that makes the app worth using: the ideal is that most notes need no prefix at all.

What this implies: **destinations must be addressable and speakable.** "My todo guy" is a name for
a standing agent session, so the dispatcher needs a registry of destinations with names a person
would actually say. Command HQ is already most of that registry — `command_hq_sessions` names
commanders and keys them on Claude's own transcript uuid. Delivery into a session exists too; see
"Speaking into a session from the backend".

Fits with the rest rather than duplicating it: the **File watchers** split applies unchanged —
a script transcribes on arrival, the dispatcher is the agent stage — and the **iPhone Action
Button** item is how a recording starts without unlocking the phone.

Open: whether the dispatcher is one long-lived session or spawned per note; what it does when
inference is uncertain (ask back, or file into an inbox for review); and whether a routing rule
is a prompt from the prompt library.