Multi-Agent Applied Builds: overview

A hotel coordinator can skip policy review or misroute a booking while still producing a polite reply. You will inspect actual node paths and database effects, add bounded error handling and merge specialist results, then build a research team led by a supervisor, a typed router or a one-shot planner.

Lessons 1 to 3 of T11.3 follow the notebooks' hotel support desk: a coordinator that talks to the guest, a compliance checker over four hotel rules, and a reservation agent over a SQLite database of eight rooms. Room 105, the Family Suite, is booked from today+30 to today+33, and the notebooks use it to show a clash. Lesson 4 of T11.3 and the interview questions move the same designs onto Larkspur Cloud, the fictional cloud host whose handbook runs through T5.1 to T5.3: its support desk, its refund and export policies, and a research team that answers from the handbook and the web.

• The compliance checker is a small RAG agent. It retrieves the 2 most relevant of the hotel's 4 rules and returns a typed verdict, COMPLIANT or VIOLATION. The coordinator sends every new request to it first, and a loop guard in code stops it being asked twice.
• The guards that matter live in tools and code, not in prompts: a read-only SQL connection whose authorizer hides guest names, one parameterised book_room tool, a date check in plain Python, a hard cap on revision loops.
• Test the router as a pure function. Notebook 02b's seven router tests need no model. In the lab, any threshold from 71 to 90 turns all seven green, because the confidence gate hides the known issue instead of fixing it.
• Parallel agents need one message key per branch, a join that waits for every branch, and one merge that writes one reply. Long threads fold old messages into a summary and delete them by id.
• A research team can be led by a supervisor, a typed router or a one-shot planner. The supervisor adapts but is hardest to bound; the planner fixes its queries up front, so its cost is known before the first search. Its quality loop stops at MAX_DRAFTS = 2 in code, whatever the reviewer says.

One node talks to the guest, specialists do the work, and plain functions between them decide where the turn goes. Every later build in the module keeps that split: the research system in 37.4 changes who the specialists are, while routing, caps and checks stay in code where a test can reach them.

Router test bench: open the file in a browser. Start at threshold 50: six of the seven router tests pass, and the seventh is the known issue the suite records on purpose. Slide to 75 and all seven pass, because the confidence gate now ends the known-issue turn before the name check runs. Then write your own coordinator reply under Route your own reply and find one that forwards while saying it will not.

• Before: T10.1 and T10.2 teach the checkpointers, threads, summaries and stores these builds use for memory. T11.1 and T11.2 teach supervisors, routers, parallel branches and Send one at a time. T7.2 covers create_agent and middleware, and T8.3 human approval with interrupt().
• Next: T12.1 to T12.4 move tools and agents behind protocols: MCP servers for tools, A2A between agents. The coordinator and specialist split stays the same.

• Put every rule that must hold in code or in a tool: a read-only connection, a parameterised write, a pure router, a loop cap. Prompts ask; code enforces.
• Test routing as a pure function on hand-built states, keep known issues as tests, and check side effects in the database, never in the agent's wording.
• Fan out with one state key per branch, join before you merge, keep writes out of parallel branches, and summarise old turns into state before the thread outgrows the context.
• Bound a research team in code: tie every finding to its source, score each draft by its weakest criterion, and stop the quality loop at a fixed draft cap.