The interesting claim in this survey isn’t that multi-agent systems are hard — it’s where the difficulty lives. Once you stack prompt engineering, context engineering, harness engineering, and loop engineering onto a single agent, you hit a ceiling that no amount of extra context clears: heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and persistent state don’t fit inside one agent’s head. The authors call the thing you actually need “system intelligence,” and their argument is that you get there by making the structure explicit rather than implied.
That framing matches what I see in production. The moment an agentic workflow has more than a couple of specialists, the orchestration logic stops being a routing prompt and becomes a graph — nodes for agents and tasks, edges for control flow and verification, a state object that has to survive retries and partial failure. Treating that graph as a first-class, evolving artifact, instead of something buried in a tangle of if-statements, is where reliability comes from. It’s also where knowledge-graph habits pay off: the same schema discipline that grounds retrieval grounds coordination.
What I’d actually do with this is use it as a checklist for the orchestration layer, not a new framework to adopt. Does your system have an explicit representation of who does what, in what order, with what verification? Can that structure change at runtime without a rewrite? The paper page on Hugging Face links a companion repo of methods worth mining. My open question: if the graph is dynamic and self-modifying, how do you keep it debuggable? A multi-agent system you can’t trace at 2am isn’t more intelligent — it’s just harder to page.