Harness Dispatch

The Router-Brain is a pure dispatcher. Its only job is to look at a transcribed command and decide where it goes — fast, in under 150 ms. It does not do the work itself.

What a harness is

A harness is an execution backend behind one shared protocol. Jarvis ships several:

• Claude Code — the default agentic coding harness, run as a subprocess
• Codex CLI
• Open Interpreter
• Python script
• MCP remote — any Model Context Protocol server
• Computer-use — direct control of the screen, keyboard, and mouse

Because they all implement the same protocol, adding a backend never touches the voice or routing layers.

The routing decision

The router holds a small, fixed tool surface for the things it can answer directly. Everything else is delegated. The force-spawn heuristic is roughly:

• Small talk (“how are you”, “thanks”) → answered locally, never dispatched.
• Action verbs (“read”, “build”, “install”, “open”, “fix”) → spawn a worker.
• External-system markers (PR, repo, GitHub, issue) → spawn a worker.

The patterns are configurable under [brain.routing], so you can tune what counts as “real work” on your machine.

Optimistic execution

The router never blocks the conversation on a network round-trip. The moment it decides to dispatch, you get your spoken acknowledgement; the worker runs in the background and reports back at the next turn boundary. The talker and the worker talk to each other only through the in-process event bus and the mission store — there’s no external message broker to run.

Why a dispatcher, not a monolith

A single model trying to be chat and coding agent and computer controller is mediocre at all three. Splitting the fast router from the heavy worker means each does one thing well: the router stays instant, and the worker can take its time, run in isolation, and verify itself. That self-verifying worker loop is Missions.