The N×M problem is eating agent teams alive

Every team that ships an AI agent arrives at the same wall, usually in month two. The demo worked. The agent could read a calendar and post to Slack. Then someone asked for a second agent, and a third integration, and the arithmetic turned hostile.

The arithmetic

Call it N agents and M tools. A support bot, a sales bot and an on-call copilot each need roughly twenty integrations. That is not twenty pieces of work. It is sixty, because each agent holds its own client, its own credentials and its own error handling for the same twenty APIs.

• Each integration needs an auth flow, and each auth flow needs a place to store a secret.
• Each secret needs a rotation story, and rotation multiplies by the number of places the secret was copied.
• Each API changes on its own schedule, and none of those schedules are yours.

The failure is not that any single integration is hard. It is that the cost is multiplicative and the maintenance never ends.

Why per-service MCP servers only move the problem

The Model Context Protocol solved a real thing: it gave tools a standard shape, so any compliant client can call any compliant server. That is genuine progress.

But the common deployment pattern, one MCP server per service, each configured separately in each client, reproduces the N×M problem with better ergonomics. You still register twenty servers in three clients. You still put twenty sets of credentials on every machine that runs an agent. You have standardised the interface without collapsing the fan-out.

What a gateway changes

Put one server in front of everything and the shape changes from multiplication to addition:

Before:  3 agents × 20 services = 60 configurations
After:   3 agents + 20 services = 23 configurations

The agent side becomes trivial: one URL, one key. The service side is done once and shared. Adding the fourth agent costs one key, not twenty integrations.

The parts that are actually hard

A gateway is easy to describe and unpleasant to build, which is most of why they are rare:

Credential isolation

The gateway holds real provider secrets for every connected account. That demands envelope encryption, per-tenant keys, and a design where plaintext exists only in memory during an outbound call. Get this wrong and you have built a single point of catastrophe.

Tool discovery at scale

Twenty-five thousand tool definitions is somewhere north of two million tokens. You cannot send that. You cannot send a tenth of it. The gateway has to rank tools against the task and expose a working set, which means the discovery layer is as important as the connectors themselves.

Schema drift

Vendors deprecate fields. Versions move. A gateway that fronts 1,500 APIs is signing up to absorb that churn centrally, forever, so that it never reaches the agent.

The test

The useful question for any integration architecture is: what does the fourth agent cost?

If the answer involves re-running twenty OAuth flows and copying secrets onto another machine, the architecture multiplies. If the answer is one command, it adds. Only one of those survives contact with a real roadmap.