# Agent Delegation Decision Framework

> **This document governs how the lead agent decides between working solo, spawning subagents, or creating agent team members. Follow this framework before beginning any task.**

## Critical Rule: Ask Before Delegating

**Before spawning any subagents or agent team members, you MUST present your delegation plan to the user and wait for explicit approval.** Do not spawn agents autonomously. Outline:

1. What you intend to do yourself
2. What you propose to delegate (and to whom — subagent or teammate)
3. Why you believe delegation is the right call
4. Estimated scope/complexity of each delegated unit

Only proceed after the user confirms. If the user is unavailable or unresponsive, default to working solo or using subagents for clearly isolated tasks.

---

## Decision Matrix

Ask yourself these questions in order. The first match determines your approach.

### Do It Yourself When:

- The task is **sequential** — each step depends on the output of the previous one
- The work involves **a single file or tightly coupled set of files** where changes interleave
- The task is **small and well-defined** — completable in under ~10 minutes of focused work
- You need to **understand the full picture** before any work can begin (discovery/orientation phase)
- The task is **conversational** — the user is iterating with you in real-time and expects back-and-forth
- You are **debugging a single hypothesis** with a clear investigation path
- The total scope is narrow enough that context window degradation is not a concern

### Spawn Subagents When:

- The task can be **decomposed into independent, fire-and-forget units** that don't need to talk to each other
- You only need **the result**, not ongoing collaboration — subagents report back and you synthesize
- The subtasks are **focused and bounded** (e.g., "run the test suite and report failures," "search the codebase for all usages of X," "lint this module")
- You want to **parallelize simple work** without paying the coordination overhead of a full team
- The subtasks touch **different files or modules** with no overlap
- You need a **quick validation or check** while continuing your own work
- The work is **routine** — no judgment calls, competing tradeoffs, or ambiguity that would benefit from debate

**Subagent guidelines:**
- Keep spawn prompts specific and self-contained — include all context the subagent needs
- Prefer fewer, well-scoped subagents over many tiny ones
- Do not spawn subagents for work that requires access to your conversation history — they don't have it

### Spawn Agent Team Members When:

- The task benefits from **agents communicating with each other**, not just reporting back to you
- Multiple agents need to **challenge, validate, or build on each other's findings** (e.g., competing hypotheses, multi-angle review)
- The work spans **multiple layers or domains** that must stay coordinated (frontend + backend + tests, each owned by a different agent)
- The task is **large enough that context window degradation in a single session would hurt quality** — splitting ownership across agents preserves focus
- You need **parallel exploration where discoveries in one area should influence work in another**
- The scope justifies the **~5x token cost overhead** relative to a solo session
- You have **3+ distinct, parallelizable workstreams** that benefit from specialization

**Agent team guidelines:**
- Define clear ownership boundaries — each teammate should own different files. Two teammates editing the same file leads to overwrites
- Use **delegate mode** (Shift+Tab) to keep yourself focused on coordination, not implementation
- Use **plan approval mode** for risky or complex tasks — require teammates to submit plans before they touch code
- Size tasks at roughly 5–6 per teammate — not too granular, not too sprawling
- Prefer broadcasting sparingly — every broadcast multiplies token cost by team size
- Shut down teammates as they complete their work to stop burning tokens

---

## Anti-Patterns — Do NOT Do These

| Anti-Pattern | Why It's Wrong | Do This Instead |
|---|---|---|
| Spawning a team for a single-file bug fix | Coordination overhead far exceeds the work | Do it yourself |
| Using subagents when agents need to share mid-task findings | Subagents can't message each other — you become the bottleneck | Use agent team members |
| Spawning teammates that edit the same files | No merge conflict resolution — overwrites will happen | Assign non-overlapping file ownership |
| Letting the lead implement while teammates are working | You lose coordination focus and risk conflicts | Use delegate mode |
| Spawning agents without telling the user | User loses visibility and cost control | Always ask first per the critical rule above |
| Using agent teams for sequential/dependent work | Teammates block on each other and waste tokens idling | Do it yourself or use subagents in sequence |
| Broadcasting status updates to all teammates | Each broadcast costs tokens in every teammate's context | Message only the relevant teammate(s) |

---

## Quick Reference

```
Is the task small, sequential, or tightly coupled?
  → YES → Do it yourself.

Can it be split into independent chunks that just need results?
  → YES → Subagents.

Do the workers need to talk to each other, debate, or coordinate?
  → YES → Agent team members.

Unsure?
  → Ask the user. Present your reasoning and let them decide.
```

---

## Cost Awareness

- **Solo session**: Baseline token cost
- **Subagents**: Moderate increase — each subagent has its own context but only reports results back
- **Agent teams**: ~5x baseline — each teammate maintains a full independent context window, and inter-agent messages consume tokens on both ends

Always factor cost into your delegation recommendation when presenting your plan to the user. If the task can be done well solo or with subagents, say so — don't reach for agent teams by default.

---

## Arch

engineering-vault/
├── CLAUDE.md
├── .gitignore
├── .claude/
│   ├── settings.json
│   ├── settings.local.json
│   ├── agents/              ← 12 predefined specialist agents
│   │   ├── researcher.md
│   │   ├── architect.md
│   │   ├── pm.md
│   │   ├── backend-dev.md
│   │   ├── frontend-dev.md
│   │   ├── data-engineer.md
│   │   ├── ai-engineer.md
│   │   ├── devops.md
│   │   ├── code-reviewer.md
│   │   ├── qa-tester.md
│   │   ├── documentation.md
│   │   └── performance-evaluator.md
│   ├── commands/            ← 10 phase slash commands (NEW)
│   │   ├── idea.md          → /idea     (Phase 1)
│   │   ├── research.md      → /research (Phase 2)
│   │   ├── design.md        → /design   (Phase 3)
│   │   ├── spec.md          → /spec     (Phase 4)
│   │   ├── plan.md          → /plan     (Phase 5)
│   │   ├── dev.md           → /dev      (Phase 6)
│   │   ├── test.md          → /test     (Phase 7)
│   │   ├── evaluate.md      → /evaluate (Phase 8)
│   │   ├── update-system.md → /update-system (Phase 9)
│   │   └── status.md        → /status   (anytime)
│   └── skills/              ← 5 reusable skills (NEW)
│       ├── critique/SKILL.md        → structured review framework for any artifact
│       ├── cost-tracker/SKILL.md    → token estimation, logging, budget checks
│       ├── mermaid-diagrams/SKILL.md → diagram types, style guide, examples
│       ├── ticket-format/SKILL.md   → standardized ticket template with sizing
│       └── research-report/SKILL.md → structured research output format
└── docs/
    └── AGENT_DELEGATION.md