Routing and decomposition are often treated as one planning step. They are not. Routing decides who should handle a request; decomposition decides whether the request should be split into pieces. A system can route well and decompose badly, or decompose a task that should never have left a single handler. The two decisions need different evidence and different failure handling.
Route before you decompose
Intent routing is the clean version: one request asks a Choice over four intents (order status, product question, return, complaint) plus a Score for complexity. Intent confidence below 0.5 routes to a human. order_status goes to deterministic code with no model call, while complaints escalate when complexity exceeds level 1 or confidence falls below 0.5.
The important detail is that the router does not handle anything. It produces an answer and a confidence, and code sends the request to deterministic code, a specialist model, or a person. Decomposition should not happen before that branch. A request headed for order_status does not need a task DAG; it needs a database lookup.
The failure mode is confidently misrouted work. The pattern's caveat says to route on the pair of answer and confidence, not either alone. A high-confidence wrong intent is worse than a low-confidence right one, because it never reaches review.
Decomposition is a shape decision
Once a request is routed to an agent, the next question is whether it is one job or several. Jev Codex Factory makes that explicit. A first Jev call, labelled shape #0, asks whether the task is single-agent or should become a DAG. A single answer routes to one Codex agent with a chosen model and effort; decompose produces a task DAG with parallel workers A, B, and C. Verification gates every change, and a failure goes to a second Jev call that classifies it as retry, escalate, block, or needs human. Blocked work can resume later.
The README targets jobs with independent subtasks, different reasoning difficulty, flaky verification, partial failures, and interrupted sessions. It also says small tasks do not need the factory. That is the right boundary. Decomposition buys parallelism and isolation; it costs coordination, duplicated context, and more places for a failure to hide.
The project is early: Apache-2.0, created in late September 2026, one star at review time, and no benchmark or pricing figures in the captured README. Treat the shape as a design, not a proven win.
Hierarchies need search, not one prompt
When the decomposition is a taxonomy rather than a task graph, a single classification prompt is the wrong tool. The hierarchical classification cookbook runs parallel beam search over Choice probabilities. Each sibling set becomes one Choice question keyed c0, c1, and so on; beam paths run as parallel questions, so extra exploration barely adds latency. Paths are scored by the geometric mean product(p) ** (1/decisions), which is length-normalized so shallow and deep leaves compare fairly.
On four labeled hierarchies, beam K=3 matched 4 of 4 expected leaves while greedy matched 2 of 4, recovering CPC patents and Shopify products. The other taxonomies are MeSH 2026, a DAG expanded into tree paths, and a frozen CookSafe snapshot. Defaults are model jev-1.12, beam width 3, max depth 12, and a RetryPolicy with five retries. For hierarchies deeper than about 10 levels, the cookbook recommends exp(mean(log(probs))) instead of the product formula to avoid precision errors.
Greedy search cannot recover an early wrong turn. That is the whole argument for paying for a wider beam, and it is also a warning: if your taxonomy is shallow and unambiguous, greedy may be enough.
Model and effort routing is its own decision
Routing a request to a model is not the same as routing it to a handler. Pi TypeSafe Router classifies each request and routes it to one of three configured models. It supports TypeSafe, Cloudflare AI Gateway, Vercel AI Gateway, and OpenRouter backends. It starts off until enabled, has a doctor command that tests the classifier and configured models with synthetic requests, and a shadow mode for watching decisions before traffic is rerouted. The README warns against running it alongside another automatic router.
Typesafe Jev Dojo shows the same decision as three questions: model tier, ambiguity, and blast radius. Its router climbs tool → haiku → sonnet → opus → fable. Triage asks about ten typed questions per ticket in one batched call, around 450 ms; the queue scene fans 8 × 10 questions over tickets in about 600 ms. Without an API key it boots in SIM mode with locally generated decisions. The README marks the whole dojo advisory: every scene shows the confidence or escalates low-confidence cases rather than acting blindly.
The evidence should temper the enthusiasm. In Fast Models, Slow Evidence, neither model beat chance on zero-shot model routing across 11 decision points. Model routing is a genuinely hard decision, and a router that looks good on demos may be guessing on your traffic.
Plans from multiple agents
Jev Planner decomposes at the level of planning rather than execution. Two or more agents draft independently (Codex and Claude by default, with DeepSeek, Kimi, and GLM supported), and Jev scores completeness, feasibility, and risk coverage. It decides whether a cross-review is worth it, then selects a finalizer that merges the strongest ideas. --mode fast judges each draft alone as it arrives and takes the first one Jev accepts; every round is saved under .jev-planner/<run>/.
The caveats are substantial: no benchmarks or pricing figures are published, and running it needs paid access to at least two agent providers plus a TypeSafe key. The catalog lists it as MIT with zero stars. Multiple drafts are a way to widen the candidate set, not a guarantee that the merged plan is better. Measure the plan against the same acceptance checks you would use for a single agent.
Fan-out is related but not the same. Speculative fan-out asks several questions about one state in parallel; it does not create parallel workers. Use it to avoid a round trip when several branches might need the same judgment, and remember that every speculative question adds input tokens on every call.
Measure at the level you deploy
AgentDecisionBench is the right frame for this topic because it separates L1 isolated questions (3,991 items from BFCL v4 and When2Call), L2 open-loop questions over recorded states (3,939 distinct questions, an answer key of 5,314 trajectory occurrences, and 153,621 answers from 39 models), and L3 closed-loop runs where the choice actually drives the agent. A router that scores well on L1 can still fail at L3, because L3 includes the consequences of the choice.
The practical checklist follows from that:
- Route first, with an explicit confidence floor and a human path.
- Decompose only when subtasks are independent enough to survive coordination.
- Use beam search for deep hierarchies, and keep the scoring in code.
- Put model routers behind shadow mode and a doctor check.
- Evaluate at the same level you deploy: isolated, open-loop, then closed-loop.
For the broader routing pattern, see Routing Models, Tools, and Skills with Jev; for where gates fit, Decision Gates in Agent Frameworks; and for batching, One Request, Many Questions. The intent-routing and decomposition entries cover the primitives, and hierarchical classification is the taxonomy case in more depth.
