When an API provider starts sending recommendations directly to your users, the dependency has moved beyond infrastructure and into distribution. The founder must decide whether the product still owns the customer relationship, and what remains defensible if the provider can reach the same person first.
Consider Kojo, an invented composite of founders I have worked alongside. At 8:17 on a Tuesday morning in Accra, he was standing beside his kitchen counter, waiting for the kettle, when a customer forwarded him an email with one line above it: “Should we use this instead?”
The email came from the model provider behind Kojo’s AI research agent. It recommended a new workflow that overlapped with the agent’s most useful feature. The provider already had the customer’s address through a separate account and could now explain the workflow without Kojo’s interface, onboarding or brand.
A renewal conversation was due that week. If the customer concluded that the provider could do enough on its own, Kojo would lose the account and the reference he needed for two deals still under review.
The kettle clicked off. He left it untouched.
The dependency had acquired a voice
Kojo had always known the provider could change its model, pricing or rate limits. Those risks lived in his technical planning. He had fallback prompts, usage alerts and a rough estimate of what migration would cost.
He had not planned for the provider to become a participant in the customer relationship.
That distinction matters. An API can sit behind your product for months while remaining invisible to the buyer. Once its owner begins teaching, recommending and selling directly to the same people, the dependency gains a voice. It can shape what customers believe they need before your product gets a chance to frame the problem.
The immediate temptation is to call this unfair and start planning a migration. That would have given Kojo movement, but little protection. Another provider could make the same decision later. Replacing the supplier would change the name beneath the product while leaving the strategic weakness in place.
The harder question was simpler: why had the customer hired Kojo’s agent rather than opening the provider’s tool directly?
His first answer was convenience. He crossed it out.
Convenience lasts until the underlying provider makes the same task easy.
The renewal call exposed the real product
Kojo joined the renewal call expecting a comparison between two interfaces. The customer had the provider’s email open in another tab and asked whether Kojo’s agent still justified a separate subscription.
For a few seconds, the account could have gone either way.
Kojo stopped defending the feature. He asked the customer to describe the last piece of work they had completed with the agent. The answer changed the conversation. The customer had used it to collect scattered research, apply an internal review sequence and produce a decision note in the format their team already used.
The model generated text. Kojo’s product carried the work through a specific company decision.
That was the turn.
He opened the workflow history and showed where the customer’s review rules, source preferences and approval steps lived. Recreating those inside a general provider tool was possible, but the customer would have to own the setup, testing and maintenance. Kojo’s value sat in the decisions around the model: what entered the process, what required human review and what counted as finished.
The customer renewed. More importantly, Kojo left the call with a narrower definition of what he was building.
This resembles the pressure in What Should You Do When the API Will Miss a Customer’s Renewal Deadline?. In both cases, a provider’s decision becomes your customer’s problem. Your architecture may be sound while your commercial position remains exposed.
Build around decisions the provider cannot see
After the call, Kojo reviewed every step between the customer’s request and the final output. He marked which parts came from the provider and which depended on knowledge the provider did not have.
The model call was replaceable. The customer’s approval rules were specific. The record of why one source had been accepted and another rejected mattered during review. The final handoff had to fit an existing team process. Those details were less impressive in a demo, yet they carried the renewal.
This audit also revealed weak areas. One workflow amounted to a prompt wrapped in a cleaner screen. If the provider promoted the same capability directly, Kojo had no strong reason to charge for it. He removed that workflow from the centre of his sales conversation and stopped allocating roadmap time to cosmetic improvements around it.
Provider abstraction still mattered, but it solved only part of the risk. A second API could protect continuity. It could not create customer value.
The stronger defence came from owning context, judgment and completion. Context meant understanding the customer’s actual constraints. Judgment meant encoding choices the customer did not want to revisit on every task. Completion meant carrying the work into the place where a colleague could approve, reject or act on it.
Run the provider-email test before it arrives
There is a useful test for any AI product built on someone else’s model: imagine the provider emails your best customer on Tuesday morning and recommends its own version of your main feature.
What does your customer still need from you on Tuesday afternoon?
Write the answer without using “better experience,” “easier” or “more tailored.” Name the decision your product helps make, the customer knowledge required and the final action it completes. If the answer reduces to interface preference, the provider already controls too much of the value.
Kojo ended that Tuesday with one renewal and a shorter roadmap. On Wednesday morning, his tea went cold again, this time beside a document titled “What remains when the model is free.”
Comments
No comments yet.