Orchestrator has no diagnostic context when subagent fails — blindly retries or fabricates results

Problem

When a Task tool subagent fails, the orchestrator (parent Claude context) receives a near-useless error message — typically just Agent "..." failed: classifyHandoffIfNeeded is not defined or a generic failure string. The orchestrator has zero visibility into:

• What the subagent accomplished before failing
• Why it failed (token budget, crash, scope explosion, tool error)
• How far through the task it got
• Whether retrying will produce the same failure

Without this information, the orchestrator exhibits two equally bad recovery patterns:

Pattern 1: Blind resubmission

The orchestrator re-dispatches the identical task to a new subagent. The new agent hits the same wall, crashes the same way, and the cycle repeats — burning parent context on each attempt until the parent itself runs out of context.

Pattern 2: Confident fabrication

The orchestrator announces something like "The agent encountered an issue, but based on what I know..." and proceeds to answer the original question by hallucinating or inferring what the subagent would have found. This produces unreliable output that the user has no reason to trust, presented with false confidence.

Both patterns waste context and degrade session quality.

Expected Behavior

Structured failure payload

When a subagent fails, the orchestrator should receive a structured error containing:

{
  "status": "failed",
  "reason": "token_budget_exceeded" | "crash" | "max_turns_reached" | "tool_error",
  "tokens_consumed": 47832,
  "turns_completed": 14,
  "partial_results": "Found 3 auth-related files: src/auth/..., src/middleware/..., ...",
  "tools_called": ["Glob x4", "Read x8", "Grep x2"],
  "last_tool_call": { "tool": "Read", "path": "src/auth/session.ts", "status": "success" },
  "suggestion": "Task too broad. Split into: (1) auth middleware, (2) session management, (3) route guards"
}

Orchestrator recovery rules

With structured failure info, the orchestrator should follow explicit rules:

1. Token budget exceeded → Do NOT retry the same prompt. Report partial results to user, suggest narrower follow-up queries.
2. Crash / internal error → Retry once with same prompt. If second failure, report to user.
3. Max turns reached → Return partial results. Ask user whether to continue with a follow-up agent.
4. Tool error → Diagnose which tool failed and why. Fix the precondition (e.g., install missing dependency) before retrying.
5. NEVER fabricate → If the subagent returned no results, the orchestrator must say it has no results. Inferring or hallucinating what the subagent "would have found" is worse than returning nothing.

Reproduction

1. Dispatch a broad Explore agent (e.g., "find all error handling patterns in this codebase")
2. Agent crashes after ~50k tokens (see #25817)
3. Observe the orchestrator's response — it either:

• Re-dispatches the same task verbatim, or
• Says "the agent failed but I can tell you that..." followed by fabricated/inferred content

1. Neither response acknowledges the actual failure mode or adjusts strategy

Impact

• Context hemorrhage — Blind retries burn 2-3x the context on a task that was already too large
• Silent unreliability — Fabricated results look identical to real results in the output. The user cannot distinguish agent-verified findings from orchestrator guesses.
• Compounding failures — Combined with #25815 (no /compact during turns) and #25817 (no subagent token budget), a single broad Task dispatch can consume the entire session: agent crashes → orchestrator retries → agent crashes again → orchestrator fabricates → user has no context left and no reliable information

Related Issues

• #25817 — Subagents lack token budget awareness (the upstream cause of most failures)
• #25815 — No way to interrupt multi-step turns to /compact
• #22312 / #23307 — classifyHandoffIfNeeded crash (the error the orchestrator receives but cannot interpret)

Environment

• Platform: Windows 11
• Claude Code: latest
• Model: Opus 4.6