/
← L1: Modular Architecture & The Agent SDK L3: Multi-Agent Orchestration →
Module 3 — Designing Scalable Agentic Architecture

L2: Task Decomposition and Chaining

L2: Task Decomposition and Chaining

In the previous lessons, we discussed the overarching Hub-and-Spoke architecture and how to distribute tools. However, the core mechanism that makes multi-agent workflows function is how you handle the prompt itself. This lesson covers Task Decomposition and Prompt Chaining —the architectural practices of breaking down massive goals into deterministic, sequential steps.

1. The Cognitive Limits of "Mega-Prompts"

When developers first transition to generative AI, they often attempt to solve complex problems with a single, massive prompt (the "Mega-Prompt").

Example of a Mega-Prompt: > "Read these 50 Jira tickets, figure out which ones are bugs, write the Python code to fix them, generate the unit tests, and output a markdown summary for the release notes."

The Architectural Failure:

Even with Claude 3.5 Sonnet's extended reasoning capabilities, Mega-Prompts introduce critical points of failure:

  • Attention Dilution: The model loses track of early constraints while trying to format the final output.

  • Context Pollution: The generation of unit tests gets confused by the context of unrelated Jira tickets.

  • Zero Error Recovery: If the model misunderstands one bug in step 2, the code, tests, and release notes for that bug will all be hopelessly hallucinated, and the entire API call is wasted.

2. Task Decomposition (The "Divide and Conquer" Strategy)

Task Decomposition is the programmatic process of taking a massive objective and splitting it into strictly scoped sub-tasks. Instead of one massive prompt, you architect a pipeline.

If the goal is to refactor a legacy module, an architect decomposes the task as follows:

  1. Analysis Task: "Map the current architecture and identify deprecated functions."

  2. Design Task: "Draft a new interface schema based on the analysis."

  3. Implementation Task: "Write the backend code matching the new schema."

  4. Verification Task: "Generate tests for the new backend code."

Architectural Advantage: Each step is handled by a separate, isolated API call to Claude. The model has exactly one goal per call, maximizing its reasoning accuracy and adherence to instructions.

3. Prompt Chaining Architectures

Once a task is decomposed, the sub-tasks must be linked together. Chaining is the programmatic passing of the output from one LLM call directly into the input of the next LLM call.

Architects utilize three primary chaining patterns:

  • Linear (Sequential) Chaining: The most common pattern. The output of Step A is required to begin Step B. (e.g., You cannot write the unit tests until the implementation code is generated).

  • Parallel (Fan-Out / Fan-In) Chaining: Used for speed and scale. If you have a BRD and need to write frontend and backend code, you "Fan-Out" the BRD to two separate Claude instances simultaneously. Once both finish, you "Fan-In" their outputs to a single Reviewer Agent to ensure the frontend API calls match the backend schema.

  • Conditional (Routing) Chaining: Step A acts purely as a classifier. "Analyze this error log. If it is a database error, route to the SQL Agent chain. If it is a network error, route to the DevOps Agent chain."

4. Designing Contracts Between Chain Links

The most fragile point in a chained architecture is the handoff between two LLM calls. If Agent A outputs a conversational paragraph, and Agent B's prompt expects a list of file paths, the chain breaks.

Architectural Enforcement:

You must enforce strict "contracts" between links in your chain using structured output (as discussed in earlier modules).

  • Step A's Output Schema: Must be forced to return strict JSON (e.g., {"deprecated_functions": ["auth()", "login()"]}).

  • Step B's Input Prompt: Your application code parses Step A's JSON and dynamically injects it into Step B's prompt: "You are tasked with refactoring the following functions:[INJECTED_ARRAY]."

By using Tool Use to force JSON outputs at every intermediate step, you ensure programmatic stability across the entire chain.

5. Error Isolation and the "Checkpoint" Pattern

The primary benefit of task decomposition is Error Isolation. In a Mega-Prompt, a failure at step 1 ruins step 5. In a Chained workflow, you can insert programatic validation between every link.

The Checkpoint Pattern:

Between Step B (Write Code) and Step C (Deploy), you insert a programmatic checkpoint. Your application runs a linter or a unit test against the output of Step B.

  • If it passes, the chain continues to Step C.

  • If it fails, the chain does not proceed. Instead, the application triggers a Validation-Retry loop entirely isolated to Step B, forcing Claude to fix the syntax error.

  • Once fixed, the chain resumes. This guarantees that downstream agents only ever receive validated, high-quality inputs.