You’ve read the catalog, and the temptation is real: build the multi-agent orchestrator with memory and guardrails on day one. Resist. Every pattern in this catalog is a response to a problem you can observe — and the systems that work in production got there by climbing one step at a time.

The analogy

You don’t buy the truck before the bicycle. A delivery business starts with one bike; when orders demonstrably exceed the bike, it buys a scooter; the truck comes when the scooter overflows. Each upgrade is a response to a measured limit — never to the fear of one.

The principle

Start at step 1. Climb only when the current step measurably fails.

  1. One augmented LLM call — a good prompt, your data in the context, the few tools that matter. This solves more than people expect.
  2. A workflow — the route is known? Wire it: chaining, routing, parallelization.
  3. An agent loop — only when the path genuinely can’t be scripted.
  4. Multi-agent — only when one context provably can’t hold the task.

And which pattern, when you do climb? Ask three questions:

flowchart TB
    Q1{"are the steps known in advance?"} -->|yes| Q2{"do they depend on each other?"}
    Q1 -->|no| Q3{"is there verifiable feedback — tests, compiler, API?"}
    Q2 -->|"yes, in sequence"| A["prompt chaining"]
    Q2 -->|"no, independent"| B["parallelization"]
    Q2 -->|"it depends on the input"| C["routing or orchestrator-workers"]
    Q3 -->|yes| D["agent loop"]
    Q3 -->|no| E["stay at a workflow — an agent that can't self-check will drift"]

A concrete example

A team automating support-ticket answers:

week 1 → one augmented call: prompt + RAG on the docs
          → already handles 60% of tickets. Ship it.
week 4 → measurement: billing tickets fail often
          → add routing: billing gets its own path. 75%.
week 9 → complex tickets need account lookups + actions
          → agent loop, gated by human approval. 85%.

Three steps, each justified by a number — and at every stage, a working system in production.

The starter checklist

  • Pick the model second. Define the task, the data and the success criterion first; then choose the cheapest model that passes.
  • Write the system prompt like instructions: role, rules, tone, output format — short and testable.
  • Fewest tools possible. Every tool schema costs context on every call.
  • One verification from day one: a format check, a test run, a sample review — you can’t improve what you don’t measure (see evaluate & observe).

The classic trap

Architecture as procrastination. Weeks spent wiring agents-that-talk-to-agents feels like progress, but a shipped single call teaches you more than a diagram. The best first agent is the one answering real users this week.