Home › Study guides › CCDV-F › Domain 1 › Lesson 1.1

CCDV-F · Domain 1 · 14.7% of the exam · Lesson 1.1 · 22 min read

Workflows, agents and supervisors: choosing the architecture

When a task needs a workflow and when an agent, the five workflow patterns, how supervisor hierarchies work, and what subagents buy and what they cost.

Written against skill 1.1 of the official CCDV-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.1.1 Does every support message need an agent?

Two messages land in a travel company's support chat a minute apart. The first asks: "Can I take a 10 kg cabin bag on a Light fare?" The second says: "Our Frankfurt to Lisbon connection was just cancelled. I'm at the airport with two kids, and our Lisbon hotel starts tonight." Rafaela, the tech lead, has been asked to put Claude in this channel. Joaquin, who runs support operations, tells her the first kind is most of the traffic, while the second is rarer and far more expensive to get wrong.

The baggage question is easy for a model, as long as your code puts the right paragraph of the policy into its context, the text the model sees with the request. One call, one answer. The cancelled connection is different. Someone has to read the booking, search later flights, ask whether the hotel can start a night later and check the fare rules. Which steps are needed, and in what order, depends on what each one turns up. If the evening flight has four free seats, the hotel question vanishes; if not, a new one appears: where does the family sleep tonight?

So Rafaela's first decision is not which prompt or model to use. It is how much control to hand the model, and that choice has four rungs. A single call answers from what you give it. A workflow runs the model through steps your code fixed in advance. An agent lets the model choose its next step in a loop. On each turn it can ask your code to run a tool, a function you expose such as a flight search, then read the result and decide again. A supervisor with subagents is an agent that hands pieces of the job to other agents.

Each rung up buys flexibility and costs more tokens (the chunks of text the API reads, writes and bills you for), more time and some predictability.

1.1.2 Workflow or agent: who decides the next step?

The exam guide names this decision outright: when to use a workflow and when an agent. The trap is that a workflow can call tools and run several steps; so can an agent. What separates them is not the tools, the model or the number of calls. It is WHO decides the path.

Anthropic's guide to building agents draws the line precisely. In a workflow, the model and tools run through code paths you defined in advance. In an agent, the model directs its own process and tool use: it picks the next tool, sees the result and decides again, until it judges the job done. Anthropic calls both agentic systems, but only the agent hands over the steering wheel.

Think of a train and a taxi. A train runs on tracks laid in advance, so its route, timetable and fare are known before it leaves, but it cannot reach an address with no track. A taxi reaches any address and reroutes around a closed road, but the meter runs and you must trust the driver's judgment. A workflow is the train; an agent is the taxi.

In the support channel, the baggage question is a train journey: classify the message, fetch the matching policy section, answer from it, the same two calls every time. The cancelled connection is a taxi ride. The model reads the booking, asks for search_flights, finds no flight with four free seats before tomorrow, decides to look for an airport hotel, then checks the fare rules. Nobody scripted that sequence, and the next disruption will need a different one. Your code still runs every tool and decides when the loop stops.

1.1.3 The decision criteria: when to let the model steer

It is tempting to make everything an agent, because agents feel more capable. Resist it. Anthropic's advice is to find the simplest solution that works and add complexity only when it demonstrably improves results. Often that is no agentic system at all, just one well-prompted call with the right documents and a few examples. Agentic systems trade latency and cost for better performance, a trade worth making only when the task needs it.

Five questions decide where each kind of work belongs.

Memorise the five criteria and which way each one points. They rarely all agree, so weigh the ones the requirement stresses.

Error tolerance cuts both ways. An agent can recover from a failed step, because it sees each tool result and can try something else. But its errors also compound: read the wrong booking reference on turn one, and every later search builds on it. Anthropic recommends extensive testing in sandboxed environments with guardrails, and a stopping condition, such as a maximum number of turns, keeps a confused agent from running forever.

Run the travel company's work through the table and it sorts itself. Baggage questions are predictable, narrow and high-volume, and must match the published policy, so they get a workflow: classify, retrieve, answer. Disruptions are open-ended, and a stranded family will wait a minute for a good rebooking, so they get an agent with a turn cap and a handoff to a human. The one step Joaquin will not leave to judgment, changing a paid booking, gets a check in code. Many real systems look like this: a workflow at the front door, and an agent behind one of its doors.

1.1.4 Five workflow patterns to know by name

A workflow is not one shape. Anthropic's guide to building agents describes five patterns it keeps seeing in production. Learn each by name and purpose, because a scenario can describe one without ever naming it.

