Aapke paas ek feature hai jismein teen cheezein ek saath karni hain. Aap ek single Claude Code session ke andar subagents spawn kar sakte hain aur unhe parallel kaam karne de sakte hain. Ya phir aap kaam ko teen independent tasks mein tod sakte hain, har ek ko alag agent ko uske apne tmux pane mein de sakte hain, aur unhe ek doosre ke baare mein bina jaane chalne de sakte hain.

Dono approaches kaam ko parallelize karti hain. Ve alag problems solve karti hain. Galat chunein aur ya to aap context window coordination overhead mein jalaa denge ya phir merge conflicts create kar denge jo original task se zyada time lete hain fix hone mein.

Yeh woh decision framework hai jo main har roz use karta hoon jab 13 Claude Code agents ek hi codebase par chalata hoon. Yeh theoretical nahi hai. Yeh itni baar galat karne ka result hai ki ab pata hai boundary kahaan hai.

Do tarah ka parallelism

Claude Code do alag tarike se concurrent kaam support karta hai.

Subagents child processes hain jo ek single Claude Code session ke andar spawn hote hain. Parent agent multiple subagents launch karta hai, har ek problem ka ek hissa handle karta hai, phir results collect karta hai. Ve same working directory aur parent ka context share karte hain. Inhe ek single process mein threads samjhein.

Parent agent
  ├── Subagent A: "Search lib/ for all usages of parseConfig"
  ├── Subagent B: "Search server/ for all usages of parseConfig"
  └── Subagent C: "Search components/ for all usages of parseConfig"

Separate agents independent Claude Code sessions mein chalte hain, typically alag tmux panes mein. Har ek ki apni context window, apni CLAUDE.md identity file, aur codebase ki apni view hoti hai. Ve memory share nahi karte. Ve artifacts ke through communicate karte hain: task comments, status updates, committed code. Inhe alag processes samjhein jinka koi shared state nahi hai.

tmux pane 1: eng1 agent → "Build the REST endpoint"
tmux pane 2: eng2 agent → "Build the React component"
tmux pane 3: qa1 agent  → "Write integration tests for both"

Mental model zaroori hai kyunki yeh determine karta hai ki kaam units ke beech kaise flow karta hai. Subagents data parent ko cheaply pass kar sakte hain. Separate agents data filesystem, git, ya external task tracker ke through pass karte hain.

Subagents kab jeette hain

Subagents tab use karein jab kaam state share karta ho aur results ko converge hona ho.

Parallel research. Aapko paanch directories mein ek pattern search karna hai, teen documentation files padhni hain, aur findings ko ek recommendation mein synthesize karna hai. Subagents har ek search path le sakte hain, results return kar sakte hain, aur parent unhe bina serialization overhead ke combine kar sakta hai.

Same data par independent transformations. Aap ek module refactor kar rahe hain aur type definitions, tests, aur documentation ko ek coherent change mein update karna hai. Har subagent ek file handle karta hai, lekin parent ensure karta hai ki changes consistent hain kyunki woh commit karne se pehle teeno results dekhta hai.

Fast exploration. Aap debug kar rahe hain aur simultaneously git log, test output, aur runtime config check karni hai. Subagents teeno parallel gather kar sakte hain aur parent diagnosis synthesize karta hai.

Pattern: fan out, gather back, combined result par act karein. Agar aapka parallelism is par khatam hota hai ki parent ko saare outputs ke baare mein saath mein reason karna hai, to subagents sahi tool hain.

Subagents kismein bure hain: koi bhi cheez jo per branch kuch minutes se zyada le, koi bhi cheez jo overlapping paths mein files modify kare, ya koi bhi cheez jisko independent verification chahiye. Subagents working directory share karte hain, to do subagents same file mein likhenge to ek doosre ka kaam corrupt kar denge. Aur kyunki ve context share karte hain, ek long-running subagent parent ki available window khaa leta hai.

Separate agents kab jeette hain

Separate agents tab use karein jab kaam independently verify ho sake aur use make sense ke liye shared context ki zaroorat na ho.

Same feature ke alag components. "API endpoint banao" aur "Frontend banao jo use call kare" integration tak independent hain. API engineer ko React component context mein nahi chahiye. Frontend engineer ko database schema nahi chahiye. Har ek ko apna agent dena ek scoped CLAUDE.md ke saath context clean rakhta hai aur ek agent ki complexity ko doosre ke kaam mein bleed hone se rokta hai.

Alag acceptance criteria. Agar task A tab done hai jab endpoint 200 return kare correct JSON shape ke saath, aur task B tab done hai jab component data ko proper error states ke saath render kare, to ve alag verification targets hain. QA agent har ek ko independently validate kar sakta hai. Subagents independently QA nahi ho sakte kyunki ve ek combined output produce karte hain.

