Nova Assembles the Team

Part of the free Generative AI course on LogicWiz, module: Nova Builds a Team.

Episode 23: Nova Assembles the Team

"Priya asks Nova to 'plan a two-day trip to London.' That's not one job — it's find flights, book a hotel, research things to do, and stitch it all into a day-by-day plan. One agent would try to juggle all four and drop three. Nova needs a team — and a way to run it."

The Job Too Big for One Nova

Last episode, Nova learned when to build a team. Now she has to actually run one — and Priya's request is the perfect test: "plan a two-day trip to London."

Look at everything hiding inside that one sentence:

• find flights,
• book a hotel,
• research things to do,
• and weave it all into a clean day-by-day plan.

Hand that to a single agent and it tries to do all four at once in its head — and drops three. So we split the work across specialists. But "have a few agents" isn't a plan; you still have to decide how they hand work to each other. That "how" is the whole subject of this episode — and, good news, there are only a handful of reusable shapes to learn.

Two Ways to Run a Team: Workflows vs. Agents

Before the shapes, one distinction that clears up so much confusion. There are two fundamentally different ways to run a group of LLM calls:

A workflow is a recipe. You, the developer, write the exact steps in advance — first do this, then that, then this — and the LLM just fills in each step. The path never changes, like following a recipe card. Predictable, and easy to debug.

An agent is a cook. You hand it a goal and some tools, and it decides what to do next based on what's happened so far. The path isn't fixed — it figures things out as it goes, like a cook tasting and adjusting.

Neither is "better." A recipe is perfect when the steps are always the same; a cook shines when the job is unpredictable. Real systems mix both — and most of the shapes below are workflows (you wire the path) with an LLM doing the thinking at each step.

{{visual:agent-patterns}}

Five Ways to Wire a Team

Those five shapes in the gallery are the vocabulary of multi-agent design. Here's each one in plain English, with the everyday version you already understand:

• Prompt chaining — do it in steps, each feeding the next. An assembly line: draft → fact-check → polish. (Nova: turn a messy request into a clean search query, then search, then summarize.)
• Routing — sort the request and send it to exactly one specialist. A receptionist pointing you to the right desk. (Nova: a flight question goes to the Search agent; a "what should I do there?" goes to the Itinerary agent.)
• Parallelization — split the job into independent pieces and do them at the same time, then combine. A group project where everyone takes a section. (Nova: search flights AND research activities at once — neither waits for the other.)
• Orchestrator–worker — a manager breaks the job into pieces, hands them to workers, and merges the results. A head chef directing line cooks, then plating the dish. (Nova: a coordinator delegates flights and itinerary, then a synthesizer combines them.)
• Evaluator–optimizer — one agent makes a draft, another critiques it, and they loop until it's good. A writer and an editor. (Nova: draft an itinerary, a checker flags "Day 2 is empty," revise — you met this as the LLM-as-judge in Chapter VI.)

The first four are workflows — you wire the path. The fifth adds a refine loop. Nova's trip planner leans on three of these, so let's build them one at a time.

Routing: The Receptionist

Start with the simplest move: routing. A request comes in; you work out what kind of request it is; you send it down exactly one path. That's literally a receptionist — they read who you are, point you to the right desk, and do nothing else.

How does the router "read" the request? With one small LLM call whose only job is intent detection — name the goal of the query. Nova's planner looks at "plan a trip to London on these dates" and splits it: the logistics (flights, hotels) go to the Search Agent, and the open-ended parts (interests, what to do) go to the Itinerary Agent.

Two things make a router genuinely good:

• Few-shot examples sharpen it. Show the router a couple of examples right in its prompt — "'cheapest flight to Rome' → Search", "'best museums in Rome' → Itinerary" — and it gets far more reliable on the tricky in-between cases. Examples beat explanations.
• It quietly saves money. You can route a simple question to a small, cheap model and a hard one to a big, expensive model. You don't need a top-tier model to answer "what's your refund window?" — a lighter model costs a fraction of the tokens for the same answer. Since token cost is always a top concern, routing by difficulty is one of your sharpest savings levers.

💡 Route on what the task needs, not just on price. If the next step must use a specific tool, send it to the agent that owns that tool. Match capability to complexity — small model for small jobs, big model for hard reasoning.

Orchestrator, Workers, and a Synthesizer

Routing sends a request one way. But Priya's London trip needs several things at once — and that's the pattern you'll use most: orchestrator–worker.

Picture a head chef. An order comes in; the chef doesn't cook it alone. They break it into parts — someone on the grill, someone on the sauce — and when the parts are ready, the chef plates them into one dish. In Nova's world: an orchestrator plans the job and hands pieces to specialized workers, and a synthesizer combines their outputs into a single answer.

{{visual:orchestrator-worker}}

Two ideas do the heavy lifting there, and both are worth pausing on:

