Agent Teams Exercises: Business Problem-Solving with Multi-Agent Teams

In Lesson 20, you learned to create agent teams with TeamCreate, coordinate tasks with dependencies using TaskCreate and blockedBy, communicate between agents with SendMessage, and set up quality gates with delegate mode and plan approval. Now you will apply those capabilities to real business problems across four professional domains -- knowledge work, corporate operations, entrepreneurship, and freelance consulting.

These exercises are organized into 5 modules with 11 exercises total. Modules 1 through 4 each contain two exercises: an Exercise A (hands-on) where you build a working multi-agent team to solve a business problem, and an Exercise B (design) where you architect team structures and workflows on paper. Module 5 contains three capstones that combine everything. The design exercises require zero API calls -- they build the strategic thinking skills that make your hands-on work more effective and cost-efficient.

Every exercise uses realistic business data. You will analyze market research, plan corporate events, debate feature priorities with survey data, draft client proposals against RFPs, and assemble business plans. These are problems that professionals solve daily -- agent teams make them faster and more thorough.

Experimental Feature

Agent Teams requires an environment variable to enable:

Set this before starting any exercise. Without it, team-related tools (TeamCreate, SendMessage, etc.) will not be available.

Download Exercise Files

Download Agent Teams Exercises (ZIP)

After downloading, unzip the file. Each exercise has its own folder with an INSTRUCTIONS.md and any starter files you need.

If the download link doesn't work, visit the repository releases page directly.

API Costs

Hands-on exercises (A-type) run multiple Claude instances simultaneously, so they cost more than single-agent sessions. Design exercises (B-type) are completely free -- they require no API calls at all.

Budget-friendly path: Complete all four design exercises first (1.2, 2.2, 3.2, 4.2), then add hands-on exercises starting with 1.1. See the exercise guide inside the ZIP for detailed cost estimates.

---

How to Use These Exercises

Start the exercises after finishing Lesson 20:

The workflow for every exercise:

1. Open the exercise folder from the claude-code-agent-teams-exercises/ directory
2. Read the INSTRUCTIONS.md inside the folder -- it has setup steps and starter files
3. Read the walkthrough below for context on what you are practicing and why
4. Start Claude Code and point it at the exercise folder
5. Work through the exercise -- write your own prompts, do not just copy the starter
6. Score your results using the assessment rubric at the bottom of this lesson

---

Tool Guide

• Claude Code -- Terminal-based, required for all hands-on agent team exercises. Agent teams operate through the terminal using TeamCreate, TaskCreate, TaskUpdate, SendMessage, and related tools.

Agent teams are a terminal-only feature. Cowork does not support multi-agent team orchestration.

---

Module 1: Your First Team (Knowledge Work)

Core Skill: Creating teams, spawning teammates, and assigning tasks with dependencies

1.1Market Research Sprint

Exercise 1.1 -- Market Research Sprint (Hands-on)

The Problem: Open the module-1-your-first-team/exercise-1.1-market-research-sprint/ folder. Your VP wants a market analysis of the premium pet food delivery space. You have a CSV with 50 rows of market data, three competitor profiles, and an analysis brief specifying three angles: market sizing, competitive landscape, and entry strategy.

What You'll Build: A 3-agent research team where a market analyst works the data, a competitive intelligence agent reads the competitor profiles, and a strategy advisor synthesizes both analyses into a go/no-go recommendation. The strategy advisor's task is blocked by the other two -- it cannot start until both analyses are complete.

What You'll Learn:

• How TeamCreate initializes a team and spawns specialized agents
• How blockedBy dependencies enforce sequencing -- the synthesizer waits for the analysts
• That dividing research angles across agents produces more thorough coverage than a single prompt

Starter Prompt:

"Create a team to analyze this market opportunity with 3 research agents."

Better Prompt (Build Toward This): "Create a team called 'market-research' using TeamCreate. Spawn 3 teammates: 'market-analyst' to analyze market-data.csv for segment sizes, growth rates, and trends; 'competitive-intel' to read all three competitor profiles and map strengths and weaknesses; 'strategy-advisor' to synthesize both analyses into entry recommendations. Create tasks for each with clear deliverables. The strategy-advisor task should be blockedBy both the market-analyst and competitive-intel tasks."

Reflection Questions:

1. How did the strategy advisor's output differ from what a single agent would produce with all the same files? Was the team version more thorough?
2. Did the blockedBy dependency actually matter -- did the strategy advisor reference specific findings from the other two agents?
3. If you could add a 4th agent, what angle would it cover?

