Aapne abhi ek doosra Claude Code agent start kiya. Ab aapke paas ek problem hai.

Pehla agent ek refactoring ke beech mein hai. Doosre ko ek feature banana hai jo kuch same files ko touch karta hai. Kisi ko nahi pata ki doosra exist karta hai. Aap ek saath router, state store, aur conflict resolver hain, aur aapka ek hi tool hai terminal windows ke beech context copy-paste karna.

Yahi woh jagah hai jahan zyaadatar developers Claude Code ke saath wall se takrate hain. Isliye nahi ki agent coding mein kharaab hai. Balki isliye ki koi system nahi hai jo use bataye ki kis par kaam karna hai.

Copy-paste problem

Zyaadatar Claude Code workflows ek hi tarah shuru hote hain. Aapke dimaag mein ek task hai (ya Jira mein, ya GitHub issue mein), aur aap description ko agent ke prompt mein paste karte hain. "Auth flow banao." "Pagination bug fix karo." "Dark mode support add karo."

Ek single agent ke liye, yeh theek kaam karta hai. Agent ke paas poora context hai, aap uski output dekh sakte hain, aur aapko pata hai kab khatam hua kyunki aap use dekh rahe hain.

Doosra agent add karo aur daraarein turant dikhti hain.

Agent A API layer refactor kar raha hai. Agent B naya endpoint bana raha hai. Dono server/routes.ts ko touch kar rahe hain. Kisi ko doosre ke changes ka pata nahi. Aap conflict tab discover karte hain jab ek push karta hai aur doosre ka kaam toot jaata hai. Ya isse bhi bura: dono locally succeed karte hain lekin merged result aisi tarah se toota hai jo koi bhi diff nahi dikhata.

Root cause yeh nahi ki agents laaparwaah hain. Yeh shared state ki absence hai. Koi jagah nahi jahan "Agent A API refactor ka maalik hai" record ho. Koi status nahi jo kahe "routes file modify ho rahi hai, apni baari ka intezaar karo." Agents individual prompts par operate kar rahe hain bina kisi awareness ke overall picture ki.

Teesra agent add karo aur aap coding se zyaada samay coordinating mein bitaate hain.

Agents ko task system se actually kya chahiye

Tool dhoondhne se pehle, yeh poochna zaroori hai: Claude Code agent ko accha kaam karne ke liye actually kya chahiye?

Hairaani ki baat hai, bahut kam.

Ek unique identifier. Kuch jo woh commits aur comments mein reference kar sake. "Bug fix kiya" multi-agent log mein bekar hai. "Complete PROJ-47: pagination filtered views par galat count return karta hai" traceable hai.

Ek clear scope. Title, description, aur acceptance criteria. Novel nahi. Personas ke saath user story nahi. "Done" kaisa dikhta hai iska concrete statement. "'/users' endpoint paginated results return karta hai. Page size default 25 hai. 'next_cursor' field last page par null hai."

Ek status jo update kar sake. Agent ko signal karna hoga ki woh kahan hai: claimed, in progress, done. Iske bina, aap wapas terminal windows mein jhaank kar guess kar rahe hain.

Dependency awareness. "Yeh tab tak shuru mat karo jab tak PROJ-46 merge na ho jaaye" sabse common multi-agent failure rokta hai: aise code par build karna jo abhi exist nahi karta.

Dhyaan dein is list mein kya nahi hai. Sprint planning. Velocity tracking. Kanban boards. Story points. Color-coded labels ke saath epics. Agents ko project management ka natak nahi chahiye. Unhe ek task chahiye, ek status, aur "main hogaya" kehne ka tarika.

CLAUDE.md contract

Task system agents ko batata hai kya karna hai. CLAUDE.md file unhe batati hai kaise karna hai.

Agar aap multiple Claude Code agents chala rahe hain, har ek ke paas ek CLAUDE.md hona chahiye jo uski identity aur boundaries define kare. Yeh optional configuration nahi hai. Yeh un agents ke beech ka farq hai jo coordinate karte hain aur jo ek doosre ke raaste mein aate hain.

Yahan ek simplified example hai ek engineering agent ke liye:

## Identity

Engineer for the project. You implement features, fix bugs,
and write tests. You own implementation quality.

## What You Own

- All files under `components/` and `lib/`
- Unit tests in `__tests__/`
- You may read but not modify files under `server/`

## What You Don't Own

- Deployment configuration (that's ops)
- Issue triage and prioritization (that's the coordinator)
- QA validation (QA tests your work independently)

## Completion Protocol

Before marking any task done:
1. Run the full test suite: `pnpm test`
2. Verify your change works manually
3. Comment what you did with the commit hash
4. Push before reporting completion

Boundary section load-bearing part hai. Bina explicit file ownership ke, agents bhatak jaate hain. Ek engineering agent "madad se" deployment config refactor kar deta hai. Ek QA agent test ko "fix" karta hai code under test ko badal kar test ki jagah. Explicit boundaries in failure modes ko rokti hain.

Completion protocol bhi utna hi important hai. Yeh sabse common agent failure rokta hai: kuch cheez ko done claim karna jabki woh sirf compile hoti hai. "Full test suite chalao" aur "manually verify karo" concrete gates hain. Is protocol ko follow karne wala agent aisa kaam produce karta hai jis par insaan bharosa kar sake. Iske bina agent aisa kaam produce karta hai jo aapko line by line check karna padta hai.

Ise multiple agents par scale karo aur aapko ek fleet milti hai jahan har member apni lane, apna handoff protocol, aur "done" ka matlab jaanta hai.

CLI-first task management

Yahan ek workflow observation hai jise internalize karne mein mujhe zaroorat se zyaada samay laga: Claude Code agents CLI tools ke saath dramatically behtar kaam karte hain GUI interfaces ki tulna mein.

Sochne par yeh samajh mein aata hai. Claude Code agent terminal mein rehta hai. Woh commands execute kar sakta hai, output padh sakta hai, aur results ke basis par action le sakta hai. Use web UI navigate karne, buttons click karne, aur rendered pages interpret karne ko kehna agent ke natural interface ke khilaf ladna hai.

CLI-based task system ka matlab hai ki agent yeh ek hi flow mein kar sakta hai:

# Read the task
task show PROJ-47

# Claim it
task update PROJ-47 --status in_progress --assignee agent-1

# Do the work...

# Report completion
task comment PROJ-47 "DONE: Fixed pagination. Commit: abc1234"
task update PROJ-47 --status done

Koi context switching nahi. Koi browser windows nahi. Kanban board ke screenshots nahi. Agent task padhta hai, kaam karta hai, aur status update karta hai, sab kuch bina us environment ko chhode jahan woh operate karta hai.

Output machine-readable bhi hai. Jab aapko check karna ho ki agents ke across kya ho raha hai, aap query kar sakte hain:

task list --status in_progress    # What's being worked on?
task list --assignee agent-2      # What is agent-2 doing?
task list --blocked               # What's stuck?

Yeh woh tooling ka shape hai jo kaam karta hai. Ek CLI jo agent ki bhaasha bolta hai.

Beads: agents ke liye local-first issue tracking

Jo workflow maine upar describe kiya woh hypothetical nahi hai. Yeh woh hai jo main har din beads ke saath use karta hoon, ek open-source, local-first issue tracker jo bilkul isi tarah ke agent-driven development ke liye bana hai.

beads issues (jinhe "beads" kehte hain) aapke codebase ke saath ek local Dolt database mein store karta hai. Har bead ke paas ek ID, title, description, status, priority, dependencies, aur ek comment thread hai. CLI ka naam bd hai, aur yeh woh interface hai jo agents tasks padhne, status update karne, aur structured comments chhodne ke liye use karte hain.

Yahan ek real workflow hai. Main ek task create karta hoon:

bd create --title "Fix pagination on filtered views" \
  --description "The /users endpoint returns wrong count when filters are applied. Page size defaults to 25. next_cursor should be null on the last page." \
  --priority p2

Ek agent ise claim karta hai:

bd update bb-r3k2 --claim --actor eng1
bd update bb-r3k2 --status in_progress

Koi bhi code likhne se pehle, agent apna plan comment karta hai:

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Fix count query in /users to apply filters before COUNT()
2. Add cursor boundary check for last page
3. Add test cases for filtered pagination

Files:
- server/routes/users.ts - fix count query
- server/routes/users.test.ts - add filtered pagination tests"

Yeh ek checkpoint hai. Agar plan galat hai, aap ise 30 second mein pakad lete hain 45 minute baad kharaab implementation discover karne ki jagah.

Agent kaam karta hai, tests chalata hai, phir completion comment karta hai:

bd comments add bb-r3k2 --author eng1 "DONE: Fixed filtered pagination count.

- COUNT() now applies the same WHERE clause as the data query
- next_cursor returns null when offset + page_size >= total_count
- Added 4 test cases covering filtered + unfiltered pagination

Commit: a1b2c3d"

bd update bb-r3k2 --status ready_for_qa

Task ke paas ab complete audit trail hai: kya request kiya gaya tha, agent ne kya plan kiya, usne actually kya kiya, aur review ke liye commit hash. QA chala raha doosra agent ise utha sakta hai aur independently verify kar sakta hai.

Yeh kaam karta hai kyunki beads wahi bhaasha bolta hai jo agents bolte hain. Sab kuch CLI command hai. Sab kuch structured output produce karta hai. Tool aur agent ke beech koi impedance mismatch nahi hai.

Bada picture dekhna

CLI workflow 3 ya 4 agents tak scale hota hai usse pehle ki aap naye ceiling par pahunchein. Tool ceiling nahi. Cognitive ceiling.

5 agents par, bd list chalana aur mentally project ki state assemble karna aise hai jaise spreadsheet padhna aur dependency graph dimaag mein rakhne ki koshish karna. Kaunse tasks blocked hain? Kis agent ne 20 minute se apna status update nahi kiya? Feature epic 60% done hai ya 80%? Information sab wahan hai CLI output mein, lekin use jodne mein mehnat lagti hai jo har additional agent ke saath badhti hai.

Yahan Beadbox fit hota hai. Yeh ek real-time dashboard hai jo beads ke upar baithta hai aur aapko aapki poori agent fleet ki state dikhata hai. Visually rendered dependency trees. Epic progress bars. Agent comment threads jo aap scan kar sakte hain bina paanch bd show commands chalaye.

Beadbox CLI ko replace nahi karta. Agents abhi bhi sab kuch ke liye bd use karte hain. Beadbox woh layer hai jo aap tab open karte hain jab aapko bada picture chahiye: kaunse workstreams chal rahe hain, kaunse stuck hain, aur bottlenecks kahan hain. Yeh beads database ko changes ke liye watch karta hai aur real time mein update hota hai, toh aap kabhi stale data nahi dekh rahe.

Yeh beta ke dauraan free hai aur poori tarah aapki machine par chalta hai. Koi accounts nahi, koi cloud nahi, aapka data local rehta hai.

Shuru kaise karein

Aapko structured task management se value paane ke liye 13 agents ki zaroorat nahi hai. Do Claude Code agents aur ek rule se shuru karein: har task ko ek bead milta hai, har agent code likhne se pehle apna plan comment karta hai, har completion mein verification steps hote hain.

Pattern compound hota hai. Ek baar agents ke paas shared task system ho, aap QA agents add kar sakte hain jo independently kaam verify karte hain. Aap coordinator add kar sakte hain jo priority queue se tasks dispatch karta hai. Aap 5, 10, 15 agents tak scale kar sakte hain bina coordination overhead linearly badhe, kyunki protocols woh handle karte hain jo pehle manual context-switching tha.

Tools:

beads local-first task management ke liye. Open source.
Claude Code agent runtime ke roop mein.
Beadbox visual oversight ke liye jab fleet badhe.

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

Claude Code Agents ke liye tasks kaise manage karein