One voice note, three requests: how we built an LLM router

In the first post of this series, a four-second voice note helped us separate what the model does from what the harness does: "Done with the Novak job." That was the easy case. A real day sounds more like this: "Done with the Novak job. We're starting the school job tomorrow at 9, remind me at 8."

That one voice note holds three requests: close a job, record a new one and set a reminder. Whoever records it on the way down from the roof won't send them one at a time or say which card they mean, and they shouldn't have to. This post shows how we built the harness so they don't, in three decisions: a router that splits the message into requests and hands each to the agent that owns it, code that searches the project while the model chooses the card, and asking only when in doubt, never to confirm.

A router that hands out work and decides nothing

The router is the first thing every message touches, and it should do exactly one thing: split the message into requests and hand each one to the agent that owns that kind of work. In the Novak note, each of the three requests lands with a different agent, and each agent gets only its own.

The router splits a message by the things asked, not by sentences. "We're starting the school job tomorrow at 9, remind me at 8" is one sentence and two requests: a new job with its start time, and a reminder. Each request travels with the person's exact words rather than the router's summary, so the agent reads what was actually said.

Everything else stays out of the router. It records nothing, picks no cards, looks for no keywords and has no rules for any language: it understands a request in whatever language it comes in. If it picked cards too, two pieces would be making the same decision, and sooner or later they would make it differently.

What the router knows about each agent isn't written in the router either. It comes from what each agent declares about the work it does. Adding an agent, or changing what one does, never means touching the router.

Show the model what the person saw

To make sense of "the Novak job" or "tomorrow at 9," the model needs what the person had in front of them when they recorded the note: the conversation as it looked on their screen. Every line carries its time, and the current time appears once, at the top. That way "tomorrow" means the same day to the router and to every agent.

Code searches and the model chooses. For "the Novak job," code looks through everything a card holds, not just its title: the description, the notes, the text in its photos and what was said in its voice notes. It searches by words and by meaning, then hands the model a few candidates, each with the place where it matched: "Novak, in the title" or "Novak, in Tuesday's voice note."

With that, the model does what it does best: read the person's words and decide which of those cards they mean. Showing it the whole project would make it slower, more expensive and easier to confuse. Showing it a single card would mean deciding for it.

There is one search per message, and both the router and the agent see its result. If each ran its own search, they could end up talking about different cards without knowing it.

The router splits a message by the things asked, not by sentences.

The model never handles a card's internal ID, either. It sees each card by a short number, like #12, and code translates that number back into the real card. A long ID is easy to copy wrong; a short number isn't.

Ask only when in doubt, never to confirm

The last decision is the one people notice most: when to ask. Werk doesn't ask for confirmation. It does what it's asked and says what it did. If something wasn't right, it can be undone from the same chat, and each card's history keeps every change.

Asking "Confirm?" before every change looks careful, but with use it stops being careful. Anthropic describes this in its post on how it built auto mode for Claude Code (2026): when people have to approve so many actions, they stop looking at what they approve. In practice, users accept 93% of permission prompts anyway.

For someone working on a roof, every confirmation is also an interruption: phone out again, gloves off again. So Werk asks only when it truly can't tell. If the project has two open Novak jobs, the panel installation and a battery quote, "done with the Novak job" fits both. If nothing else tells them apart, Werk asks which one instead of guessing.

The two questions look alike, but they aren't. "Which one?" asks the person for a fact the harness doesn't have. "Confirm?" asks for permission they already gave when they sent the message.

In practice, users accept 93% of permission prompts anyway.

(Anthropic, 2026)

Even so, the harness will sometimes get it wrong. How that mistake gets caught, how it becomes a test and where it gets fixed is the subject of the third post.

That way, people on the move can keep talking the way they do, in a hurry and with three things in one breath, and each one ends up where it belongs.