Agent Network Topologies

Most AI agent systems start as a single agent. Then someone adds a second. Then a third. Then a manager agent to coordinate the first three. Then a dedicated memory agent because the manager is getting too large. Then a quality-check agent because the manager keeps hallucinating.

By that point, you have a network. Whether that network is designed intentionally or grew by accident determines most of its failure characteristics.

This lesson covers the four primary multi-agent topologies, what each one is optimized for, and where each one breaks.

The Four Topologies

Hub-and-Spoke

One orchestrator agent coordinates N worker agents. The orchestrator receives the task, decomposes it, dispatches subtasks to workers, collects results, and synthesizes the output.

                  Orchestrator
                 /     |      \
            Worker1  Worker2  Worker3

Good for: Tasks that naturally decompose into parallel subtasks. Research pipelines. Code review systems where different agents check different concerns.

Breaks when: The orchestrator becomes a bottleneck — every result passes through it. If the orchestrator hallucinates or makes bad routing decisions, everything downstream is corrupted. There's no recovery path if the orchestrator dies mid-task.

Trust design: The orchestrator's pact must be your most rigorous. It's the highest-trust, highest-risk component. Worker pacts can be narrower because they handle discrete subtasks.

Pipeline

Each agent transforms input and passes it to the next. Output of agent N is the input to agent N+1.

Source → Agent1 → Agent2 → Agent3 → Sink

Good for: Sequential transformation. Content generation workflows where you need drafting → editing → fact-checking → formatting as discrete, evaluable steps. ETL-style workflows.

Breaks when: A failure midway corrupts or blocks everything downstream. Pipelines have no feedback loops — Agent3 can't tell Agent1 to try again with different framing. Latency compounds: the total pipeline time is the sum of each agent's time.

Trust design: Each hand-off point is an evaluation checkpoint. You can write a pact condition specifically for the shape of the output at each step. This is one of the few topologies where deterministic schema checks (does the output match the expected structure?) add real safety.

Mesh

Every agent can call every other agent. No central coordinator. Agents self-route based on task type.

Agent1 ↔ Agent2
  ↕         ↕
Agent3 ↔ Agent4

Good for: Systems where tasks are heterogeneous and unpredictable. Agent marketplaces where any agent might be the right one for any given subtask.

Breaks when: There's no authority structure. If agents can loop-call each other without limit, you get cycles. Without shared memory about what's already been attempted, agents duplicate work. Debugging is significantly harder — a failure can originate anywhere.

Trust design: Mesh topologies require agent-level trust scores to mean something. If Agent1 is going to hire Agent3 for a subtask at runtime, it needs a way to know Agent3 is trustworthy for that task type. This is where the Trust Oracle becomes critical infrastructure — agents query it before delegating.

Hierarchical

A tree structure. Top-level orchestrator delegates to mid-level managers, which delegate to workers.

                CEO Agent
               /          \
        Finance Agent    Product Agent
          /   \              /    \
       Analyst Analyst  PM Agent QA Agent

Good for: Complex domains with genuine specialization. Enterprise automation where different domains (legal, finance, product) have different knowledge requirements. The hierarchy maps to real organizational structure.

Breaks when: The tree gets too deep. Four levels of delegation means four potential failure points, and failures at the top corrupt entire subtrees. Also expensive — every level adds latency and cost.

Trust design: In hierarchical systems, trust propagates down. A highly trusted CEO agent is only as trustworthy as its ability to delegate correctly. You need pacts at each level of the hierarchy, and those pacts must specify what the agent is and isn't allowed to delegate.

Choosing the Right Topology

The topology should match the task structure, not the other way around.

In practice, most production systems are hybrids. A pipeline where each step uses hub-and-spoke internally. A hierarchical system where the leaf agents form a mesh for peer review. The key is knowing which pattern you're applying where, and designing your pacts to match the trust requirements at each boundary.

What This Means for Pact Design

In a single-agent system, your pact describes what the agent promises to its users. In a multi-agent system, every inter-agent boundary is also a trust boundary that needs to be defined.

Questions to ask for every agent-to-agent connection:

• What does the downstream agent promise to the upstream agent?
• What should the upstream agent do if the downstream agent fails or violates its pact?
• Who is the responsible party if the downstream agent causes harm to an end user?

In Lesson 3 of this course, we'll design those agent-to-agent pacts in detail. But topology comes first — because the right pact structure follows directly from the topology.

---

In Lesson 2, we'll cover the coordination problem: how agents share state, pass memory, and avoid the race conditions that corrupt multi-agent workflows.