Task Orchestration

Beyond Single Questions

Most Claude Code users ask one-off questions. That’s fine for quick help. But for serious development, you want to orchestrate entire workflows.

This means directing Claude through multi-step tasks—breaking down complex work, sequencing it logically, and iterating until it’s right.

The Orchestration Mindset

Think of yourself as a tech lead directing a capable developer.

Bad tech lead: “Build the feature.” Good tech lead: “Let’s break this down. First, outline the approach. Then we’ll implement the data layer. Then the API. Then tests.”

Same with Claude. Vague big asks get vague big outputs. Structured direction gets quality results.

Task Decomposition

Any complex task can be broken into pieces:

Original task: “Add user authentication to the app”

Decomposed:

Design the auth flow (what happens where)
Create the user model and database schema
Implement login/logout endpoints
Add password hashing
Create session management
Add protected route middleware
Write tests

Each piece is concrete. Each piece has a clear “done” state.

The Orchestration Loop

┌─────────────────────────────────────┐
│  1. Define the task clearly         │
│     What's the goal? What's done?   │
└───────────────┬─────────────────────┘
                │
                ▼
┌─────────────────────────────────────┐
│  2. Provide context                 │
│     Add relevant files and info     │
└───────────────┬─────────────────────┘
                │
                ▼
┌─────────────────────────────────────┐
│  3. Request the work                │
│     Specific, actionable ask        │
└───────────────┬─────────────────────┘
                │
                ▼
┌─────────────────────────────────────┐
│  4. Review the output               │
│     Does it meet the goal?          │
└───────────────┬─────────────────────┘
                │
        ┌───────┴───────┐
        │               │
        ▼               ▼
┌───────────────┐ ┌───────────────────┐
│   Good?       │ │   Needs work?     │
│   → Next task │ │   → Give feedback │
│               │ │   → Iterate       │
└───────────────┘ └───────────────────┘

Practical Orchestration Patterns

Pattern: Plan Before Build

Don’t jump straight to implementation.

> I need to add a caching layer to the API responses.
> First, outline the approach. Consider:
> - What should be cached
> - Cache invalidation strategy
> - Redis vs in-memory
> Don't write code yet—just the plan.

Review the plan. Discuss alternatives. Then:

> Good plan. Let's implement option 2 with Redis.
> Start with the cache utility functions.

Pattern: Incremental Implementation

Build in layers, verifying each one.

# Step 1
> Create the data models for the shopping cart.
> Just the models, no API yet.

# Review, then...

# Step 2
> Now add the cart service with add, remove, and clear operations.
> Use the models we just created.

**Quick check:** Before moving on, can you recall the key concept we just covered? Try to explain it in your own words before continuing.


# Review, then...

# Step 3
> Now create the API endpoints that use the cart service.

# Review, then...

# Step 4
> Add tests for the cart service.

Each step builds on the last. You catch issues early.

Pattern: Refine Through Iteration

Claude’s first output is rarely perfect. That’s fine.

> Create a function to parse CSV files with these columns: name, email, created_at

# Output is close but not quite right

> Good start, but:
> - Handle empty cells by returning null instead of empty string
> - Add validation that email format is correct
> - The date parsing should handle both ISO and US formats

# Iterate until right

Specific feedback is faster than re-explaining the whole task.

Pattern: Parallel Planning

For large features, plan the full scope first.

> We need to build a notification system. Before coding, outline:
> 1. What components are needed
> 2. How they interact
> 3. What order to build them
> 4. What external services are involved

Get the full picture. Then execute pieces systematically.

Conversation Continuity

Claude remembers your session. Use this.

Good:

> Now add error handling to the function we just created.

Claude knows which function.

Unnecessary:

> Now add error handling to the parseCSV function
> that takes a file path and returns an array of objects
> with name, email, and created_at fields that we created earlier.

Don’t re-explain what’s already in context.

When Tasks Go Wrong

Claude goes off-track

> Stop. That's not what I asked for.
> I need X, not Y.
> Specifically: [clear restatement]

Be direct. Redirect clearly.

Claude gets stuck

> Let's step back. What's confusing about this task?
> What information would help?

Sometimes Claude needs guidance on what’s missing.

Output is partially right

> The first part is correct. Keep that.
> Change only the validation logic: [specific fix]

Don’t throw out good work. Point to exactly what needs changing.

Task Complexity Calibration

Complexity	Approach
Trivial	One request, done
Simple	Request + one iteration
Moderate	Plan → implement → refine
Complex	Decompose → plan each → implement incrementally
Very complex	Multiple sessions, chunked context

Match your orchestration effort to task complexity.

Exercise: Orchestrate a Feature

Practice orchestrating this task:

Goal: Add a “recently viewed items” feature to an e-commerce site.

Break it down:

What’s the data model?
Where is the data stored (cookie, localStorage, database)?
What API endpoints are needed?
What UI components?
What’s the order of implementation?

Write out the sequence of Claude Code prompts you’d use.

Key Takeaways

Break complex tasks into clear, verifiable steps
Plan before implementing for anything non-trivial
Iterate with specific feedback rather than restarting
Use conversation continuity—Claude remembers context
Match orchestration effort to task complexity

Next: file operations. How to work with files safely and efficiently.

Up next: In the next lesson, we’ll dive into File Operations.