CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
Page 01 taught you the patterns. This page tries to talk you out of using them. That is not contrarianism — it is the actual state of the practice: the people who have shipped these systems, including the ones who ship them successfully, agree that the boundary is narrow and that most teams cross it too early.
The engineering team behind Devin argues against the default multi-agent design, and their reasoning is structural rather than stylistic. Two principles anchor it: share context, and treat every action as carrying an implicit decision.
When you split work across subagents, each one sees a fragment. Each fragment leads to a locally reasonable choice. Those choices are made with no visibility into one another — so the pieces come back conflicting, and nobody in the system is in a position to notice. Worse, the conflicts are plausible: two agents produce two coherent halves of an incoherent whole. Their prescription is to keep one continuous thread of context and, when a task is too long for one window, to compress deliberately rather than to fragment accidentally.
LangChain answers from the other direction, and lands on a compatible boundary. Multi-agent earns its cost when the work genuinely divides: subtasks that can run in parallel and whose outputs are independently verifiable. Read-heavy research is the clean case — several searches, several checkable findings, one synthesis.
Write-heavy work is the dirty case. When agents must produce a single coherent artifact, or make decisions that depend on each other's decisions, parallelism is fictional and verification is impossible in isolation — you can only judge the pieces by looking at the whole, which is precisely what no individual agent can see.
Cemri et al. (2025) studied a large set of multi-agent LLM traces and organized what went wrong into the MAST taxonomy: fourteen failure modes grouped into three categories. The value of a taxonomy is that it turns "it broke" into a diagnosis you can act on — so learn the three categories, and use them as your debugging checklist.
The failure was baked in before the run started: a role defined too vaguely to constrain behavior, a task description missing the constraint that mattered, an agent that ignores its instructions, or a design with no termination condition. The instruction-decay example on page 01 lives here.
Tell: every agent did exactly what it was told, and the result is still wrong.
The failure happened between agents: a hand-off that dropped context, agents working from incompatible assumptions, conversations that go in circles, duplicated work, or one agent quietly derailing another's task. This is Cognition's fragmentation argument, catalogued.
Tell: each agent's output looks fine in isolation; put two of them side by side and they contradict.
The failure was one nobody checked for: work ended prematurely, verification was absent, or the "verifier" was itself an LLM glancing at the output and declaring it good. A reviewer agent that agrees with everything is a rubber stamp with a token bill.
Tell: the system says "done" and is confidently wrong — and no artifact in the trace records what "done" was supposed to mean.
Cemri et al. (2025) — Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657) ↗
Adding an agent is not like adding a function call. Each agent is a full model invocation carrying its own system prompt, its own tool definitions, and its own accumulated context — and the supervisor pays again to write each hand-off and read each result back. The overhead is per-run and permanent.
The one public number we can cite precisely: Anthropic reports that their multi-agent research system used about 15× more tokens than a chat interaction, alongside roughly a 90% improvement over a single-agent baseline on their internal research evaluation. Both figures are as reported in their engineering post, approximate, and specific to that system and that eval — they are not a general multiplier for multi-agent systems, and you should not quote them as one.
The transferable lesson is the shape, not the number: you pay a large multiple, up front and every run, for breadth. If the task's value does not clear that bar, the correct architecture is one agent.
Anthropic Engineering — How we built our multi-agent research system ↗
Three questions to put to any team proposing a multi-agent architecture, in order:
Latency deserves a footnote: parallel workers can genuinely finish a breadth-first task faster in wall-clock time, even while burning more tokens. Speed and cost move in opposite directions here, so be explicit about which one you are buying.
Five situations. For each, apply the test: do the subtasks run in parallel, and can each output be verified on its own? Answer before you reveal — this is the exact judgment Milestone I asks you to defend in writing.
In Week 8 you built the discipline of evaluating an agent: fixed cases, a scored run, a number that moves when you change something. Multi-agent breaks the easy part of that — not the scoring, but the attribution.
The aggregate score drops three points. Which of your five agents caused it? With only an end-to-end trace, you cannot say — and the natural response, changing prompts until the number recovers, is not engineering. It is also expensive: each experiment now costs a full multi-agent run.
Worse, failures compound quietly. Agent 2 hands agent 3 a subtly wrong fact; agent 3 reasons impeccably from it; agent 5 writes it up beautifully. The output is confidently wrong and every individual step looks defensible. This is why "the answer looked good" is not evidence in a multi-agent system.
Each agent gets the Week 2 evidence standard in full: state before → observation → available actions → selected action → result → state after. On top of that, multi-agent adds three things a single-agent trace never needed:
Budget the observability before you add the agent. Retrofitting per-hand-off logging onto a running five-agent system is how teams end up rewriting it as one agent.