Skip to main content
Think of the drawer full of chargers and cables at home. You probably own several different types, and the exact one you need is seldom where you expect it. For many years, AI integrations produced the same kind of clutter: lots of bespoke connectors, duplicated effort, and growing maintenance costs.

​
The core problem: N agents × M tools

On one side you have AI assistants or agents — call that count N. On the other side you have the internal systems those agents must interact with (GitHub, Jira, Postgres, Slack, etc.) — call that count M. Without a shared integration standard, engineers build direct, custom connectors for every agent-tool pair. Each connector must implement authentication, map data to/from the tool’s API, and handle retries and errors. Even when two agents integrate with the same service, they often implement that integration independently.
A man stands beside a glowing lightboard holding a marker. The board shows three green boxes labeled A1–A3 connected by lines to four yellow boxes labeled GH, Jira, PostG, and Slack, with "N x M" and the number 12 written.
This direct-pairing model produces N × M custom integrations to build and maintain. For example:
  • With 3 agents and 4 tools: 3 × 4 = 12 connectors.
  • With 50 agents and 10 tools: 50 × 10 = 500 connectors.
Each additional agent adds M connectors; each new tool adds N connectors. At scale that quickly becomes unsustainable.

​
Why this is costly

  • Duplication of effort across teams.
  • Inconsistent authentication and error semantics.
  • Fragmented maintenance: bug fixes and feature changes must be applied across many connectors.
  • Slower onboarding for new agents or tools.

​
The maintainable alternative: a shared standard and adapters

A far more maintainable approach is to introduce a shared integration standard between agents and tools. Each agent implements a client-side adapter for that standard, and each tool implements a server-side adapter. Instead of N × M pairings, you build N client adapters plus M tool adapters — a total of N + M implementations. That dramatically reduces integration surface area and simplifies cross-team coordination.
A presenter gestures next to a glowing lightboard diagram. The board shows three apps (A1, A2, A3) wired to services like GH, Jira, PostG and Slack, with a simplified consolidated "S" architecture on the right.
This is analogous to how USB-C standardized hardware power and data connections: both sides agree on a single protocol so you don’t need a different charger for every device. In software, a shared protocol centralizes responsibilities (authentication flows, data serialization, error semantics) and moves them into the standard and its adapters, reducing duplication.

​
MCP: the shared standard for AI integrations

For AI applications and tools, the shared standard often used is MCP. When hosts, clients, and servers adopt MCP, the architecture becomes modular: defined adapters handle the integration boundaries, and the standard ensures consistent behavior across the ecosystem.
Using a shared standard like MCP converts the integration problem from O(N×M) work to O(N+M). That reduces long-term maintenance, accelerates onboarding, and makes security and observability consistent across integrations.
Key responsibilities for each adapter typically include:
  • Authentication and authorization flows for the specific tool or agent.
  • Data serialization and mapping between the standard’s contract and the tool’s API.
  • Error semantics, retries, and observability (logging/metrics/tracing).
  • Security controls and permission checks at the integration boundary.
Without a standard, teams accumulate technical debt: duplicated connectors, inconsistent behavior, and an exploding maintenance burden. Introducing a well-defined adapter pattern early avoids costly refactors later.

Watch Video