Router, Specialist, Verifier

Three parts you can actually staff:

This is not a multi-agent society yet (next track). It is one runtime with three functions. The router does not call refund. The verifier does not search. The billing specialist does not answer poems. Small jobs. The router picks. The specialist acts. The verifier checks.

Ship this before a swarm. Multi-agent is for when specialists must talk to each other. Most products need a router and a verifier first. A god-loop with forty tools is how gather refunds and FAQ specialists send email.

Router

The router maps user text to a kind: billing, faq, handoff. It can be code (keywords) or a small model call with an enum schema. Fail closed: unknown → handoff, not “guess billing.” The router’s tool list is empty or is route only. It does not execute refund to “save a hop.” Saving a hop is how you skip policy.

Keep the router cheap. It runs every message. If it is a 40-tool ReAct agent, you did not route. You nested a god-loop.

Specialist

Each specialist is the six-part loop with a small catalog: billing has lookup, policy, refund, finish, handoff. FAQ has search-hours, finish, handoff. Computer use, if you must, lives in a specialist that cannot refund.

Assembler advertises only that catalog. State machine is that specialist’s phases. Budget is per specialist run. You can share memory stores or not; do not share allowlists.

The specialist returns a draft plus evidence ids, not a live write, unless the verifier (or HITL) already sits in front of writes. Safer: specialist drafts, verifier checks, then executor writes. Money still HITL.

Verifier

The verifier is the grounded critic with a job title. It sees the draft and the evidence the user will see. Billing must cite policy. FAQ must mention hours. Handoff is not ok as a “specialist success.” Fail → retry once or deny/handoff.

The verifier does not call refund. It does not search. If it needs evidence, the specialist should have fetched it. Asking the verifier to tool-call is how it becomes a fourth agent. Next track can do that on purpose. This track: a function.

One runtime

Three functions, one process, one run_id, one trace. You can log role=router then role=billing then role=verifier. That is enough to debug. You do not need message buses yet. You do not need a crew of personas.

If billing must ask FAQ a question, you are at the border of the next track. Do not start there. Duplicate a hours note in billing’s retrieve if you must. Talking specialists is a product when the note is not enough.

Before the world changes

Verify before writes. Router → specialist draft → verifier → HITL if needed → execute. If you execute then verify, the critic is a blog post about the incident.

Poems have no specialist: handoff. That is success of the router. Do not send poems to billing “in case.”

Small catalogs, shared runtime, and what still sits in one loop

Each specialist’s catalog should fit on a notecard. Billing: get_order, check_window (code), refund, finish, handoff. FAQ: get_hours, finish, handoff. If billing also has run_sql, send_email, computer_use, and search_web, you rebuilt the god-loop inside a costume named billing. The assembler advertises the notecard. The parser fail-closes the rest.

Shared runtime means shared stop meters if you want a global cap, shared traces, shared run_id. It does not mean shared allowlists. Memory: a profile store can be shared; a billing scratchpad should not leak into FAQ as if it were policy. Retrieve can be per specialist index.

The verifier’s checklist is per kind. Billing: cites policy, amount present, no extra vendors. FAQ: hours string, no refund language. A shared vibe critic that only says “looks helpful” is ungrounded again. Fail closed on handoff kind: there is no draft to bless.

Writes: prefer draft-then-verify-then-HITL-then-execute. Reads can happen inside the specialist before the verifier. If the specialist executed refund before the verifier, the pattern is theater.

This is still one agent costume with three functions. Personas in the prompts (“you are BillingBot”) are optional and often harmful. Jobs are the functions. When billing must call FAQ as a peer with its own loop and mailbox, that is the next track. Until then, copy the hours snippet into billing’s notes or add get_hours to billing’s notecard if it is truly needed.

Common mistakes

• Router calls refund.
• One specialist with every tool.
• Verifier that only reads vibes.
• Verify after the wire transfer.
• Calling this a multi-agent platform.
• Nested god-loop as “router.”

Run to execute this in your browser. Nothing is sent to a server.

Refund routes to billing and passes (draft cites policy). Hours route to faq. A poem has no specialist — handoff, not a guess. The verifier never ran a tool. The router never refunded. That is the pattern in three prints.

Keyword routing is blunt. A real router might parse JSON {"kind": "billing"} from a small model. Still an enum. Still fail closed to handoff. Still one runtime.

How agents use this

Ship this before a swarm. Multiagent is for when specialists must talk to each other. Most products need a router and a verifier first.

Traces next will log these roles per step. Tool thrash still applies inside a specialist. Handoff is how the router’s unknown kind leaves the building with a packet, not a shrug.