systemdesign.academyAI EngineeringFree lessonsSign inGet the course
  1. Home

Where this shows up in interviews

This idea carries a full system design question on its own. Each walks through the full answer.

  • →Design a Multi-Agent System
Previous lessonAgent Memory and Context: What the Model Sees, and What It ForgetsNext lessonAgent Reliability Math: pass@k, pass^k, and Why 95 Percent Fails

System Design

  • Foundation
  • Intermediate
  • Advanced
  • Capstone

AI Engineering

  • Foundation
  • Data, RAG and Agents
  • Evaluation, LLM Ops and Security

systemdesign.academy

  • Home
  • Glossary
  • Interview prep
  • Reviews
  • About
  • Pricing
  • Privacy
  • Terms
  • Refunds
  • Delivery
  • Contact
AI Engineering: Data, RAG and Agents
  • Agents in Production
  • Multi-Agent Systems, and When Not to Build One

    • AI Engineering · Agents In Production

    Multi-Agent Systems, and When Not to Build One

    Free preview: the first part of this 11-part lesson.

    Already bought the course? Sign in to read the whole lesson.

    this lesson is part of

    AI Engineering

    Unlock this lesson and the 199 other paid lessons

    • 210 lessons in 16 chapters
    • 118 lessons built on a lab that really ran
    • An AI tutor beside every lesson that answers and draws
    • Lifetime access, every new lesson included

    $49 once, by PayPal

    See the AI Engineering course

    The rest of this lesson

    1. The Words You Need First
    2. When Does More Than One Agent Genuinely Help?
    3. What Does Coordination Actually Cost?
    4. Why Do Agent Swarms Fall Apart?
    5. Does Adding Agents Make the System More Reliable or Less?
    6. The Four Designs, Worked by Hand
    7. So How Do You Decide?
    8. Common Mistakes
    9. What This Chapter Was Really About
    10. Knowledge Check

    read the rest of this lesson in

    AI Engineering

    Unlock this lesson and the 199 other paid lessons

    • 210 lessons in 16 chapters
    • 118 lessons built on a lab that really ran
    • An AI tutor beside every lesson that answers and draws
    • Lifetime access, every new lesson included

    $49 once, by PayPal

    See the AI Engineering course

    Continue this lesson

    in Agents In Production

    This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.

    One-time payment. Lifetime access. No subscription.
    Global
    $49/lifetime

    One-time payment via PayPal

    Get Lifetime Access
    Foundation lessons free, try before you buy
    India Special
    India
    ₹999/lifetime

    One-time payment: UPI, card or netbanking

    Get Lifetime Access
    Foundation lessons free, try before you buy
    Every ML Platform lesson, Foundation to Advanced
    Real architecture diagrams with real tool logos
    MLOps, LLMOps, and data engineering in depth
    Quizzes with instant feedback
    Built and reviewed by senior engineers
    Lifetime access, all future content included

    Foundation lessons of this course are free, no payment needed. Try them now

    When an Agent Gets Hard, Should You Split It Into a Team?

    Usually no. The right default is one agent with a good set of tools.

    The temptation is strong and it feels principled. The task is hard, so you break it into parts and give each part its own agent: a researcher, a writer, a checker, a fixer. It looks like clean design, the kind you would use for a team of people. But an agent is not a person, and a team of agents is not an org chart. It is a distributed system where every member is stochastic and sometimes wrong, and every message between them is another place the whole thing can break.

    Side-by-side architecture comparison: on the left a single agent connected to a row of tool chips (search, query_db, write_file, create_pr, run_code) with one context and one transcript; on the right an orchestrator with three subagents (researcher, writer, checker) that each carry their own context, showing the extra coordination the team introduces

    A single agent with the right tools is simpler to build, cheaper to run, and far easier to debug, because there is one context, one transcript, and one place the failure happened. The moment you have several agents, you have several transcripts, several contexts, and a new problem the single agent never had: getting them to agree. That problem is not free, and most tasks do not need to pay for it.

    Look closely at the two shapes. On the left, a failure has one home. You open a single transcript, you find the step that went wrong, you fix it. On the right, the same failure could live inside any of the three agents or, worse, in the space between them, in a handoff where one agent's output was read by another and quietly misunderstood. That second kind of bug is the expensive one, because there is no single place to look. You are debugging a conversation, not a program.

    This is the closing lesson of the chapter, and it is deliberately contrarian. The whole industry spent a year selling agent swarms. The engineers who actually shipped came back with a quieter answer: start with one, and add agents only when you can say exactly what they buy you. Restraint is not the timid choice here. It is the one that ships.