Project: the wedding planner
Three ideas from this module now have to occupy one system: tools you did not write, data in the right compartment, and more than one agent. The interesting failures are all at the joins.
The scenario
A planner coordinating a wedding. Venue availability and catering quotes come from suppliers’ remote MCP servers. The couple’s budget, date and guest count are fixed at the start. The running plan, the bookings made and the spend so far all change constantly.
That description already contains most of the design.
Placement first, agents second
Do the boring part first, because it is the part that decides whether the rest works.
- Context: budget, date, guest count, couple id. Caller-supplied, fixed for the run, read only.
- State: the running plan, bookings made, spend so far, any escalation flag. Written during the run.
- Store: anything that should survive this engagement entirely, such as supplier preferences learned last time.
The trap in this domain is grouping by topic rather than by mutability. Total budget and running spend are obviously the same subject, and they belong in different compartments, because one is written and the other is not.
The agent count question
The join that catches people
An MCP tool is a tool. It attaches to whichever agent needs it, and it does not need an agent wrapped around it for isolation, because the protocol boundary is already the isolation.
The genuinely non-obvious one is context propagation. A subagent invoked as a tool does not automatically inherit the parent’s context. Anything the specialist needs, such as the tenant or the budget, has to be passed deliberately.
This works perfectly in development, where there is one couple and one tenant and the missing value happens to be the only value there is. It fails the first time there are two. That is the shape of nearly every multi-agent bug worth knowing about: not wrong logic, but an assumption that held because the test data was too small to disprove it.
Try it yourself
Place the budget
The couple's total budget is fixed for the whole engagement, but the running total spent changes every time a supplier is booked. Where do the two values go?
Show answer
Correct answer: C — Total budget in context, running total in state
The fixed figure is caller-supplied and never written during the run, so it is context; the running total is written by the agent as it books, so it is state. The first option is the natural grouping error, because the two values are obviously about the same subject and the instinct is to keep related data together. Placement follows mutability, not topic.
Specialist or tool
The planner needs venue availability from a supplier's remote MCP server. Does that become a subagent?
Show answer
Correct answer: A — No, it is a tool; MCP exposes tools and a tool needs no agent around it
MCP gives you tools, and tools attach directly to the agent that needs them. The second option is the seductive one because isolating an external dependency behind its own boundary is genuinely good instinct in most architectures; here the boundary already exists at the protocol, and wrapping it in an agent adds a conversation history and a model call to something that was already a function call.
What composition exposes
Every project lesson exists to surface a disagreement between two things that were individually correct.
Name two decisions from module 2 that only become forced once MCP tools, context and multiple agents are in the same system.
Reveal answer
First, tool ownership: when several specialists exist, you have to decide which of them holds which MCP tools, and giving every agent every tool destroys the reason for splitting them. Second, context propagation: a subagent invoked as a tool does not automatically inherit the parent's context, so anything a specialist needs has to be passed deliberately rather than assumed, and that is exactly the kind of assumption that works in testing with one tenant and breaks with two.
Specify it on paper first
This one is deliberately not a build. The wiring is now large enough that specifying it is the harder and more transferable skill.
- Write down the agents you would create and, for each, the one thing it can do that the coordinator structurally cannot.
- Cross out any agent whose answer was about following longer instructions, and note which pattern it should have been instead.
- List every data field the system touches and place each in state, context or store.
- For each specialist, decide subagent or handoff, and write the sentence that justifies it in terms of where control ends up.
- Mark every MCP tool with which agent owns it, and confirm no tool is owned by two.
Trace one request end to end
Take a single user request that needs two specialists and walk it through your design by hand.
You can say at every step which agent holds control, and you found at least one place where context has to be passed explicitly rather than inherited.