Shrutam CCA-F Crash › Domain 1 › d1-l08-task-decomposition English Hinglish →

Task Decomposition — When to Split, When to Merge

Domain 1 · 27% ~12 min English narration

Scenario anchor

Aaranya IT ke ek BFSI client ke liye 800-service legacy modernization chal rahi hai — aur aapka Claude-based orchestrator ek single prompt mein poora payment-reconciliation pipeline run karne ki koshish kar raha hai. Result? Context window overflow, partial tool calls, aur downstream agents ko incomplete state mil rahi hai. Is lesson mein hum dekhenge ki task decomposition ka wahi principle jo aapne SOA se microservices transition mein apply kiya tha — bounded context, single responsibility — wahi Claude agentic systems mein kaise map hota hai: kab split karo, kab merge karo, aur boundary kahan draw karni chahiye.

Key Takeaways

Decompose tasks at natural idempotency boundaries — the same boundary where you would define a saga compensation step or a distributed transaction checkpoint in a microservices architecture.
A subagent should own exactly one coherent capability contract: if its output JSON schema cannot be defined without referencing another agent's internal state, the boundary is drawn incorrectly.
Context-window budgeting is a first-class architectural constraint — treat it the way you treat heap allocation in a JVM service: measure before you split, not after you hit the limit.
Memory anchor under exam pressure: task decomposition in agentic systems == microservices decomposition boundary — split on bounded context, merge on shared transactional state.

← Previous lesson Same lesson in Hinglish Next lesson → Back to overview