• Parallelization — the workers run at the same time. Finding flights and researching museums don't depend on each other, so there's no reason to do them one after the other. Run them together and the whole job finishes in the time of the slowest piece, not the sum of all of them. That's what people mean when they call a multi-agent system "faster" — not that any single step is quicker, but that many things happen at once. (Ten people clearing a warehouse beat one person, even if nobody moves any faster.)
• Synthesis — you can't just staple the outputs together. Worker 1 hands back flight options; worker 2 hands back a list of museums. Side by side, that's a mess. The synthesizer is a final LLM step whose whole job is to weave the pieces into one clean recommendation — "Fly out Friday 9am, stay at the Rex; Saturday hit the museums near your hotel, Sunday do the river walk."

Here's that exact flow — orchestrator splits, workers run in parallel, synthesizer merges — on a real request:

{{cell:l23-orchestrate}}

Sub-Agents: A Helper With Its Own Desk

One more move, and it's the one that keeps big systems from falling over. Sometimes a single subtask is so messy — a dozen web searches, a database lookup, some cross-checking — that doing it inside the main agent would bury the coordinator in clutter. Every half-finished note piles into its context until it loses the plot.

The fix is a sub-agent: a helper agent the coordinator calls the same way it calls a tool. Think of delegating research to an assistant. You say "figure out the best neighborhoods to stay in," they go off to their own desk, do all the digging, and come back with a one-page summary — not the fifty browser tabs they opened to write it. Your desk stays clean.

{{visual:sub-agent-quarantine}}

That "own desk" has a name: context quarantine. The sub-agent chains its own tools (search, then retrieve, then summarize) inside its own isolated context, and hands the parent back only a clean package — a summary, the findings, and its sources. The messy middle never touches the coordinator. And notice the neat twist: the "tool" the coordinator calls is itself an agent. That's the agent-as-a-tool pattern.

See it in code. The sub-agent does its own thinking in its own separate message list; the parent only ever sees the one clean line it hands back — never the sub-agent's internal work:

{{cell:l23-subagent}}

Sub-agents are powerful but not free, so know when to use one:

⚠️ Sub-agents hide the messy middle on purpose — that's the whole point. But if your workflow actually needs the coordinator to see those middle steps, that same hiding works against you. Don't quarantine context you truly need.

The Loop Inside Every Agent

Patterns decide how agents hand work to each other. But zoom into any one agent, on its own turn, and you'll find a small cycle repeating under the hood. It's worth slowing down on, because it's the real difference between a plain chatbot and an agent.

Here's the intuition first. A plain chatbot answers straight from memory, in one shot. An agent is built for questions it can't answer from memory — so instead of guessing, it works the way a careful person would: figure out what you actually need, go get it, look at what came back, and decide whether you're done or need another go. That "figure out → go get → look → decide" cycle has four named steps:

flowchart LR
    P["Perception<br/>understand the request"] --> O["Observation<br/>what tools do I have?"]
    O --> A["Action<br/>call the right one"]
    A --> F["Feedback<br/>did that answer it?"]
    F -->|not yet| P
    F -->|done| Done["Final answer"]

Let's walk it slowly with one real question — "any good vegetarian restaurants near the hotel?" — for an agent that has two tools: a web-search tool and a maps tool.

1. Perception — understand what's actually being asked. The agent reads the request and works out the real intent: find vegetarian restaurants close to the hotel we already booked. (Not "what is vegetarian food" — it has to catch the "near the hotel" part and remember which hotel.)
2. Observation — look at what it can do. It scans its toolbox: web-search and maps. Which one fits "find places near a location"? The maps tool.
3. Action — actually do something. It calls the maps tool with vegetarian restaurants near [the hotel address]. This is the step that reaches into the real world; everything before it was just thinking.
4. Feedback — look at the result and decide. The tool returns a list. The agent reads it and asks itself one question: is this enough to answer?
   • Enough? It writes the final reply and stops. ✅
   • Not enough — say maps came back empty — it loops back to step 1 and tries again: maybe rephrase the search, or reach for the web-search tool instead. Then observe, act, and check once more.

That loop-back is the whole point. The agent isn't locked into a single attempt — it keeps cycling think → act → check until it either has a solid answer or gives up gracefully. That's the difference between reasoning and merely responding.

💡 This is the same ReAct ("Reason + Act") loop Nova learned as a single agent in Chapter VI. In a multi-agent system it runs inside every agent at once — the coordinator, each worker, each sub-agent.

Put the two ideas together — patterns wiring agents on the outside, this loop turning inside each one — and you have a real team.

What Nova Learns Next

Nova can now route, run workers in parallel, delegate to sub-agents, and reason in a loop — on paper. Next episode she builds it for real with LangGraph: the framework that gives her a shared memory, nodes, edges, and the persistence to run a resilient multi-agent system in production.