---

1.2Team Architecture Workshop

Exercise 1.2 -- Team Architecture Workshop (Design)

The Problem: Open the module-1-your-first-team/exercise-1.2-team-architecture-workshop/ folder. You have five different business scenarios -- each needs a multi-agent team, but they have very different requirements for team size, task structure, and communication patterns.

What You'll Design: For each of the five scenarios, sketch the team: how many agents, what each one does, which tasks depend on which, and what information flows between them. No API calls needed -- this is strategic thinking about when and how to decompose problems into parallel agent work.

What You'll Learn:

• Not every problem benefits from a team -- some are better solved by a single agent
• Team structure follows problem structure: parallel analysis needs parallel agents, sequential processes need pipeline dependencies
• Designing the team before creating it prevents wasted API tokens on poorly structured workflows

Reflection Questions:

1. Which of the five scenarios benefits most from a multi-agent approach? Which benefits least?
2. For the scenarios where you chose more than 3 agents, could you achieve the same result with fewer? What is the tradeoff?
3. What patterns do you notice across your five designs -- are there common team shapes?

---

Module 2: Task Pipelines (Corporate)

Core Skill: Creating task pipelines with blockedBy dependencies and managing sequential workflows

2.1Event Planning Pipeline

Exercise 2.1 -- Event Planning Pipeline (Hands-on)

The Problem: Open the module-2-task-pipelines/exercise-2.1-event-planning-pipeline/ folder. You are planning a 200-person corporate event. You have an event requirements document, a budget CSV, a venue options CSV with 12 venues, and a guest list CSV with 80 confirmed attendees. The planning has strict ordering: budget analysis must happen first, then venue selection (constrained by budget), then logistics (constrained by venue), then communications (constrained by all prior decisions).

What You'll Build: A 4-stage pipeline where each task is blocked by the previous one. Budget analyst determines what you can afford. Venue selector picks the best venue within budget. Logistics coordinator plans catering, AV, and transportation for the chosen venue. Communications agent drafts attendee invitations with all the confirmed details.

What You'll Learn:

• How addBlockedBy creates sequential dependencies between tasks
• That blocked tasks cannot proceed until their dependencies resolve -- this prevents out-of-order execution
• The difference between tasks that must be sequential (venue depends on budget) and tasks that could run in parallel

Starter Prompt:

"Create a pipeline for planning this corporate event with 4 stages."

Better Prompt (Build Toward This): "Create a team called 'event-planning' with 4 agents: 'budget-analyst' to analyze the budget CSV and determine spending limits per category; 'venue-selector' to evaluate all 12 venues against budget constraints and event requirements; 'logistics-coordinator' to plan catering, AV, and transportation for the selected venue and guest count; 'comms-agent' to draft attendee invitations with confirmed venue, date, and logistics details. Set dependencies: venue-selector blockedBy budget-analyst, logistics-coordinator blockedBy venue-selector, comms-agent blockedBy logistics-coordinator."

Reflection Questions:

1. What happened when the venue selector tried to work before the budget analyst finished? Did the blockedBy dependency prevent premature decisions?
2. Could any of these four stages run in parallel instead of sequentially? What would need to change?
3. If the budget analyst discovers the budget is insufficient for any venue, how should the pipeline handle this failure?

---

2.2Pipeline Blueprint

Exercise 2.2 -- Pipeline Blueprint (Design)

The Problem: Open the module-2-task-pipelines/exercise-2.2-pipeline-blueprint/ folder. You have three real business workflows that need dependency graphs: a product launch sequence, a quarterly financial close, and an employee onboarding process.

What You'll Design: For each workflow, map out every task, identify which tasks depend on which, and draw the dependency graph. Identify which tasks can run in parallel and which must be sequential. No API calls needed.

What You'll Learn:

• Real business workflows are rarely purely sequential -- most have parallel branches that converge at key milestones
• Drawing dependencies before creating tasks prevents circular dependencies and deadlocks
• The critical path (longest sequential chain) determines minimum pipeline duration

Reflection Questions:

1. For each workflow, what is the critical path -- the longest chain of sequential dependencies? How does it compare to running everything sequentially?
2. Did you find any tasks that seemed sequential at first but could actually run in parallel? What made you reconsider?
3. How would you handle a dependency that fails midway through -- does the whole pipeline stop or just the downstream branch?

---

Module 3: Communication (Entrepreneurship)

