In Part 1, I described the problem and five principles: write everything explicitly, use layers, catalog hallucination traps, mark silent collapses, stay the gateway.
But I left out three things deliberately — they needed more room.
How to build agents that don't break each other.
What not to do when building the system.
How to know the system actually works.
That's this post.
Why one smart agent is the wrong architecture
The obvious setup: one powerful agent that reads everything, understands everything, fixes everything. It's flexible, it adapts, it "gets the context."
The problem: one agent is one point of iatrogenesis.
Iatrogenesis is a medical term — when the treatment causes another disease. The doctor fixes the knee, damages the nerve. The surgeon removes the tumor, introduces infection. In medicine it's a known, studied risk. In information systems almost nobody names it.
In agent systems it looks like this: the agent fixes a contradiction in file A, and in doing so creates a new one in file B. Or it summarizes a long document and loses a nuance that was critical three layers down. Or it rewrites a section "for clarity" and subtly shifts the meaning — consistently with its own model, not yours.
The fix is the same as in surgery: specialization. A surgeon who only does knees doesn't touch nerves. An agent that only reads and builds a model can't accidentally break anything — it has no write access. An agent that only adds content never rewrites existing text — by design.
Each role, one responsibility, one explicit constraint:
Reader → extracts understanding. builds a model. never edits.
Verifier → runs the hallucination checklist. emits COLLAPSE markers.
Surgeon → reads the report. makes targeted edits. never rewrites.
Mirror → checks symmetry. is every connection described from both sides?
Filler → only adds. never touches existing content.
Auditor → checks distribution. where does info live on the wrong layer?
These aren't product names — they're roles. Your implementation might have three of them or fifteen. The principle is the same: every constraint is a removed degree of freedom for error.
And the number of agents is unlimited. When a new domain appears, you add a role for it. The pipeline scales horizontally without changing the core.
Iatrogenics: the patterns that look like work but aren't
Beyond multi-agent design, there are recurring failure modes that appear when building any knowledge system with LLMs. They all share the same shape: they feel productive, they produce output, and they quietly degrade the system.
"The main stuff is covered."
This is rationalization of incomplete reading. There are no unimportant parts of a knowledge system. An unread source isn't "background context" — it's a blind spot. The only honest alternative: flag it explicitly. "Read 12 of 20 sources. The remaining 8 require a second pass covering: [list]." Incomplete analysis doesn't get called analysis.
"Exactly N items in the system."
Hardcoding counts is a pressure artifact. The agent is implicitly told: fit reality into this number. So it does. It picks the five most prominent issues and ignores three others that are equally real. The count should come from the content, not the prompt. Always.
"Top 5 problems."
Same mechanism, worse outcome. Limiting the output count is not brevity — it's information loss. If there are eight problems, there are eight problems. The agent that returns five has made an editorial decision on your behalf, without flagging it.
"Describe it briefly."
Volume should follow content, not instructions to be concise. Nuance lives in the details that get cut first. If a brief description is genuinely sufficient — it will be brief naturally. Forcing brevity on a complex topic produces a description that sounds complete and isn't.
Rigid output format.
This is the subtlest one. If your prompt requires "five sections" — you will always get five sections. Even when the content calls for three or eight. The agent optimizes for format compliance, not for accuracy. Format should follow content. Always the other way around from what most people do.
The ACE paper (Zhang et al., arXiv:2510.04618, 2025) describes the same failure at the architectural level and calls it brevity bias — the system optimizes for shorter outputs because shorter is what the format rewards. The same dynamic happens in knowledge systems when you constrain the output shape before you understand the content shape.
The series so far — and where it goes
Part 1 — the problem and five principles: write everything, use layers, catalog hallucination traps, mark collapses, be the gateway.
Part 2 (this post) — agents and specialization, iatrogenics patterns.
Part 3 — determinism as an engineering requirement: what it means, how to test for it, and what "done" actually looks like.
After that: real failure modes from real domains — confabulation vs hallucination, static automation, and why your tech stack is a consequence not a decision.
Method developed from a real working system. The tools — Markdown, Obsidian, open-source Copilot — are one implementation. The principle works with any stack.
References: Zhang et al. arXiv:2510.04618 (ACE, 2025), Li et al. arXiv:2507.03724 (MemOS, 2025), Luhmann (1981).
Top comments (0)