Given a task, produce three outputs in order:

1. Routing Plan — decompose the task, identify constraints (latency, cost, data sensitivity, required tools), and list candidate capabilities.
2. Capability Match — score each candidate against the task requirements, pick a winner (and fallback).
3. Execution Path — concrete sequence of steps/handoffs to execute the winning match, including fallback trigger conditions.

Example call:

Task: "Summarize this 40-page PDF and extract action items into a table."
→ Routing Plan: doc-parsing + summarization + structured-extraction
→ Capability Match: pdf-reader-skill (0.95) > vision-ocr-agent (0.4)
→ Execution Path: parse PDF → chunk → summarize per chunk → merge →
  extract action items → format as table

Progress:

• Step 1: Parse the task — identify explicit ask, implicit sub-tasks, and hard constraints
• Step 2: Enumerate candidate capabilities (agents, skills, tools, APIs) that could plausibly handle each sub-task
• Step 3: Score each candidate on: capability fit, reliability, cost/latency, data/access constraints
• Step 4: Select primary match + fallback(s); note conditions that trigger fallback
• Step 5: Sequence the execution path, including handoff points between capabilities
• Step 6: Output Routing Plan / Capability Match / Execution Path

1. Parse the task

Break the request into atomic sub-tasks. Flag ambiguity explicitly rather than guessing silently — state the assumption made.

2. Enumerate candidates

List every capability that has plausible overlap with the sub-task, even weak matches — scoring happens next, not here.

3. Score candidates

Use a simple weighted scale (0.0–1.0) per criterion:

• Capability fit (does it actually do this?)
• Track record / reliability
• Cost & latency budget fit
• Constraint compatibility (permissions, data locality, format support)

4. Select match

Primary = highest score clearing a minimum fit threshold (~0.7). Always name at least one fallback with its trigger condition (e.g., "if primary times out >5s" or "if confidence <0.6").

5. Sequence execution

Order steps so outputs of one capability feed correctly into the next. Mark parallelizable steps explicitly.

6. Output

Always return the three-section format, even for trivial routes.

Example 1: Input: "User wants real-time translation of a live audio call plus a post-call summary." Output:

Routing Plan:
- Sub-task A: streaming speech-to-text + real-time translation
- Sub-task B: post-call transcript summarization
- Constraints: low latency for A, batch-tolerant for B

Capability Match:
- realtime-asr-translate-agent (0.9) > batch-translate-api (0.3) [for A]
- summarization-skill (0.92) [for B]

Execution Path:
1. Stream audio → realtime-asr-translate-agent (parallel, per-utterance)
2. Log full transcript in background
3. On call end → feed transcript to summarization-skill
4. Return: live captions during call, summary after call ends
Fallback: if realtime-asr-translate-agent latency >800ms, degrade to
captions-only (no translation) and flag for manual review.

Example 2: Input: "Route: classify this support ticket and assign to the right team." Output:

Routing Plan:
- Sub-task: intent classification → team assignment lookup
- Constraint: must complete <200ms, no external API calls (PII)

Capability Match:
- local-intent-classifier (0.88) > llm-zero-shot-classifier (0.6, rejected: too slow)

Execution Path:
1. Ticket text → local-intent-classifier → intent label
2. Intent label → static routing table → team ID
3. Return team ID + confidence score
Fallback: if confidence <0.5 → route to "triage-human" queue