Pathway Routing

Route agent work to the right level of intelligence, context, and review.

This pattern extends the public idea in Just Enough Intelligence: use the strongest intelligence where judgment matters, and route lower-risk work through bounded roles that still come back for review.

For leaders

The problem in one sentence. A source map, a risky code change, and a final recommendation should not run through the same lane.

What the pattern changes. Work is classified before it starts, then routed to the lane that fits its risk, reasoning need, context source, and review requirement.

The failure it prevents. Expensive judgment being wasted on low-risk work, or helper output being treated as final authority.

What to ask your team. Which parts of our agent work need final-authority reasoning, and which parts only need bounded exploration before review?

The Problem

A quick source map is one job. A risky code change is another. A security review, first-pass outline, and final recommendation each ask for a different level of reasoning, context, and review.

Context needs the same treatment. Raw notes, working notes, curated knowledge, trusted artifacts, and repo-state memory should not arrive with the same authority. If they do, the answer may sound confident while resting on a draft, a candidate, or a stale operating note.

When every task goes through one lane, the system pays twice. Routine work burns the strongest model by default. High-stakes work can move too quickly because nothing forces it to slow down, gather the right context, or come back for review. Context gets flattened, so the final answer cannot show which sources were working material, which were reviewed, and which still need a human check.

That is bad token economics and bad judgment control. The strongest model carries too much routine work. Lower-trust output can become trusted before anyone has checked whether it deserves that trust.

The Pattern

Classify every incoming task before work starts. The classification asks five questions:

1. What kind of work is this?
2. How much reasoning does it need?
3. What is the risk of being wrong?
4. Which context source is allowed?
5. What review must happen before the output is trusted?

Those answers select a pathway.

Low-risk, well-understood work can use a direct build path or an economy helper lane. Source mapping, rough comparison, open-question extraction, and first-pass outlines can go to bounded helper roles. Complex coding, hard synthesis, security review, and final recommendations stay with stronger lanes.

The same decision applies to context. A task may use raw notes only for orientation, working notes for current-state discovery, curated knowledge for reusable context, trusted artifacts for handoff, and repo-state memory for hygiene or closeout questions. The pathway record should name the context class, not just the model lane.

The orchestrator owns the route. It breaks the request into smaller jobs, assigns bounded roles, selects the context lane, collects the handoffs, and keeps final synthesis centralized. Helper lanes can contribute useful work, but they do not become final authority by themselves.

Four properties keep pathway routing honest:

• Right-sized intelligence. Use the strongest model where judgment matters, and cheaper lanes where the work is bounded.
• Context discipline. Give each role just the context it needs, with source class and trust state visible.
• Reviewable handoffs. Helper output returns with a role, source, scope, missing inputs, and review status.
• Centralized authority. The orchestrator accepts, revises, or rejects helper output before it enters the final answer.

Diagram

flowchart TB
    task["Incoming task"] --> classify["Classify work"]
    classify --> kind{"Task kind"}
    classify --> reasoning{"Reasoning need"}
    classify --> risk{"Risk if wrong"}
    classify --> context{"Context source"}
    classify --> review{"Review need"}

    kind --> route["Pathway decision"]
    reasoning --> route
    risk --> route
    context --> route
    review --> route

    route -->|routine, low risk| direct["Direct path"]
    route -->|bounded exploration| helper["Helper lane"]
    route -->|technical change| worker["Worker lane"]
    route -->|high risk or unclear| safe["Safe lane"]
    route -->|final judgment| primary["Primary reasoning lane"]

    helper --> handoff["Reviewable handoff"]
    worker --> handoff
    direct --> handoff
    safe --> gate["Review gate"]
    primary --> synth["Final synthesis"]

    handoff --> synth
    gate --> synth
    synth --> out["Result with pathway record"]

Template Or Small Example

A pathway policy can be written as a routing table. It should route the work lane and the context lane together.

Work type	Useful lane	Context allowed	Review before trust
Source map or likely-file search	Helper lane	Working notes or repo-state memory	Spot check or orchestrator review
First-pass comparison or outline	Helper lane	Working notes and curated knowledge	Orchestrator review
Routine local edit with tests	Worker lane	Owning repo and relevant curated notes	Test and review
Security, regression, or source-fidelity check	Reviewer lane	Owning repo, evidence, and trusted artifacts	Findings reconciled by orchestrator
Hard synthesis or important recommendation	Primary reasoning lane	Curated knowledge and trusted artifacts	Final review required
Unclear, high-stakes, or outward-facing work	Safe lane	Bounded source packet only	Human or explicit review gate

As pseudocode, the router is a decision function:

route(task):
    kind = classify_kind(task)
    reasoning = estimate_reasoning_need(task)
    risk = estimate_risk(task)
    context = choose_context_source(task)
    review = required_review(task)

    if risk is high or kind is unclear:
        return (SAFE_LANE, context, "high risk or unclear scope")

    if review is final_authority:
        return (PRIMARY_REASONING_LANE, context, "final judgment required")

    if kind in {source_map, comparison, outline, open_questions}:
        return (HELPER_LANE, context, "bounded first-pass work")

    if kind in {implementation, tests, refactor}:
        return (WORKER_LANE, context, "bounded technical change")

    return (PRIMARY_REASONING_LANE, context, "default to stronger review")

The pathway record names the lane, the reason, the role, the context source, and the review requirement.

Failure Mode It Guards Against

The failure it prevents is misplaced authority.

One version is waste: every subtask uses the strongest model, largest context, and deepest reasoning even when the work is a bounded first pass.

The other version is risk: helper output looks complete, so it slips into the final answer without the review that should have happened. A related context failure happens when raw or working material is treated like curated knowledge because the pathway record never named the source class.

Pathway routing separates contribution from authority. A helper can map sources, outline options, or compare evidence. A retrieval lane can provide context while proof stays with reviewed sources and human checks. The orchestrator still owns the final synthesis and the review decision.

What This Pattern Does Not Prove

Correct routing does not guarantee correct output. A task can be sent to the right lane and still be handled poorly. A helper can produce a useful map and still miss an important source. A reviewer can miss a defect.

This pattern controls where work goes, what context it receives, and when review is required. It does not prove that each lane performs well. Lane quality must be tested separately.

Proof Note

The routing table is reproducible without a private system. A reader can take a list of agent tasks, classify each one by work type, reasoning need, risk, context source, and review requirement, then assign a pathway.

The public article Just Enough Intelligence provides the source idea: multi-agent orchestration can control cost, preserve judgment, and use context more efficiently when work is split into bounded roles with reviewed handoffs.