M×N protocol calculator

What is the M×N integration problem?

The M×N integration problem is the multiplication you get when every one of M agents needs its own hand-written connection to every one of N systems: the number of adapters is the product, and each new agent or system adds a whole row or column of work. A shared protocol replaces the product with a sum, because each side implements one contract once.

Chapter 6 of the book opens its protocol section with the count. Three agents in production, five systems they need to reach, and “each connection is a hand-written adapter: parse this system’s API, translate it into this agent’s tool format, handle its authentication, its pagination, its errors.” Multiply, and the answer is “on the order of fifteen.” The calculator above runs the same count on your numbers, redraws both wiring diagrams, and prices the next addition.

How does a protocol turn a multiplication into an addition?

A protocol turns the multiplication into an addition by putting one agreed contract between the two sides, so that an agent no longer needs to know anything about a particular system, only how to speak the contract. The chapter states the result in a sentence: “Each system implements the standard once; each agent speaks it once; the count collapses from a multiplication, M×N, to an addition, M+N.”

On the book’s example, that is fifteen adapters against eight implementations. The figure’s caption gives both numbers: “the same reach costs eight implementations, and an addition costs one.”

The book is careful about what a protocol is, since the word gets waved around. “A protocol is an agreement about how two independently written programs talk: the message shapes, the sequence of exchanges, the promises both sides keep.” For agents, what gets standardized is everything around the model’s request to call a function: “how a capability describes itself, how an agent discovers it, how it is invoked and answered across a process or network boundary.”

The idea is older than agents. The chapter calls it “the same one that saved hardware, networking, and the web before us”. Editor tooling went through the same arithmetic when every editor needed its own support for every programming language, and one shared protocol between editors and language tools removed the product. That example is this page’s, not the book’s.

What does each new agent or system cost?

Wired directly, each new system costs one adapter per agent and each new agent costs one adapter per system; with a shared contract, either one costs a single implementation. The chapter gives the two numbers for its example: “Add a sixth system and you owe three new adapters; add a fourth agent and you owe five”.

	Wired directly	One shared contract
Three agents, five systems	15 adapters	8 implementations
Add a sixth system	3 more	1 more
Add a fourth agent	5 more	1 more
One system changes its interface	3 adapters to fix	1 implementation to fix

The last row is the tool’s, derived from a clause in the same paragraph: “every adapter you already own is a living liability that breaks when either of its ends changes.” Building is a one-time cost. Keeping fifteen adapters working while eight things on their far ends keep changing is the cost that recurs, and it scales with the same product.

The chapter makes the payoff concrete for one connector: build it once, and every protocol-speaking agent can use it, “which is the difference between an integration that costs an afternoon and one that costs a sprint per agent, forever.”

One assumption in the count deserves a flag. The product assumes every agent connects to every system, and the chapter says only that “Every agent needs most of the systems.” The calculator has a field for the share of pairs that need connecting. Lower it and the hand-wired count falls, though never below the larger of M and N, since every agent and every system is still reached once. The protocol count stays at M+N. Sparse wiring is one of the cases where the multiplication is smaller than it looks.

When is a direct API call still the right choice?

A direct call is still the right choice when there is a single tightly coupled integration that you control at both ends, because then there is nothing to multiply and the protocol only adds a layer. The chapter says so without hedging: “For one tightly coupled integration you fully control, a direct API call is simpler, faster, and easier to debug; protocols earn their ceremony with many connections and third-party reuse”.

The arithmetic agrees at small sizes. One agent and one system is one adapter by hand and two implementations through a contract. One agent and six systems is six against seven. Two and two is four against four. The product pulls ahead once both sides have at least two members and one of them has three.

The calculator turns that sentence into a reading with three outcomes, and the thresholds are its own, not the book’s. It asks who owns the ends, because “you fully control” is half of the chapter’s condition:

• The count favors a protocol whenever the product exceeds the sum, whoever owns the ends.
• A direct call is simpler when the hand-wired count is no larger than the protocol count and one team owns both ends of every connection.
• The count does not favor a protocol when the numbers are that small but another team or a third party owns an end. The chapter’s condition for a direct call does not hold then, and the count gives no reason for a protocol either. The result says what would tip it: others reusing the connector, or a third party that already publishes one.

It also checks the additions you plan. If the count is even today and tips after the next agent and system arrive, the result says so. The book’s general rule for this kind of decision applies: “the simplest thing that works, upgraded on evidence.”

What does the count leave out?

The count leaves out everything that makes a protocol expensive, which the chapter collects in what it calls the honest ledger: “protocol adoption is an engineering decision and not a sacrament.” Three costs are current and one is unlike the others.

The standards are young. Specifications revise and authorization stories mature unevenly. The chapter quotes a member of one protocol team saying the specification was early and that “this is NOT done.” The advice that follows is short: “Version your integrations and expect breakage.”

The far end drifts. “a protocol is a moving contract, and the far end moves without asking you.” A server changes its tools; a capability advertisement goes stale. An agent should degrade gracefully when a tool disappears from the menu.

A generic interface costs specifics. A standard built for everyone “flattens capabilities toward a lowest common denominator, hides useful specifics behind a schema built for everyone, and inserts indirection you may not need.”

Trust does not come with the plug. This is the cost the chapter sets apart. “Standardizing the interface does not standardize the trustworthiness of what is behind it; it lowers the cost of connecting to a stranger to one configuration line, and strangers have noticed.” The compressed form is the one to carry: “every socket is a door.” The tool contract linter checks the descriptions a server exposes before your model reads them, and the lethal trifecta audit checks what the agent could do with them.

The count also treats an adapter and an implementation as the same size of work, and they are not. Eight is fewer pieces than fifteen. Whether it is less effort depends on how heavy the contract is and how well it fits what your systems do.

Which kind of protocol do you need?

You need a tool protocol when the far end executes and an agent protocol when the far end reasons. The chapter draws the line by “what stands at the far end of the wire”, and says the choice “is usually not subtle.”

A tool protocol connects an agent to tools and data. A server wraps a database or a ticket tracker and advertises what it offers; a client inside the agent application asks what is on the menu and calls it on the model’s behalf. The book’s labeled example of the category is the Model Context Protocol, which it asks the reader to take “as one instance of a category that will keep evolving.”

An agent protocol connects an agent to another agent. “When your agent calls a tool, it holds the reasoning and the far end holds a function”. When the far end takes a goal, works for a while and makes its own choices, a single call that must answer now is the wrong container. The book’s labeled example here is Agent2Agent, and the defining ideas are a published capability advertisement, a task with its own lifecycle, and results returned from a counterpart that stays a black box.

The chapter’s rule of choice fits in two sentences. “If the far end is a capability (data to fetch, an action to perform, deterministic machinery), you want a tool protocol”. And if it “reasons, plans, and owns its own method, especially if another team or vendor owns it, you want an agent protocol and a well-written brief.” The two kinds combine in one system without conflict.

Whichever kind you pick, the craft of what you expose still matters more than the wire. Idempotent tools and safe retries covers one part of that craft, the guide to tools and protocols places protocols next to skills and tool design, and the full section, with the comparison of skills, tools and protocols that precedes it, is in Chapter 6, Skills, Protocols, and Interoperability (in the full book).