# Two decision models, two jobs

[Journal](/journal/)

October 6, 2026 · [product](/journal/#product)



Choosing the answer model and choosing tools fail differently. Muniment Desktop gives each its own decision model, and the tool picker can pick nothing.

![A rotary switch sends one verdigris input to a single output, and beside it a bar gauge with a threshold line connects only three of many sockets in verdigris.](/_astro/two-decision-models-two-jobs.CqaUOBcM_UvAkE.avif)

Picking the model that answers and picking the tools it may use look like one routing problem. They fail in opposite directions, so Muniment Desktop now runs them as two decisions, each with its own decision model.

A wrong answer model costs money or quality on one reply. A wrong tool pick changes what the agent can reach. One error is a price, and the other is a permission.

## Routing must always answer

Model routing runs on every message. The decision model reads the message and chooses one of the answer models the user connected, and account balancing spreads the load across accounts. A routing decision can be wrong, but it cannot be empty, because the message still needs a reply.

That job wants a small, fast model. It answers one short question, many times a day, on the critical path of every message.

## Tool picks may answer nothing

Assistance is the second job. Before the turn starts, a decision model reads the message and up to 20 installed MCP servers and skills, each with its description, and may pick some of them for this message.

We built that picker to fail closed. Every candidate list includes an explicit choice of none. It makes at most 3 picks, and each pick needs a confidence of 0.6 or more. A timeout or a low score adds no capability at all, and the turn proceeds with what the user chose by hand.

| Decision | Candidates | Output | When unsure |
| --- | --- | --- | --- |
| Model routing | Connected answer models | Exactly one | Falls back to a model |
| Assistance | Up to 20 servers and skills, plus none | 0 to 3 picks at 0.6 or more | Adds nothing |

## Keyword search runs after the model asks

Pi, the harness inside our desktop, already finds tools. Its codemode scripts call [`searchTools()`, which ranks callable tools by BM25](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/codemode.md) and returns eight by default. That search runs inside a script, after the answer model has decided it needs a tool and chosen the words to search for.

Assistance runs earlier and reads meaning, not keywords. A request to check why a deploy failed can pick a CI server whose description never says deploy. Both layers stay. Assistance decides which servers join the turn, and codemode search finds the right tool inside them. Pi’s authors are neither Muniment customers nor endorsers.

## Users see which model decides

Settings lets the user choose the assistance model separately, or keep the routing one. A fast model can route every message while a larger one reads the tool catalog.

While assistance is on, the composer names the model that decides, such as Clef Flash assists, and one click turns it off for a single message. While it is off, the label disappears. An automatic choice that changes what an agent can touch should carry a visible name, so the user can tell which model made it.

If you run agents with real tools, give the tool picker its own model, its own threshold, and an empty answer. The [models guide](/docs/models/) shows both settings in Muniment Desktop.

## Sources

1.  [Pi documentation: Codemode](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/codemode.md) github.com