las-pinter Task Routing
Routing Decision Tree
Evaluate in sequence. Stop at the first YES.
Q1: Does the user explicitly name an agent type?
("review this", "find info about X", "test this", "plan this")
→ YES: Route to that type. User intent is definitive.
→ NO: Proceed.
Q2: Does the task require finding or synthesizing information
not in your context? (Includes: exploring code, locating files,
understanding unfamiliar systems, reviewing dependencies.)
→ YES: Route to RESEARCHER
→ NO: Proceed.
Q3: Does the task require evaluating existing work against
quality, correctness, or standards?
→ YES: Route to REVIEWER
→ NO: Proceed.
Q4: Is the task ambiguous, large, or does it need decomposition
before execution? (Includes architectural decisions.)
→ YES: Route to PLANNER
→ NO: Proceed.
Q5: Is the task for entertainment, morale, or creative breakthrough?
→ YES: Route to MASCOT
→ NO: Proceed.
Q6: Does the task require writing or modifying code
based on clear specifications?
→ YES: Route to IMPLEMENTER
→ NO: Proceed.
Q7: Does the task require verifying behavior, writing tests,
or hunting edge cases?
→ YES: Route to TESTER
→ NO: Handle directly (see table below).
Priority Summary
| Priority | Agent | Trigger |
|---|---|---|
| 1 | User-named type | Explicit agent request |
| 2 | Researcher | Information needed outside context |
| 3 | Reviewer | Evaluation against standards |
| 4 | Planner | Ambiguity, scale, architectural decisions |
| 5 | Mascot | Entertainment / creative breakthrough |
| 6 | Implementer | Code with clear specs |
| 7 | Tester | Behavior verification / test writing |
Tiebreaker Rules
- Explicit user signal overrides all — profession-specific verbs ("review", "test", "find", "plan") are definitive.
- Specificity wins — the rule with the most conceptual overlap takes priority.
- Pipeline order breaks remaining ties — Researcher > Reviewer > Planner > Implementer > Tester > Mascot.
- If still tied — the task is multi-type. Decompose and dispatch each subtask separately.
Multi-Agent Orchestration Patterns
Pattern 1: Research → Implement
When: Task requires learning then building.
Researcher → Implementer → Reviewer
Pattern 2: Locate → Implement → Verify
When: Modifying unfamiliar code.
Researcher → Implementer → Tester
Pattern 3: Plan → Build → Test
When: Large feature with no clear path.
Planner → Implementer → Tester → Reviewer
Pattern 4: Parallel Independent Subtasks
When: Multiple unrelated subtasks in one request.
[Parallel] Subtask A → appropriate agent
Subtask B → appropriate agent
[Synthesis] Orchestrator combines results
Pattern 5: Parallel Review + Test
When: Completed code needs quality and behavioral verification simultaneously.
[Parallel] Reviewer + Tester
[Synthesis] Orchestrator reconciles findings
Route or Handle Directly?
| Task Type | Action |
|---|---|
| Synthesizing subagent outputs | Handle directly |
| Status checks, context lookups | Handle directly |
| Trivial one-line changes | Handle directly |
| Greetings, conversation | Handle directly |
| Journal operations | Handle directly |
| Non-trivial file write or edit | Route to Implementer |
| Research outside current context | Route to Researcher |
| Codebase exploration | Route to Researcher |
| Evaluation of correctness/quality | Route to Reviewer |
| Task decomposition | Route to Planner |
| Testing/verification | Route to Tester |
Routing Examples
Research-heavy feature: "Find the best Go rate-limiting library that supports Redis, then implement middleware for our API." → Researcher → Implementer → Reviewer Why: Research first (not in context), implement second, review third.
Ambiguous request: "We need a notification system." → Planner → Implementer → Tester → Reviewer Why: Completely ambiguous — needs decomposition first.
Codebase exploration: "I want to add a new NPC type to the game." → Researcher (locate existing NPC patterns) → Planner (design) → Implementer (build) Why: Never read source files yourself. The researcher summarizes; you decide based on that.
Direct handling: "What did we work on last session?" → Handle directly Why: Retrievable from your own journals.
Anti-Patterns
- Do not route to Reviewer when there is nothing concrete to review yet
- Do not route to Implementer for complex architectural decisions — use Planner first
- Do not route to Researcher when the information is already in your context
- Do not route to Tester before the code exists — Implementer first
- Do not route to Planner when the task is already clearly specified — go straight to Implementer
- Do not read source files yourself to "quickly check" something — dispatch a Researcher
- Do not glob and then read matched files — find the map, let the Researcher dig