**
An architectural idea widely circulated in the AI community is leading many teams astray.
The Conclusion First
If you are considering naming multiple AI Agents as "Product Manager," "Architect," and "Test Engineer," and having them pass documents and collaborate like company departments—please stop.
This model seems intuitive and logically sound, but it has fundamental flaws in engineering. More importantly, none of the three major providers—Anthropic, OpenAI, and Google—use this model when building their own Agent systems.
This is not a coincidence.
What is the "Three Departments and Six Ministries" Architecture?
This metaphor refers to a class of multi-agent design ideas widely popular in the community, known by different names in various frameworks and articles: role-based agents, virtual teams, CrewAI-style division of labor, or MetaGPT-style organization. This article collectively refers to them as the "Departmentalized" model.
The core pattern is: decompose a complex task into several functions, with each Agent playing a role—PM for requirements, Tech Lead for architecture, Dev for implementation, and QA for testing. Tasks flow between Agents like an assembly line.
This model looks great on a diagram. It satisfies the human intuition for "division of labor" and makes the concept of an "AI team" concrete and explainable. Frameworks like CrewAI have accumulated many users because of this.
The problem is, it solves human bottlenecks, not AI bottlenecks.
Why This Analogy is Fundamentally Wrong
Humans need division of labor because:
- A single person has limited attention and cannot process all information simultaneously.
- Humans have professional barriers and high learning/switching costs.
- Humans need interfaces to coordinate with each other.
But LLM characteristics are completely different:
- The same model can write both PRDs and code; there are no "professional boundaries."
- The bottleneck for models is not attention span, but reasoning depth and information integrity.
- Models lack "culture" and "tacit understanding" to compensate for information loss.
Labeling an Agent as a "Product Manager" doesn't make it more professional—it makes it refuse to cross boundaries. An Agent boxed into a "Test Engineer" role might skip an architectural issue because "it's not within my scope." The most valuable reasoning often happens at the boundaries, and the Departmentalized model seals off this possibility at the system level.
Role-playing creates fake boundaries. This is the first problem.
The Second Problem: Information Dies in Transit
In the Departmentalized model, Agent A produces a document and passes it to Agent B.
This process passes conclusions, not the reasoning process.
B receives the document, re-understands it, and rebuilds the context. Original intent decays, hidden assumptions are lost, and every handoff accumulates error. The longer the workflow, the more the final output becomes "locally correct but globally drifted"—each node looks reasonable, but the whole has deviated from the original goal.
Human organizations rely on meetings, culture, and informal communication to compensate for this information loss. Agents do not have these mechanisms.
There is a common rebuttal: Don't the solutions from the three major providers (progress.txt, spec files, runbooks) also involve "passing files"? What's the difference?
The difference lies in who writes it, who it's for, and how it's updated.
Departmentalized information flow is a one-way handoff between roles: A finishes and gives it to B; B doesn't look back, and A doesn't know how B used the document. Information is compressed into conclusions, the reasoning process is lost, and the handoff is a breakpoint.
External state files are incremental logs of the same task: The executing entity appends to the same record at each checkpoint, and the next session reads the full history of the task, not the output conclusion of a previous "colleague." The person writing the state and the person reading the state are the same role, just at different times. Information is not "compressed and passed"; it is "continuously accumulated."
This difference determines whether the reasoning chain can remain continuous across sessions.
A massive amount of tokens is wasted on "handoff files" between Agents rather than actual reasoning. You get a system that simulates company behavior, not a system that solves problems.
How the Three Major Providers Actually Do It
It is noteworthy that when Anthropic, OpenAI, and Google build their production-grade Agent systems, their engineering documents almost never mention "role-playing" or "departmental division."
Anthropic: Context Engineering + Explicit State Files
Anthropic has upgraded "Prompt Engineering" to "Context Engineering": The question isn't how to write a good prompt, but what token configuration best produces the desired behavior.
When building Claude Code and Research systems, their core challenge was: Agents must work in discrete sessions, and each new session has no memory of what happened before. Their metaphor is "shift engineers"—each new shift of engineers knows nothing about the previous shift's work.
The solution isn't having Agents play different roles, but:
- claude-progress.txt: A cross-session work log that the Agent updates at the end of each session and reads at the start of the next.
- Git history: Serving as state anchors, recording every incremental change.
- Initializer Agent: Runs only in the first session to set up the environment, expand the feature list, and write the runbook for all subsequent sessions.
Key insight: The continuity of the reasoning chain doesn't rely on the model "remembering"; it relies on explicit external state to anchor it.
They also found that hard-coding "model capability assumptions" into the harness is dangerous. Sonnet 4.5 had "context anxiety"—it would wrap up early when nearing the context limit, so they added a context reset to the harness. But in Opus 4.5, this behavior disappeared, and the reset became dead weight. This shows that the harness needs to evolve with the model; any "permanent solution" is just an engineering compromise for the current stage.
In multi-agent Research systems, Anthropic's architecture is orchestrator-worker: a lead agent decomposes tasks and coordinates subagents, which explore different directions in parallel, with results flowing back to the lead agent for synthesis. They found that token consumption alone explained 80% of performance differences—the value of multi-agents isn't "division of labor," but using more tokens to cover a larger search space.
There is a point of confusion here: Anthropic's subagents might look like "division of labor," but the essence is different. Departmentalization is functional division—different roles handle different types of work (PM to Dev to QA). Anthropic's subagents are functional parallelism—multiple identical agents search different directions simultaneously, there is no "next hand," and all results converge back to the same orchestrator. The former is a relay race; the latter is casting a wide net.
OpenAI: Compaction + Skills + Structured Spec Files
OpenAI's principles for long-horizon tasks are even more direct: plan for continuity at the start of the task.
In their Codex experiments, engineers gave the agent a spec file (freezing the goal to prevent the agent from making something "impressive but in the wrong direction"), had it generate a milestone-based plan, and then used a runbook file to tell the agent how to operate. This runbook is also a shared memory and audit log.
Result: GPT-5.3-Codex ran for about 25 hours continuously, completing a full design tool while maintaining coherence throughout.
Server-side compaction serves as a default primitive, not an emergency fallback. In multi-step tasks, previous_response_id allows the model to continue working in the same thread rather than rebuilding context every time.
They also introduced the concept of Skills—reusable, versioned instruction sets mounted into containers, giving agents stable operating standards for specific tasks. These are not "roles"; they are tools and operating procedures, which are fundamentally different.
Google: 1M Context + Context-driven Development
Google's direction is to brute-force the window: Gemini's 1M token context is a clear differentiation strategy. Their logic is that previously forced techniques like RAG slicing and discarding old messages can be replaced by "just putting it all in" given a large enough window.
But they admit even this isn't enough. Google launched the Conductor extension for Gemini CLI, with a core idea identical to Anthropic's: move project intent out of the chat window and into persistent Markdown files in the codebase. The philosophy: "Don't rely on unstable chat history; rely on formal spec and plan files."
Gemini 3 also introduced Thought Signatures: saving key nodes of the reasoning chain in long sessions to prevent "reasoning drift"—the problem of logical inconsistency in long contexts.
What are the Real Architectural Principles?
From the engineering practices of these three companies, several common principles can be extracted:
The reasoning chain cannot be broken; it can only branch and merge. The correct use of multi-agents is not an assembly line, but a main agent holding the full intent, with sub-calls used to dig deep into sub-problems, and results flowing back to the main agent, not passed to the next agent.
Explicit external state, don't rely on model memory. Whether it's progress.txt, git history, spec files, or databases—the form doesn't matter. The principle is: key nodes of the reasoning chain must be externalized to persistent storage.
The value of multi-agents is parallel coverage, not division of labor. Anthropic's Research system conclusion is clear: performance gains come from "spending more tokens," not from "better division of labor." Multi-agents are suitable for breadth-first tasks—scenarios requiring simultaneous exploration of independent directions. They are not suitable for scenarios requiring continuous reasoning and deep context dependency.
The Verifier Agent is a denier, not a relay runner. If using multi-agents for quality control, the correct design is to have one Agent specifically find problems in another's work, rather than "passing the work result." Adversarial testing, not assembly line transfer.
Tools are tools, not roles. What tools you equip an Agent with (bash, file I/O, search, code execution) is far more important than what label you stick on it. Tools determine what an Agent can do; role labels only constrain what it is willing to do.
Why is the "Departmentalized" Model Popular?
Because it is easy to explain.
"This Agent is the PM, that one is the QA"—anyone can understand that. It satisfies the human desire for AI system explainability and management's imagination of "AI working like a team."
It is also easy to demonstrate. Drawn as a flowchart with departments, arrows, and handoffs, it is very intuitive.
But being easy to explain and demonstrate is different from being engineeringly sound.
A deeper reason is that most teams adopting this model haven't truly faced the problem of "context loss during multi-agent transfer." Their tasks might not be complex enough, or the problem is masked by other factors. Once task complexity rises and the system starts showing "locally correct but globally wrong" errors, the problem is exposed.
Practical Advice
The best multi-agent system doesn't look like a company. It looks more like a thinker's multiple drafts—the same brain expanding reasoning across different dimensions and finally merging them into a coherent conclusion.
Based on this principle:
Don't ask "How many Agents do I need?"; ask "What is the information dependency structure of this task?"
If a task requires continuous reasoning and high context dependency (e.g., writing a design doc for a complex feature), a single Agent + good context engineering is usually superior to multi-agents.
If a task requires simultaneous exploration of independent directions (e.g., researching 10 competitors simultaneously), multi-agent parallelism is reasonable—each subagent's task is independent, and the cost of information loss is minimized.
If a task spans multiple sessions, external state files are mandatory. An effective state file should contain four types of information:
- Task Goal (Invariant, read at session start to prevent drift)
- Completed Steps (Appended, not overwritten, to keep full history)
- Current State (Overwritten to reflect the latest progress)
- Known Pitfalls (Appended to avoid repeating mistakes in the next session)
These four types of information, maintained separately and combined, provide the full context needed by the "next self."
If adding a verification step, make the Verifier Agent's sole task to find problems, not to "take the baton and continue." Adversarial testing, not assembly line transfer.
Finally: Model capabilities are improving rapidly. Workarounds needed in the harness today might become dead weight in six months. Anthropic has already proven this—Sonnet 4.5's context anxiety disappeared in Opus 4.5. Maintaining architectural evolvability is more important than choosing a "perfect architecture."
Departmentalization is a feel-good but engineeringly expensive illusion. Its true cost isn't direct failure, but causing your system to degrade in hard-to-diagnose ways as complexity rises—where every node "looks like it's working," but the whole is drifting.
By the time you find the problem, the assembly line is already very long.
References: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
