OSI for AI: Network Engineering Patterns for Multi-Agent Systems

A typical multi-agent AI system works like this: agent A calls agent B for a task. Agent B sometimes calls agent C. Agent C sometimes calls agent A for context. There is no shared set of rules. There is no map of who calls whom. There is no promise that a request will succeed. When the system breaks, no one can explain why.

This is not a new problem. Network engineers solved it in 1984 by building the OSI model. It has seven layers. Each layer has a clear job. Together they turned the chaos of computer-to-computer communication into an orderly system. The same idea works for multi-agent AI.

The OSI-to-AI Mapping

Each layer of the OSI model has a direct counterpart in a multi-agent AI system:

• Application layer (L7) → Your top-level user request and the SINC-2 / structured prompt format that carries it
• Presentation layer (L6) → Converting data formats between agents (JSON to markdown to tool-call schemas and back)
• Session layer (L5) → Keeping track of the conversation, managing the context window, staying on topic across many turns
• Transport layer (L4) → Getting messages from one agent to another reliably (retries, timeouts, error fixes)
• Network layer (L3) → Routing: deciding which agent handles which request, using a classifier to choose
• Data link layer (L2) → The direct link between two specific agents, including who is allowed to call whom and how often
• Physical layer (L1) → The real API call to the LLM provider (HTTPS, model choice, token limits)

Most teams put everything in the application layer and ignore the rest. There is no reliable delivery. There is no routing map. The system works in testing and breaks in production.

What the Topology Designer Returns

The free Multi-Agent Topology Designer reads your workflow description and gives back the full network spec:

Agents

Each agent gets an ID, a name, a tier (opus / sonnet / haiku / free), and a clear role. Tier matters because Opus costs about 12 times more than Haiku. Sending every request to Opus is like using your most expensive server for every tiny task, no matter how simple.

Routes

Each route says: which agent sends, which agent receives, when it fires (on success, on failure, or on a match), and how many retries are allowed. This is your routing table. Without it, agents just follow prompt words that get read differently each time.

QoS Budget Classes

Network engineers sort traffic into QoS classes: realtime (voice), interactive (web), background (file transfer). Each class gets a different priority. AI works the same way. A customer chat reply is realtime. A nightly report is background. Each class gets its own budget, its own timeout, and its own fallback plan.

TTL (Time-to-Live) Limits

In IP networking, every packet carries a TTL number. It counts down by one at each hop. When it hits zero, the packet is dropped. This stops loops from eating up the whole network. The same idea works for agents: max_spawn_depth controls how deep the agent tree can go, and max_iterations controls how many retries one agent can make. Without TTL, a runaway loop is just a matter of time.

Congestion Control

What happens when the system gets too busy? Networks have proven fixes: exponential backoff, circuit breakers, load shedding. Most multi-agent systems use none of these. The Designer suggests specific patterns: rate-limit each agent, open a circuit breaker after N failures in a row, and define a graceful fallback path.

Graphviz DOT Diagram

The output includes a valid Graphviz DOT spec. Paste it into GraphvizOnline and it draws your architecture as a real diagram. This is the kind of deliverable a senior architect brings to a design review.

Why a Diagram Beats a Prose Description

A workflow written as prose can be read many different ways. A workflow shown as a directed graph with labeled nodes and labeled edges is clear. The diagram is the spec. When you give it to another engineer, you are not asking them to guess what you meant. You are giving them an architecture they can act on.

From a wiki synthesis I built mapping networking concepts to AI: "Your layered architecture (hooks → routing → agents → tools) IS the OSI model. routing_monitor_hook.py = routing table. SINC-2 = application layer protocol. Spawn depth limits = TTL. Budget pools = QoS classes."

Try It on a Workflow You Are About to Build

Describe a multi-agent system you are planning, even in rough terms. The Designer returns a structured topology and a diagram. You will see right away whether your design has clean QoS separation, defined routing, TTL limits, and congestion control, or whether you were about to ship a mess.

For production systems where the topology must actually run, with monitoring on every route, observability on every agent, and circuit breakers tied to alerts, see the paid service. The patterns are reusable. The deployment is built for your setup.