Feature Request: Lead-Agent Context-Aware Review of Teammate Tool Calls (post Auto Mode)

Update (2026-04-16): Claude Code's Auto Mode (model-driven per-call risk evaluation, Shift+Tab to toggle) addresses the original UX pain point — approval-prompt flood in agent teams. This issue is now narrowed to the remaining architectural gap: lead-agent context-aware review of teammate tool calls, which Auto Mode doesn't cover because it evaluates calls session-locally rather than at the lead level.

Summary

Auto Mode solves "should this tool call be approved?" at the level of a single agent evaluating its own actions. But in Agent Teams, the lead holds context that individual teammates don't — the task decomposition, each teammate's assigned scope, and the overall plan. Using that context for permission decisions (not just plan approval) would catch a class of problems Auto Mode structurally can't see.

The Gap Auto Mode Doesn't Close

| Dimension | Auto Mode (today) | Lead-as-proxy (this request) |
|---|---|---|
| Who evaluates | Each agent evaluates its own tool calls | Lead evaluates teammates' tool calls |
| Context available | Only the agent's own brief | Full task decomposition + each teammate's assignment |
| Scope enforcement | Can't detect "teammate acting outside its assignment" | Can catch misaligned actions (e.g., frontend teammate editing auth) |
| User-configurable bright lines | Model judgment only | Patterns like alwaysEscalateToHuman |
| Bounds as hard ceiling | Each subagent decides independently within its permissions | Lead's bounds act as a hard ceiling on teammate authority |

The key insight: scope-misalignment is invisible to a self-evaluating agent. If a teammate was assigned "update the login UI" but requests Edit(src/auth/session-store.ts), Auto Mode in the teammate's session sees a reasonable-looking edit. Only the lead knows the edit is outside the teammate's brief.

Proposed Solution

Extend the existing "lead approves teammate plans" pattern to tool calls:

Teammate requests tool call
  └── Lead evaluates against:
       ├── User's permission bounds (hard ceiling — lead can never exceed)
       ├── Teammate's assigned scope (does this call fit the assignment?)
       ├── Risk assessment (destructive / irreversible?)
       └── User-configured escalation patterns
  └── Decision: approve | deny with feedback | escalate to human

Why the lead is uniquely positioned

• Already approves teammate plans autonomously — extending to tool calls is a natural progression
• Already holds the task decomposition and each teammate's scope
• Can catch cross-agent misalignment no self-evaluator can see
• User trust already flows lead → teammates; formalizing it for permissions matches the existing mental model

Configuration sketch

{
  "agentTeams": {
    "permissionCascading": true,
    "leadCanApprove": ["Edit(src/**)", "Bash(npm *)"],
    "alwaysEscalateToHuman": ["Bash(rm *)", "Bash(git push *)"]
  }
}

Or simpler: inherit from the lead's permission mode — if the user trusts the lead with Edit(src/**), the lead can approve the same for teammates within scope.

Why This Still Matters After Auto Mode

Auto Mode made agent teams usable. This would make them coherent — catching the class of failures where a teammate's action looks locally reasonable but globally wrong. That's not a UX complaint; it's a supervision-quality gap.