Main idea

There is a precedent: as long as SaaS products lived in isolation, they competed on the richness of their features. The day they had to coexist inside one organization, the API became the criterion that eliminates — a tool without an API, however good, loses more in re-keying than it gains in functionality.

The same tipping point is playing out again with agents. A tool whose agent sees only its own data produces outputs consistent with one face of reality and false on the rest. A context-exchange protocol — MCP being its emerging form — lets Figma go and read the recent changes in a GitLab repository, understand the relevant merge requests, and align the design with what the product has become.

Each tool's specialty does not disappear; it stops being what decides. What decides becomes the ability to pull context elsewhere and to act within a perimeter larger than its own.

Why it matters

It gives a tool-selection criterion that comes before use: assess what a tool can read outside itself, before assessing what it can do. The criterion has already proved its predictive value once, with APIs.

It also says what happens to established positions. A tool dominant through its functional perimeter becomes vulnerable as soon as the comparison bears on openness.

Nuances and limits

The analogy with APIs has a weakness: an API exposes data whose format is known and stable, a context-exchange protocol exposes material that a model interprets. Openness therefore does not guarantee that what is pulled is understood.

And the movement is not finished. The mechanism is visible in its direction, not in its final balance, and nothing guarantees that the protocol that prevails will be that one.

Open questions

• What decides, within an organization, which tool becomes the one that pulls and which becomes the one that supplies?