Memorise the names and the middle column; the last column only helps you spot a pattern.

Routing is the pattern Rafaela puts at the front door, as one small call to the Messages API. Look at the two commented lines at the bottom: the model only returns a label, and a dictionary in your code decides what happens next. An unexpected label falls through to a human, not to a guess.

HANDLERS = {
    "baggage": answer_from_policy,       # one call with the right policy section
    "disruption": run_rebooking_agent,   # the open-ended branch
}

def handle(message: str) -> str:
    reply = client.messages.create(
        model=SMALL_MODEL, max_tokens=10,
        system="Classify the customer message. Answer with one word: baggage, disruption or other.",
        messages=[{"role": "user", "content": message}],
    )
    label = reply.content[0].text.strip().lower()   # the model only LABELS
    handler = HANDLERS.get(label, hand_to_human)     # YOUR code picks the path
    return handler(message)

Two of the patterns are easy to confuse. Parallelisation and orchestrator-workers both split work and combine the results, but in parallelisation your code fixes the subtasks, while in orchestrator-workers a model picks them for each input. Anthropic still lists orchestrator-workers among the workflows: your code fixes its shape (split, delegate, combine), even though a model fills in the pieces. Turn the orchestrator and its workers into full agents, with their own tools and loops, and you have a supervisor hierarchy.

1.1.5 Supervisor hierarchies: one agent in charge

Now the hard case. Suppose the family from the opener is on a two-week tour, and the cancellation knocks on to three flights and a Lisbon hotel booking. One agent could do it, but its context would fill with hundreds of fares it never looks at again, and each search would wait for the last. This is where a manager/supervisor hierarchy helps. One supervisor agent (also called a manager, lead agent or orchestrator) owns the request, and subagents, separate agents it starts, each own one piece.

The structure has four moves:

1. PLAN. The supervisor reads the request and decides which pieces of work it needs, scaling the effort to the request. A simple case may need no subagents at all.
2. DELEGATE. It starts a subagent for each piece, with a complete brief: the objective, the output format, which tools and sources to use, and where the task ends.
3. WORK. Each subagent works in its own context, with its own tools, and returns a short result.
4. COMBINE. The supervisor merges the results, decides whether more work is needed, and owns the final answer and any action that cannot be undone.

Picture a general contractor renovating a house. The homeowner deals only with the contractor, who hires an electrician and a plumber, each with a job ticket, and each reports back to the contractor, not to the other. The electrician never decides to move a wall. Communication runs through the hub, and decisions that shape the whole job stay there.

For the family, the supervisor talks to the customer and holds the plan. A flights subagent with only search_flights returns the three best options. A hotel subagent with only search_hotels reports what can move, and a fare-rules subagent with only check_fare_rules reports what is refundable. None can book anything; the supervisor calls rebook_trip itself once the family agrees.

The brief matters because a subagent knows only what it is told. In the Claude Agent SDK, for example, a subagent starts with a fresh context by default, and the only thing its parent passes in is the task prompt. In Anthropic's multi-agent research system, early one-line briefs made subagents duplicate each other's searches or leave gaps. So the flights brief names the legs, the four travellers, what counts as a match and the three-line format to return.

Keep the hierarchy shallow: every layer adds a handoff where detail can get lost, so start with one supervisor over one layer of subagents, the shape Anthropic's research system uses. And split along context lines, not job titles. A planner, a booker and a messenger for the same rebooking would pass the same details back and forth like a game of telephone. Independent searches whose raw output the supervisor never needs are the natural boundary.

1.1.6 What subagents buy, and what they cost

The tempting belief is that more agents make a smarter system. Anthropic's advice runs the other way: start with a single agent and add subagents only in three situations; outside them, coordination usually costs more than it returns.

• PARALLELISM. Independent subtasks run at the same time, so together they take about as long as the slowest one, not the sum. Several subagents can also cover more ground than one agent could fit in its context.
• CONTEXT ISOLATION. Each subagent searches in its own context, and only its final message returns to the parent. Two hundred lines of fares stay in the flights subagent; the supervisor reads three.
• SPECIALISATION. Each subagent gets a focused prompt, a narrow tool set and, where it fits, a cheaper model. A subagent that can only search cannot book by mistake.

