The same decision — exposing your capabilities as callable tools — produces opposite outcomes for different companies. Some find their reach multiplied: they get used in workflows they were never part of, by people who would never have opened their application. Others find themselves reduced to an endpoint that a competitor can replace on a Tuesday. The sorting is not random and it is not about execution quality. It comes down to whether anything about your product survives the removal of its interface. Here are four tests that answer that, and they are more uncomfortable than they look.
Test one: does the write have to pass through you?
Not the read — the write. When the agent changes something that matters, does the change have to go through your system to be real, and does your system impose rules on it that nobody else can impose?
If you are where the authoritative state lives, and your invariants are what make a change valid, then an agent calling you is not bypassing you. It is submitting to you. Every tool call reinforces your position because the record is the thing being changed, and you own the record. If, on the other hand, you are a convenient place to view and edit state that is authoritative somewhere else, being callable makes you an optional stop on a route that has other paths.
Test two: could your data be reconstructed without you?
Almost every incumbent believes its data is a moat. Most are describing volume rather than defensibility. The question is not how much data you hold; it is whether a competent competitor could assemble something functionally equivalent from public sources, from the customer’s own systems, or from a few integrations.
Data that customers gave you because your product was the convenient place to put it will follow them when the convenient place changes. Data that only exists because of your position — a multi-party history, a proprietary observation, an accumulated corpus of confirmed decisions with names attached — does not. The uncomfortable version of this test: if your largest customer left, how much of what you know about their domain would you keep?
Test three: is there a network on your side of the boundary?
A capability serves one customer. A network serves a customer because of all the others. If your value depends on counterparties — other institutions on the same rails, a marketplace, a shared reference set, a settlement path — then calling you is the only way to reach them, and the protocol simply widens the door.
Single-tenant capability, however sophisticated, has no such protection. This is the test that most cleanly separates products that look similar from the outside and behave completely differently once the interface stops mattering.
Test four: who carries the accountability?
When the action goes wrong — a wrong payment, a bad filing, an incorrect eligibility decision — whose name is on it? Accountability is the one thing a harness is structurally reluctant to absorb, and in regulated work it is frequently the thing a regulator will not let it absorb.
If your product is the place where a named human confirmed a decision, where an auditor can replay what happened and why, and where liability actually sits, then you hold something the orchestration layer does not want and cannot easily take. That is not a feature. It is a position.
What false comfort sounds like
Three answers come up constantly in these conversations and none of them is a moat.
“We’re mission critical.” So is the database underneath you, and nobody negotiates with it. Criticality without exclusivity just means the replacement project is carefully planned rather than abandoned.
“We have deep domain expertise.” If that expertise lives in your interface — in the sensible defaults, the good workflow, the way the screen guides someone through a complex process — then it is exactly what the tool call leaves behind. Expertise only survives if it is encoded in something the call has to pass through: the validation, the rules, the record.
“Our customers would never switch.” They would not have switched when switching meant a migration project. The whole point of a protocol is that it stops meaning that.
Reading your own result
Very few companies are purely one thing. The useful output of these tests is not a verdict but a map: which parts of the product are substrate and which parts are façade. Almost always the substrate is a smaller and less glamorous share than the org chart implies, and the façade is where most of the engineering headcount has been going for years.
That map is the input to everything strategic that follows. It tells you which capabilities to expose enthusiastically — because exposure multiplies them — and which to stop treating as differentiators, because the market is about to stop paying for them. Getting this map honestly is worth more than any amount of debate about the protocol itself.
The next post takes the map and turns it into a plan.
When Your Product Becomes a Tool — a five-part series on MCP and incumbent strategy
- When Your Product Becomes a Tool
- What Dissolves When You Become Callable
- Substrate or Façade — Who Survives Being Called — you are here
- The Incumbent’s Playbook for an MCP World
- Buying in an MCP World
Related: The Substrate War — Will Your Data Platform Become Your System of Record? · The Model Is the Least Defensible Part of Your Agent.
Leave a Reply