hermes - 💡(How to fix) Fix Feature: Branch Table Delegation — run cheap subagents on pre-computed decision maps with tiered escalation [1 participants]

Problem

When delegate_task spawns a subagent, the subagent gets a goal + context and must figure everything out from scratch — even when the parent already knows most of the possible outcomes. This forces a wasteful trade-off:

• Spawn on an expensive model — wasting tokens on straightforward tool execution
• Spawn on a cheap model — getting poor results when edge cases appear
• Write a detailed step-by-step plan in context — still unstructured, the cheap model has to think its way through every branch

What we need: a protocol where the parent pre-computes the decision space and the cheap subagent does pattern-matching + reporting — not open-ended reasoning.

The Idea: Branch Table Delegation

Instead of:

delegate_task(
    goal="Check if X website supports feature Y",
    context="Here is the URL, go figure it out"
)

You give the subagent a branch table — a map of all anticipated outcomes with escalation triggers encoded in the plan:

branch_table:
  - condition: "Page loads successfully"
    checks:
      - "Feature Y toggle is visible"
      - "Feature Y toggle is functional"
    branches:
      ok:
        action: report_with_evidence
      not_found:
        action: escalate
        tier: overseer
        prompt: "Could not find toggle — possibly renamed or removed"
      broken:
        action: escalate
        tier: overseer
        prompt: "Toggle found but click failed — investigate"

  - condition: "Page returns 404 or redirect"
    branch:
      action: escalate
      tier: human
      prompt: "URL may be dead — verify or provide alternative"

  - condition: "Page requires authentication"
    branch:
      action: report
      format: "Auth-gated — can't verify without credentials"

  - default:
      action: escalate
      tier: overseer
      prompt: "Unexpected state: {observed_state}"

How It Works

1. Parent compiles the branch table — the expensive model thinks once about what could happen, encodes all known paths with escalation targets.

2. Cheap subagent executes mechanically — its job is: try step, check observed outcome against branch conditions, report branch name + evidence. No open-ended reasoning required. A Gemini Flash, DeepSeek V4 Flash, or GPT-4.1 Nano can do this reliably because it's pattern-matching, not problem-solving.

3. Two-tier escalation:

   • Overseer (medium model, e.g. Sonnet / GPT-5.1) — fires when the observed outcome doesn't match any expected branch. The overseer analyzes the situation, extends the branch table, and dispatches a new subagent with the revised map.
   • Human — fires when the overseer can't resolve it, or when the default branch explicitly routes to human.

4. Escalation carries structured context: expected branch, observed state, what was tried, raw evidence. The overseer gets a clean delta — "here's what we expected, here's what happened" — instead of a raw log dump.

Why This Is New

The subagent doesn't think — it matches and reports. That means significantly cheaper models work for delegation without quality loss, because the reasoning was already done by the parent when it built the branch table.

Relationship to Existing Issues

• #20249 (Model Presets) — complementary. Model Presets define what models exist; this defines how a cheap model follows a plan with escalation.
• #15789 (per-task model overrides) — solves a different axis. #15789 lets you pick which model runs each task; this changes how the task is structured (plan vs. open-ended goal).
• #1719 (subagent-to-orchestrator queries) — closest relative, but this formalises when the subagent asks back (only at branch-table boundaries) and who it asks (overseer model → human, not just parent).
• #9459 (agent profiles) — profiles define static subagent configs; this defines a runtime protocol within a single delegation call.

Implementation Sketch

1. Schema extension

delegate_task gets a new optional field on each task item:

{
    "goal": "...",
    "context": "...",
    "branch_table": {
        "escalation_model": "claude-sonnet-4-6",  # medium model for overseer
        "max_escalation_depth": 2,                # cycles before routing to human
        "conditions": [
            {
                "description": "Page loads successfully",
                "checks": ["X toggle visible", "X toggle clickable"],
                "branches": {
                    "ok":              {"action": "report"},
                    "not_found":       {"action": "escalate", "tier": "overseer"},
                    "broken":          {"action": "escalate", "tier": "overseer"}
                }
            }
        ],
        "default": {"action": "escalate", "tier": "overseer"}
    }
}

2. Subagent instruction layer

When branch_table is present, the child agent's system prompt is augmented with:

"You are running in Branch Table mode. Your job is to execute the task and match outcomes against the provided branch conditions. When a branch matches, report the branch name with supporting evidence. When no branch matches, escalate with structured context. Do NOT try to resolve ambiguity — that's the overseer's job."

3. Overseer callback

When escalation fires, a fresh subagent (on the escalation model) receives:

• The original branch table
• What the cheap subagent observed vs. expected
• A task: either extend the branch table and re-dispatch, or escalate to human

The parent agent never sees intermediate steps — only the final resolution or the human-facing escalation message.

Open Questions

1. Branch table format — YAML in the prompt, a JSON schema in the tool definition, or hybrid? JSON is easiest for programmatic parsing but YAML is more natural for human-authored plans.
2. Escalation model source — inline per call, a named preset (referencing #20249), or a new delegation.escalation_model config key?
3. Recursion depth — how many overseer escalation cycles before routing to human? (Suggestion: 1-2, zero-oversight mode possible with max_escalation_depth: 0 routing directly to human)
4. Evidence format — what does a cheap subagent include in its report? Raw terminal output? TL;DR? Both? A structured {branch, evidence, confidence} envelope?
5. Mandatory default — should a default branch be required (forcing the parent to think about "what if it's all wrong") or optional (silently escalate by default)?
6. Dynamic branch table mutation — can the parent skip writing everything upfront and instead define an "if X then call overseer to generate sub-branches dynamically"? This avoids blowing up the branch table for problems with deep trees.