Here is the fan-out in miniature. To keep it short, your code fixes the two pieces, and each subagent is one call on data your code already fetched. In a real hierarchy, the supervisor chooses the pieces and each subagent runs its own tool loop. Look at asyncio.gather, which starts both searches at once, and at the return in worker, the only thing that leaves a subagent.

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def worker(brief: str, raw_data: str) -> str:
    reply = await client.messages.create(
        model=WORKER_MODEL, max_tokens=300,
        system="Do only the task in the brief. Reply in at most three lines.",
        messages=[{"role": "user", "content": f"{brief}\n\n<data>\n{raw_data}\n</data>"}],
    )
    return reply.content[0].text                # only this short answer leaves the subagent

async def gather_options(trip) -> str:
    flights, hotel = await asyncio.gather(      # independent searches run at the same time
        worker("List the 3 earliest Frankfurt-Lisbon flights today with 4 free seats.", trip.fares),
        worker("Can the Lisbon hotel start one night later, and at what cost?", trip.hotel),
    )
    return f"Flights:\n{flights}\n\nHotel:\n{hotel}"  # the supervisor reads about six lines

Now the bill. Each subagent needs its own context, agents exchange coordination messages, and results are summarised at every handoff. In Anthropic's testing, multi-agent systems typically used 3 to 10 times more tokens than a single agent on the same task. They often took longer overall too, despite the parallel work, because there was so much more work in total. Each handoff can also drop a detail, and every extra agent is another prompt to maintain and another place to fail.

So Rafaela's team does the sum per case. The ordinary one-leg disruption stays with a single agent, because its searches are small. The multi-leg family case gets the supervisor: its searches are independent, each returns far more than the supervisor needs, and a stranded family is worth the tokens. Baggage questions never come near an agent.

1.1.7 The exam traps

Most of these traps put work on the wrong rung of the ladder; the rest build the right rung badly.

• ✗ Building an agent for work whose steps you can write down. ✓ Use a workflow, or a single call: cheaper, faster and consistent. Autonomy buys nothing when the path never changes.
• ✗ Forcing an open-ended task into a fixed pipeline, then adding a branch each time it fails. ✓ Let an agent choose the next step, bounded by a turn cap, a budget and checks in code on risky actions. A bigger decision tree still breaks on the next surprise.
• ✗ Adding subagents because more agents sounds smarter. ✓ Add them for the parallelism, context isolation or specialisation the task actually needs; they multiply token use several times.
• ✗ Splitting one piece of work by job title: planner, doer, reviewer. ✓ Split along context boundaries, such as independent searches. Role splits pass the same details back and forth and lose some at each handoff. A checker that needs only the finished output and clear criteria is the exception that works.
• ✗ Delegating with a one-line instruction. ✓ Give each subagent an objective, an output format, its tools and sources, and clear boundaries. Vague briefs produce duplicated work and gaps.
• ✗ Giving every agent in the hierarchy the power to act. ✓ Keep subagents' tools narrow, and irreversible actions with the supervisor behind a check in code.

1.1.8 Put it together: design the support channel, then overbuild it

You now have every piece, from the ladder of autonomy to the price of a subagent. To feel the trade-offs, build a small support channel, then deliberately put easy traffic on the expensive path and watch the bill.

The rest of Domain 1 builds what you have just chosen. Agent construction (1.2) covers the Claude Agent SDK, custom loops, hosting, and hooks that turn "never rebook without approval" into code. Agent patterns and frameworks (1.3) covers tool-use loops, subagents, memory and context-window management, and frameworks such as LangGraph. Context engineering (6.1) goes deeper into keeping each agent's context lean.

Key takeaways

• ✓ Architecture is a choice of how much control to hand the model: a single call, a workflow, an agent, or a supervisor with subagents.
• ✓ In a workflow your code decides the path; in an agent the model decides each next step, and your code executes it and sets the limits.
• ✓ Choose by predictability, open-endedness, cost, latency and error tolerance; many applications put a workflow at the front door and an agent behind it.
• ✓ The five workflow patterns are prompt chaining, routing, parallelisation, orchestrator-workers and evaluator-optimizer, each for a different problem.
• ✓ A supervisor owns the request, delegates each piece with a precise brief, combines short results and keeps irreversible actions; keep it shallow and split by context, not by role.
• ✓ Subagents buy parallelism, context isolation and specialisation at typically several times the tokens, so add them only when one of those benefits is real.

Check your understanding

4 questions written for this lesson, then one from the CCDV-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Building effective agents
• How we built our multi-agent research system
• When to use multi-agent systems (and when not to)
• Subagents in the SDK
• Create custom subagents
• Python SDK
• The CCDV-F exam guide, summarised