Georgia State University — J. Mack Robinson College of Business PATH — Pathways for AI Training & Hiring CIS 4394 Agentic AI  ·  Fall 2026  ·  Dr. Xinyu Fu
Week 9 · Module 3 · Systems

Multi-agent systems — and when not to build one.

Every overloaded agent tempts you with the same fix: add more agents. Sometimes that is exactly right. More often you have just bought yourself coordination overhead, a bigger token bill, and a new class of failure that is much harder to debug. This week you learn the patterns — and the honest test for whether you need them.

📌 This week's logistics: Capstone Milestone I is due this week — submit on iCollege in your own section (details in the section below). 📝 Quiz 4 is next week — in class, closed-book, 5 multiple-choice; the scope and five sample questions are at the bottom of this week's Practice page. Group Assignment 3 is in progress — due Week 11. Capstone Milestone II releases next week.
The big question
Discussion questionYour agent is overloaded: too many tools, a context window stuffed with three jobs' worth of instructions, and results that drift. Is the right move to split it into four agents?
Only if the work actually decomposes. Ask one question, not "how many agents": can this task be cut into subtasks that run in parallel and can each be verified on their own? If yes — breadth-first research, four independent searches, four checkable answers — splitting buys you real parallelism and clean context per worker. If the subtasks form one dependent chain, or if they all read and write the same evolving artifact, splitting buys you nothing and costs you a great deal: every hand-off is a place for context to be dropped, and every agent is another full model call. "My agent is overloaded" is often a context engineering problem (Week 3) or a tool design problem (Week 5) wearing an org-chart costume.
The honest headline

More agents = more coordination

What you gain

Specialization (a narrow role with a narrow tool set), context isolation (each worker gets a clean window instead of one bloated one), and parallelism (four searches at once instead of four in a row). These are real. They are why Anthropic's own research system is multi-agent.

What you pay

Coordination: every hand-off is a contract that can be under-specified. Context fragmentation: two agents holding different pictures of the same task make confidently conflicting decisions. Tokens: each agent is a full model call with its own prompt overhead.

What gets harder

Attribution. A single-agent run has one trace to read. A five-agent run fails somewhere in the seams, and "whose fault was that?" becomes a research question — unless you paid, up front, for per-agent and per-hand-off logging (Week 8's evaluation discipline).

Interactive · the arithmetic of a team

Click a team size

Capability grows roughly with the number of agents. The number of relationships that can go wrong grows faster. This is the oldest result in organization design, and it did not stop being true when the workers became language models.

If every agent can talk to every other

Pick a team size.

Read this honestly. n(n−1)/2 is the upper bound — the number of pairs. A supervisor design deliberately refuses most of those links: workers talk only to the supervisor, so you are back to n−1 channels. That restriction is the design. Topologies are not decoration; they are how you choose which relationships are allowed to exist.
This week's pages

Work through in order

Why managers care

An agent team is a hiring decision

Cost

Each agent is a recurring per-run expense, not a one-time build cost. Anthropic reports that their multi-agent research system consumed roughly 15× the tokens of a chat interaction (Anthropic Engineering, 2025 — figure as reported, approximate). Parallel search buys breadth, not savings. A second agent has to earn that line item.

Trust

Two agents that disagree do not announce it — they produce two confident, incompatible outputs and let a human discover the contradiction. Your users cannot see the seam. That is a trust failure before it is a technical one.

Auditability

"Why did the system do that?" has a clean answer only if every agent's trace carries the Week 2 evidence standard — state before → observation → available actions → selected action → result → state after — plus the hand-off payload. Budget observability before you add the agent.

Due this week

Capstone Milestone I

What it is

Your first working capstone checkpoint: a single agent that runs end to end on your chosen task, plus the start of an evaluation harness — a handful of cases you can re-run to tell whether a change made things better or worse. Submit on iCollege in your own section; the full brief and rubric live in the Milestone I dropbox.

This week's rule, applied to your capstone

Do not add a second agent to Milestone I without a written justification. "It felt cleaner" is not one. The justification you owe is the test from page 02: name the subtasks, show that they can run in parallel, and say how each one is verified on its own. A single agent with well-designed tools is the correct default — and it is the baseline you will need in order to prove that a second agent helped.

Looking ahead: Milestone II releases next week. If you are already sure your capstone needs a team of agents, spend this week on page 02 first — the decision drill there is exactly the argument you will have to make in writing.
← CourseAll weeks