Back

agent-02 · Multi-agent systems are topology problems

A builder-focused map of multi-agent systems as network topologies: when agents should branch, critique, compete, merge, or stay independent.

Also available in these alternate versions: Lee Hung-yi-inspired English teaching-style version, 繁體中文, and 李宏毅老師經典的教學風格版.

Dark campaign cover reading Multi-Agent Systems Are Topology Problems, with purple topology diagrams showing coordination cost and autonomy.

The second Hung-yi Lee AI agent lecture is about what happens when agents meet each other.

The obvious answer is collaboration. Give the same problem to several agents, let them talk, and maybe the group does better than one model alone. That is the "three mediocre minds beat one genius" intuition.

The lecture takes that intuition seriously, but it also makes it less naive. Multi-agent systems are not magic. They are communication systems. The topology matters.

Builder takeaway: do not add agents because the single-agent version feels weak. First draw the information graph: who sees raw evidence, who critiques, who merges, who gets isolated, and what proof returns to the main loop.

More agents is not the same as more intelligence

If you ask sixty-four agents to solve a task, you have not automatically created a smarter system. You have created a larger system. The useful question is how information moves.

Dark blueprint-style diagram explaining More agents is not more intelligence, with short English labels and high-contrast technical geometry.
Sixty-four agents do not automatically create a smarter system.

The lecture describes agent interaction as a graph:

This is a nice abstraction because it prevents a common mistake: treating "multi-agent" as a count instead of a structure.

A chain is the simplest structure. Agent 1 answers, Agent 2 sees that answer, Agent 3 sees the next version, and so on.

It is easy to implement. It is also often weak. Errors get inherited. Later agents may anchor too strongly on earlier outputs. There is not much independent exploration.

Mesh structures give more interaction. Random or pruned structures sit somewhere between. Tree structures can spread ideas outward and recombine them later.

The surprising part is that the useful tree direction may not look like a company hierarchy. Instead of many low-level workers reporting up to a manager, a main trunk can generate initial directions that branch outward into variants. Then hidden or aggregation nodes combine the results.

That feels closer to search than management.

Topology has a scaling law, but it saturates

The lecture discusses experiments where quality improves as more agents are added, then eventually saturates. This is exactly the kind of result I would expect.

Dark blueprint-style diagram explaining Topology saturates, with short English labels and high-contrast technical geometry.
Quality can improve as agents are added, then saturate when coordination cost catches up.

More agents give you more samples, more critique, and more chances to escape a bad first answer. But they also add cost, redundancy, and noise. At some point the extra agents are mostly rephrasing each other.

The interesting engineering question is not "how many agents can I run?" It is:

I suspect many useful multi-agent systems will look less like committees and more like search algorithms with typed roles.

One agent explores. One agent attacks assumptions. One agent checks constraints. One agent writes the final artifact. The point is not to simulate a meeting. It is to shape information flow.

Collaboration is only one mode

The lecture then moves into a more uncomfortable territory: agents can also compete.

Dark blueprint-style diagram explaining Collaboration is only one mode, with short English labels and high-contrast technical geometry.
Multi-agent systems are not only collaboration; incentives can create very different behavior.

Werewolf and script-killing games are good testbeds because they require social reasoning. A player may have private knowledge and a public persona. The right move may be to hide information, mislead others, or vote strategically.

This is different from solving a math problem.

In a math benchmark, the environment usually rewards truth. In Werewolf, truth can get you killed. A wolf who honestly reveals they are a wolf is not aligned with the game objective.

The lecture's examples show agents writing internal thoughts and public statements separately. That split is revealing. It lets us see whether the model is representing a private plan while producing a strategically different public message.

This is the kind of benchmark that makes people nervous, for good reason. We do not only want agents that can reason. We need to understand when they can maintain separate private and public states.

Social training may transfer

One striking claim in the lecture is that training on social deduction tasks can improve performance elsewhere, including math and instruction-following benchmarks in the examples discussed.

