The N×M Explosion

Part of the free Generative AI course on LogicWiz, module: Nova Joins the Network.

Episode 32: The N×M Explosion

"Add the Stripe tool to all our agents," Anjali said. Arjun opened his laptop, counted the agents, counted the tools, and felt his stomach drop. It wasn't one change. It was forty.

Two Tools Was Easy. Two Hundred Isn't.

Last episode, one tool turned Nova from a frozen book into an agent with hands. The loop was clean: describe a tool, let the model call it, run it, feed the result back.

Then reality arrived. A real support assistant doesn't need one tool — it needs to look up tickets, search docs, check orders, issue refunds, and escalate to a human. And Nova isn't the only agent: there's a billing agent, a research agent, an onboarding agent. Each one needs its own set of tools.

The instinct is to keep doing what worked: wire each agent directly to each tool it needs. That instinct is a trap, and this episode is about why.

Binding: The Wire Between an Agent and a Tool

Binding is just the act of connecting an agent to a tool it's allowed to use — giving the agent the tool's description, its arguments, and whatever it takes to actually call it.

For an internal tool (a function in your own codebase), binding is cheap: you own the code, so you just hand the agent the description. For an external tool (a payment API, a Salesforce integration, a search service), binding is heavier — each one needs:

  • Authentication — a token or key that proves this agent is allowed to call that service.
  • Connection details — the address, the protocol, the exact request shape.

So a "binding" isn't one line — it's a small bundle of description + auth + connection, per agent, per tool. Hold that thought.

Do the Math: A × T

Here's the part that surprises everyone. If you have A agents and T tools, and each agent can use each tool, direct binding needs A × T separate connections — because every agent must be wired to every tool individually.

Play with it. Add agents. Add tools. Watch the wires:

{{visual:connection-explosion}}

Ten agents and ten tools isn't twenty connections. It's one hundred — a hundred bundles of description, auth, and connection details, each one built and maintained by hand. This is called tight coupling: every agent is bolted directly to every tool, and the number of bolts grows by multiplication.

📌 The number to remember: direct binding scales as A × T. That "×" is the whole problem. Double your tools and you double your connections — across every agent.

Why the Web Rots

A hundred connections wouldn't be so bad if they sat still. They don't. Tools change: a parameter is renamed, an auth method is upgraded, a security policy tightens. And with direct binding, there is no central place to make that change — so it has to be propagated by hand to every agent that uses the tool.

That creates three slow-burning problems:

  • Addition/deletion overhead. Every new tool must be wired into every agent that needs it — and every retired tool un-wired from all of them. One change becomes N changes.
  • Maintenance burden. If ten teams each use the same tool, all ten must independently update their agents when that tool changes. Nobody can evolve the toolset or the agent fleet on its own.
  • Configuration drift. Because updates are manual, they arrive unevenly. Agent A gets the new auth; Agent B is still on the old one. Now different agents use different versions of the "same" tool, and things break in ways nobody can reproduce.

⚠️ The real killer isn't the number of connections — it's that there's no central control plane. Without one place to define and update a tool, every change ripples outward by hand, and the ripples never quite line up.

The One Thing Direct Binding Gets Right

To be fair, tight coupling has a genuine virtue: it's easy to debug. When something breaks, the path is short and explicit — Agent A called Tool T, and here's the exact wire between them. There are no abstraction layers to peer through, so root-causing a failure is straightforward: it's either the agent's logic or the tool's interface, and you can see both.

That's why for a small, stable setup — a couple of agents, a handful of tools that rarely change — direct binding is often the right call. The trouble is only what happens as you grow.

So the goal writes itself: find a way to manage all these connections from one central place, so a change to a tool is made once and every agent sees it automatically — without giving up too much of that debuggability. That one idea is the reason MCP exists.

What Nova Learns Next

We've named the enemy: A × T, propagated by hand, drifting out of sync. In Episode 33, we introduce the fix — a single server that sits between every agent and every tool, and turns that multiplication back into addition.