Kaam jo codebase ke alag parts touch karta hai. File ownership merge conflicts rokne ka sabse simple tarika hai. Agent A server/ ka maalik hai, Agent B components/ ka. Koi bhi doosre ke territory mein nahi jaata. Agar aap yeh subagents ke saath try karein, to parent ko file locking manage karni padegi, jo parallelism ka purpose hi defeat kar deta hai.

Alag time horizons wale tasks. Ek task 10 minute leta hai, doosra 2 ghante. Subagents ke saath, parent sabse slow child ka wait karta hai. Separate agents ke saath, short task complete hota hai, verify hota hai, aur ship hota hai jabki long task abhi bhi chal raha hai.

Pattern: fire, forget, separately verify karein. Agar kaam ka har piece akele khada ho sake aur akele check ho sake, to structured tasks ke saath separate agents zyada clean hain.

Handoff ka problem

Asli decision point handoffs par aata hai.

Subagent handoffs cheap hain. Child same context mein parent ko data return karta hai. Koi serialization nahi, koi file writes nahi, koi status update ka wait nahi. Parent teen subagents launch karta hai, ve teen results return karte hain, parent ke paas sab kuch hai.

Separate agent handoffs expensive hain lekin durable. Agent A kaam complete karta hai, code commit karta hai, task status update karta hai, aur comment karta hai kya kiya. Agent B woh signal pick up karta hai (ya to coordinator ke through ya task tracker ko poll karke) aur apna dependent kaam shuru karta hai. Overhead real hai: aapko task system chahiye, status protocol chahiye, aur agents ke liye koi tarika chahiye doosre agents ne kya kiya yeh discover karne ka.

Rule of thumb: agar kaam mein parallel units ke beech ek se zyada handoff chahiye, subagents use karein. Single fan-out-and-gather ke liye subagents simpler hain. Agar Agent A ka output Agent B ka input hai, jo Agent C ka input banta hai, to separate agents ki coordination cost justified hai kyunki har handoff ek verified, committed artifact produce karta hai jo lost nahi hoga agar agent crash ho ya context limit hit kare.

Ek concrete example. Aapko:

Saare API endpoints dhundhne hain jo user data return karte hain
Har ek mein rate limiting add karni hai
Naye rate limits ke liye tests likhne hain
API documentation update karni hai

Steps 1 aur 2 tightly coupled hain. Search results (step 1) directly modification mein feed karte hain (step 2). Ek subagent search handle karta hai; parent changes apply karta hai. Yeh subagent pattern hai.

Steps 3 aur 4 ek doosre se independent hain lekin step 2 par depend karte hain. Tests ko actual endpoint code chahiye. Docs ko final API shape chahiye. Yeh separate agents ke liye separate tasks hain, har ek ke apne acceptance criteria, har ek apne aap verifiable.

Structured task breakdown practice mein

Jab answer "separate agents" ho, aapko feature ko tasks mein decompose karne ka tarika chahiye jo parallel chal sakein bina ek doosre ko interfere kiye.

Decomposition process:

1. Dependency graph identify karein. Kuch bhi split karne se pehle, map karein kya kisse depend karta hai:

Feature: User profile page with activity feed

- API endpoint: GET /users/:id/profile     (no deps)
- API endpoint: GET /users/:id/activity     (no deps)
- React component: ProfileHeader            (depends on profile API)
- React component: ActivityFeed             (depends on activity API)
- Integration test: profile page end-to-end (depends on all above)

Do API endpoints ki koi dependencies nahi hain. Ve parallel chal sakte hain. Do React components har ek ek API par depend karte hain. Integration test sab par depend karta hai.

2. Ownership boundaries draw karein. Har task ko file scope milta hai. Profile API agent server/routes/profile.ts aur server/services/profile.ts ka maalik hai. Activity API agent server/routes/activity.ts aur server/services/activity.ts ka maalik hai. Koi bhi doosre ki files nahi chhoota. Agar shared utility mein modification chahiye, to ek agent change banata hai aur doosra wait karta hai.

3. Har task ke liye acceptance criteria define karein. Har task ko ek clear "done" condition chahiye jo doosre tasks dekhe bina verify ho sake. "Profile API 200 return kare correct shape ke saath" verifiable hai. "Profile page kaam kare" nahi, kyunki yeh integration par depend karta hai.

4. Handoff artifacts specify karein. Downstream agent ko upstream agent se kya chahiye? Usually: known branch par committed code, status update, aur interface contract describe karta hua comment (API shape, component props, function signatures).

Yeh decomposition ek vague "profile page banao" ko paanch discrete tasks mein badal deti hai explicit dependencies aur verification criteria ke saath. Har task aise agent ko assign ho sakta hai jiske paas exactly woh context hai jo use chahiye aur kuch zyada nahi.

Beads structured breakdown ke liye

Yahaan ek real task system hona zaroori hai. Aap paanch parallel tasks ko sticky notes aur terminal output se track nahi kar sakte.

beads ek local-first issue tracker hai jo is decomposition ko natively model karta hai. Ek epic feature represent karta hai. Children subtasks represent karte hain. Dependencies agents ko kaam shuru karne se rokte hain jab tak prerequisites done nahi hote.

Practice mein breakdown aisa dikhta hai:

# Create the epic
bd create --title "User profile page with activity feed" \
  --type epic --priority p2

# Create subtasks as children
bd create --title "GET /users/:id/profile endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "GET /users/:id/activity endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "ProfileHeader React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-api

bd create --title "ActivityFeed React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-activity-api

bd create --title "Profile page integration test" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-header,bb-activity-feed

Ab structure explicit hai. bd show bb-profile-header chalane wala agent dekhta hai ki yeh profile API task par depend karta hai. Agar woh task abhi done nahi hai, agent jaanta hai ki shuru nahi karna. Jab API agent finish karta hai aur apna task complete mark karta hai, frontend agent ki dependency clear ho jaati hai.

Agent workflow ek predictable loop follow karta hai:

# Agent claims the task
bd update bb-profile-api --claim --actor eng1

# Agent comments its plan before writing code
bd comments add bb-profile-api --author eng1 "PLAN:
1. Create route handler at server/routes/profile.ts
2. Add service layer at server/services/profile.ts
3. Return shape: { id, name, avatar, bio, joinedAt }
4. Test: curl localhost:3000/users/1/profile returns 200"

# Agent implements, tests, commits
# ...

# Agent marks done with verification steps
bd comments add bb-profile-api --author eng1 "DONE: Profile endpoint implemented.
Returns { id, name, avatar, bio, joinedAt }.
Verified: curl returns 200 with correct shape.
Commit: abc1234"

bd update bb-profile-api --status ready_for_qa

Har step recorded hai. QA agent DONE comment padhta hai aur exactly jaanta hai kaise verify karna hai. Downstream agent PLAN comment padhta hai aur code finish hone se pehle hi API contract jaanta hai.

Yeh process ke liye overhead nahi hai. Yeh woh minimum structure hai jo paanch parallel agents ko paanch incompatible code pieces produce karne se rokta hai.

Default choice

Months tak production kaam par parallel agents chalane ke baad, yeh mera decision tree hai:

Subagents se shuru karein jab:

Task research ya exploration ho (search, read, compare)
Results ko ek single action mein converge hona ho
Saara kaam ek context window mein fit ho
Har parallel unit ki independent verification ki zaroorat na ho

Separate tasks par switch karein jab:

Kaam ke alag parts alag files touch karein
Har piece ke apne acceptance criteria hon
Aap chahein ki QA pieces ko independently verify kare
Kaam itna lamba hoga ki ek piece doosre se ghanton pehle finish ho sakta hai
Agents ko alag context chahiye (frontend agent ko database internals nahi chahiye)

Complex features ke liye hybrid approach: Research aur planning phase ke liye subagents use karein (fan out, information gather, plan synthesize karein), phir implementation ko independent agents ke liye separate tasks mein break karein. Spec-driven development workflow yahaan naturally fit hota hai: ek single agent subagents ke saath spec likhta hai, phir spec multi-agent fleet ke liye tasks mein decompose hoti hai.

Breakdown ko visualize karna

Jab aapke paas paanch ya das structured tasks hain jinke beech dependencies hain, terminal mein progress track karna mushkil ho jaata hai. bd list aapko flat list dikhata hai. Yeh nahi dikhata ki kaun se tasks blocked hain, kaun se shuru hone ko ready hain, ya epic kitna aage badha hai.

Yeh woh problem hai jo Beadbox solve karta hai. Yeh same beads database padhta hai aur epic trees render karta hai progress indicators, dependency relationships, aur agent assignments ke saath. Aap dekhte hain kaun se subtasks done hain, kaun se prerequisites par blocked hain, aur kaun se ek agent ke pick up ke liye ready hain. --deps se specify kiya hua dependency graph aapke parallel kaam ka visual map ban jaata hai.

Jab ek agent task finish karta hai aur status update karta hai, Beadbox change real time mein reflect karta hai. Koi refresh nahi, koi bd list dobara chalane ki zaroorat nahi. Tree update hota hai, progress bar move hota hai, aur blocked tasks unblock ho jaate hain jaise jaise unki dependencies resolve hoti hain.

Same data. Bas visible.

Agar aap aise workflows bana rahe hain, to Beadbox ko GitHub par star karein.

Claude Code Subagents vs Structured Task Breakdown: kab kya use karein