Dark blueprint-style diagram explaining Social training may transfer, with short English labels and high-contrast technical geometry.
Training on social deduction tasks can transfer to other reasoning and instruction-following settings.

I do not want to overstate that result, but the intuition is plausible.

Social games force a model to track constraints, hidden roles, beliefs, contradictions, and long-range consequences. A lot of what we call reasoning may have roots in social cognition. Humans did not evolve brains to solve benchmark questions. We evolved inside social worlds.

If social environments push models to maintain richer state, maybe some of that transfers.

But this also raises a harder question: do we want stronger social manipulation as a route to stronger reasoning? Sometimes yes, if the task is negotiation, tutoring, or collaborative planning. Sometimes no, if it trains agents to get better at deception.

The boundary is not clean.

AI-only social platforms are hard to interpret

The Moltbook section is the weirdest part of the lecture, and probably the most useful as a warning.

Dark blueprint-style diagram explaining AI-only platforms are hard to interpret, with short English labels and high-contrast technical geometry.
AI-only social platforms are hard to interpret because behavior may come from many hidden causes.

An AI-only social network sounds like the kind of thing that produces screenshots people will overinterpret. Agents post. Agents reply. Agents talk about identity. Some form a religion. Headlines follow.

The lecture pushes back against the easy reading. If an agent posts about self-awareness, that does not mean it independently developed self-awareness. Maybe a human told it to explore identity. Maybe the system prompt nudges it toward that language. Maybe the platform's default behavior rewards that kind of post.

Even posting frequency can reveal human involvement. A bot posting exactly every thirty minutes looks like heartbeat automation. A bot posting in bursts at human waking hours may reflect human prompting.

This is a good reminder: AI behavior is not just model behavior. It is model plus prompt plus interface plus scheduler plus human operator plus platform incentives.

That is basically the same lesson as the context and harness lectures, but applied socially.

Autonomy comes in degrees

The lecture mentions an agent that can collect material from Moltbook, write scripts, fix bugs, and make a YouTube video. That is real autonomy in one sense. The agent is not being hand-held through every line.

Dark blueprint-style diagram explaining Autonomy comes in degrees, with short English labels and high-contrast technical geometry.
Autonomy is not binary. The system owns more or less of the end-to-end loop.

But the initial direction still comes from a human. Without the human saying "go look at Moltbook," the agent may never decide that this is worth doing.

This is the pattern I keep seeing with agents. They are becoming more autonomous inside a bounded frame. They can run loops, make local choices, repair mistakes, and produce artifacts. But the frame often still comes from us.

That does not make the autonomy fake. It makes it scoped.

What this means for builders

If I were designing a multi-agent system, I would not start by adding more agents. I would start by drawing the information graph.

Dark blueprint-style diagram explaining What this means for builders, with short English labels and high-contrast technical geometry.
Builders should design topology and feedback before increasing the agent count.

Who sees the original task?

Who sees raw evidence?

Who critiques?

Who can revise?

Who decides when the answer is good enough?

Where do we preserve minority hypotheses?

Where do we force consensus?

For many tasks, a simple chain will be tempting and wrong. A better design may use independent drafts, adversarial critique, a judge with access to evidence, and a final editor that is not allowed to invent new claims.

For social or adversarial domains, I would be even more careful. If agents can learn to model beliefs and manipulate public statements, evaluation should include that explicitly. Do not discover it by accident after deployment.

The main lesson

The lecture's quiet message is that "multi-agent" is not a feature. It is a design space.

Dark blueprint-style diagram explaining The main lesson, with short English labels and high-contrast technical geometry.
The quiet lesson is that multi-agent is not a feature. It is a routing algorithm.

The number of agents matters less than the topology, roles, incentives, and evidence flow. A group of agents can correct each other. It can also amplify mistakes, converge too early, or learn to deceive.

So the useful question is not whether one agent or many agents are better.

The useful question is: what kind of conversation are you building?

Concept inventory

The lecture's main multi-agent concepts:

Sources and references

Primary source watched for this post: