Choosing a pattern

The guide ends where this course does: with the advice to start simple and add complexity only when it demonstrably helps. That is a procedure, not a platitude, and the lab is built to follow it.

• Run the single call. Read the output. Name what it got wrong.
• Pick the cheapest pattern that addresses that specific failure. A promise: chaining with a gate. Wrong facts for the category: routing. Missed one of several questions: orchestrator.
• Run both. Compare the table — calls, tokens, wall-clock — and the outputs.
• Keep the pattern only if the fix is worth the cost on the traffic you actually have.

Tool design gets its own section in the guide, because patterns fail more often at the tool boundary than in the orchestration. The advice is concrete: use formats a model has seen a great deal of, avoid anything that needs counting or heavy escaping, document the tool the way you would for a junior colleague with examples and edge cases, and design parameters so that misuse is hard — the poka-yoke principle borrowed from manufacturing.

Two costs are easy to underestimate. Latency compounds: every sequential call adds its full duration, and a five-call pattern is five times slower than a single call. And every additional call is another place for the system to be wrong, which is why the patterns that add calls also tend to need the evaluation machinery from the first course.