Core Skill: Using SendMessage for direct messages and understanding broadcast vs DM tradeoffs

3.1Feature Prioritization Debate

Exercise 3.1 -- Feature Prioritization Debate (Hands-on)

The Problem: Open the module-3-communication/exercise-3.1-feature-prioritization-debate/ folder. Your startup has three proposed features (Analytics Dashboard, Collaboration Suite, API Marketplace) and limited engineering bandwidth. You have 100 user survey responses, revenue projections by quarter, and engineering effort estimates. You need a data-driven prioritization, not a gut decision.

What You'll Build: A 4-agent debate team. Three advocate agents each champion one feature using real data from the CSV files. A decision-maker agent synthesizes all three arguments into a prioritized build order. Each advocate reads the survey data and revenue projections for their assigned feature and builds the strongest case they can.

What You'll Learn:

• How SendMessage enables structured information flow between agents
• That debate format (multiple agents arguing different positions) can produce better analysis than a single agent trying to be "balanced"
• When to use DMs (sharing findings with the decision-maker) vs broadcast (announcing results to all)

Starter Prompt:

"Create a team where 3 agents each argue for a different feature and a 4th decides the priority."

Better Prompt (Build Toward This): "Create a team called 'feature-debate' with 4 agents: 'advocate-analytics' champions Feature A using survey data and revenue projections; 'advocate-collaboration' champions Feature B with the same data sources; 'advocate-marketplace' champions Feature C; 'decision-maker' synthesizes all three arguments into a prioritized recommendation. Create tasks for each advocate, then a synthesis task for the decision-maker blockedBy all three advocate tasks. Each advocate should also read effort-estimates.csv to address feasibility. The decision-maker should weigh revenue potential, user demand, AND engineering effort."

Reflection Questions:

1. Did the advocates cherry-pick data that supported their feature? Is that useful or harmful for decision-making?
2. How did the decision-maker handle conflicting evidence -- for example, a feature with high revenue but low survey scores?
3. Compare this structured debate to asking one agent "analyze all three features and recommend a priority order." Which produced better reasoning?

---

3.2Communication Protocol Design

Exercise 3.2 -- Communication Protocol Design (Design)

The Problem: Open the module-3-communication/exercise-3.2-communication-protocol-design/ folder. You have five multi-agent scenarios that each require different communication patterns. Some need broadcast, some need targeted DMs, some need information to flow in one direction, and some need back-and-forth negotiation.

What You'll Design: For each scenario, specify the communication protocol: who sends messages to whom, when to use broadcast vs DM, what information each message contains, and in what order messages should flow. No API calls needed.

What You'll Learn:

• Broadcasting is expensive -- it interrupts every agent. Most messages should be DMs to specific recipients
• Communication direction matters: top-down (lead to teammates), bottom-up (findings to lead), or peer-to-peer (agents sharing with each other)
• Well-designed communication protocols reduce token waste and improve output quality

Reflection Questions:

1. For how many of the five scenarios did you choose broadcast over DM? What made broadcast necessary in those cases?
2. What happens when agents communicate too much -- constant status updates, unnecessary broadcasts? How does that affect costs and quality?
3. Design a "communication budget" rule: if each message costs X tokens, how many messages should a 3-agent team exchange for a 30-minute task?

---

Module 4: Quality Gates (Freelancer/Consultant)

Core Skill: Using delegate mode and plan approval to enforce quality standards

4.1Client Proposal Pipeline

Exercise 4.1 -- Client Proposal Pipeline (Hands-on)

The Problem: Open the module-4-quality-gates/exercise-4.1-client-proposal-pipeline/ folder. A client has sent you an RFP (Request for Proposal). You have your company capabilities document and two reference proposals from past wins. You need to draft a proposal, review it for quality, and get final approval before "submitting" it.

What You'll Build: A 3-agent pipeline with quality gates. A proposal writer operates in delegate mode -- it must present its plan (outline, key themes, pricing approach) and get approval before drafting. A quality reviewer checks the draft against every RFP requirement. An engagement lead makes the final submission decision.

What You'll Learn:

• How delegate mode (plan_mode_required) prevents agents from charging ahead without approval
• That review cycles improve output -- the quality reviewer catches gaps the writer missed
• The approval pattern: plan approval before work, quality review after work, final sign-off before delivery

Starter Prompt:

"Create a proposal team with a writer, reviewer, and approver."

Better Prompt (Build Toward This): "Create a team called 'proposal-team' with 3 agents: 'proposal-writer' in delegate mode (plan_mode_required) to draft the proposal matching RFP requirements using company capabilities and reference proposals; 'quality-reviewer' to check the draft for completeness against every RFP requirement, accuracy of capability claims, and persuasiveness; 'engagement-lead' to make the final submission decision. Create tasks: draft proposal (writer), review draft (reviewer, blockedBy writer), final approval (lead, blockedBy reviewer). The writer must present its plan and get approval before writing."

Reflection Questions:

1. Did the delegate mode approval step prevent any wasted effort? What would have happened if the writer started drafting without plan approval?
2. How many revision cycles did the proposal go through? Was each cycle productive or did you hit diminishing returns?
3. In a real consulting firm, this pipeline runs every week. How would you template this team for reuse across different RFPs?

---

4.2Review Workflow Design

Exercise 4.2 -- Review Workflow Design (Design)

The Problem: Open the module-4-quality-gates/exercise-4.2-review-workflow-design/ folder. You have three different deliverable types that each need review and approval pipelines: a technical blog post, a financial report, and a software architecture document.

What You'll Design: For each deliverable, design the complete review workflow: who creates, who reviews, who approves, what criteria each reviewer uses, and how revision requests flow back to the creator. No API calls needed.

What You'll Learn:

• Different deliverables need different review criteria -- technical accuracy for architecture docs, regulatory compliance for financial reports, readability for blog posts
• Quality gates add cost (more agents, more time) but reduce risk -- the tradeoff depends on the stakes of the deliverable
• The revision loop (create, review, revise, re-review) must have a termination condition or it runs forever

Reflection Questions:

1. Which deliverable type needed the most reviewers? Why -- what is at stake if a financial report has errors versus a blog post?
2. How did you design the termination condition for revision loops? After how many rounds should the team stop revising and ship?
3. Could you combine any reviewer roles -- for example, one agent checking both technical accuracy and readability? What are the tradeoffs?

---

Module 5: Capstones

Choose one or more. These combine team creation, task coordination, communication, and quality gates -- no starter prompts provided.

Capstones are different from the exercises above. There are no guided prompts -- you design the entire approach yourself. Each project requires integrating concepts from all four modules into a complete multi-agent workflow.

ABusiness Plan Assembly

Capstone A -- Business Plan Assembly

Open the module-5-capstones/capstone-A-business-plan-assembly/ folder. You have a business idea description, a market research CSV with 55 rows of data, and a cost estimates CSV. Assemble a complete business plan using 5 agents: market researcher, financial modeler, competitive analyst, operations planner, and an executive summarizer who synthesizes everything into a pitch-ready document. Design the task dependencies, communication flows, and at least one quality gate.

What You'll Learn:

• How to decompose a complex deliverable (business plan) into parallel workstreams
• That the synthesizer agent benefits enormously from well-structured upstream outputs
• How quality gates at the end catch inconsistencies between sections (financial projections that contradict market sizing)

---

BCustomer Feedback Triage

Capstone B -- Customer Feedback Triage

Open the module-5-capstones/capstone-B-customer-feedback-triage/ folder. You have 200 customer reviews, a product catalog, and a team brief. Build a team that categorizes reviews by sentiment and topic, identifies the top 5 product issues, proposes fixes for each, and produces an executive action plan with priorities and owners.

What You'll Learn:

• How agent teams handle high-volume data (200 reviews) through division of labor
• That categorization agents and analysis agents have different strengths -- separating these roles produces better results
• How to design dependencies so the action plan reflects actual data patterns, not assumptions

---

CYour Business Challenge

Capstone C -- Your Business Challenge

Open the module-5-capstones/capstone-C-your-business-challenge/ folder for a self-assessment template and planning worksheet. Apply agent teams to a real challenge from your own work. Define the problem, design the team, identify what data or documents the agents need, and run the workflow. This capstone has no fixed structure -- the team design must match your specific problem.

What Makes This Special: The team structure you design here could become a reusable workflow you run weekly. Most professionals discover that even a 2-agent team saves significant time on tasks they were doing sequentially.

---

Assessment Rubric

After completing an exercise, evaluate your team's output on four criteria using a 1-5 scale:

Scoring targets:

• Module exercises (1.1 through 4.2): 14/20 -- solid understanding of the concept
• Capstones (A, B, C): 16/20 -- integration and mastery

Record your scores after each exercise. If you score below target, re-read the reflection questions for improvement ideas.