The company whose model runs your customer-facing agent is one product launch away from being your competitor, and it will enter your category with a head start you handed it. The frontier labs have stopped being pure model suppliers. Every one of them now ships vertical products, coding agents first, and the pattern is already visible in that category. Tools built on a lab's model watched the same lab launch its own version, and the ones that survived moved to open models to get out from under a supplier that had become a rival. That's a startup story today. The enterprise version is quieter and worse, because the lab doesn't need to beat you at your business. It needs to learn your workflow from your usage, package it, and sell it to your customers and your competitors at once. We call the supplier that can do this the upstream competitor, and most companies have one and haven't named it.
What is an upstream competitor?
It's a supplier positioned above you in the stack who can enter your market using what it learned from supplying you.
Every business has suppliers. Few suppliers can watch exactly how you use what they sell, in enough detail to replicate it. A model vendor can. When your agent runs on a lab's API or inside a lab's harness, the lab sees the prompts, the tool calls, the corrections, and the outcomes, which is the complete recipe for the workflow you built. We've written about this exposure as a learning problem in the learning ledger, where the know-how from your deployment accrues to the vendor's balance sheet. The upstream competitor is the same exposure read as a competitive one. The ledger says the vendor banks your learning. The upstream competitor says the vendor can spend it, in your category, against you.
Hasn't this always been true of platforms?
Yes, and the difference now is speed. A platform used to need years to notice a category and build into it. A lab needs a quarter, because it already has the product in its usage data.
The old version of this risk had a name in every industry. The cloud provider that launched a managed version of the open-source tool its customers were running. The marketplace that launched a house brand in the category its sellers made popular. Those moves took time, because the platform had to study the category from the outside. A model vendor doesn't study from the outside. The vertical product it ships is, in large part, the aggregate of what its customers already built on top of it, and the use cases that show up most in a lab's traffic are the obvious candidates for its next launch. If your agent is one of the heaviest users of a model in a given workflow, you're not a customer the lab wants to keep. You're a market the lab has already sized.
Where does the exposure actually sit?
In the usage data and the harness, which is also where you've probably put the least thought.
Three things make a company legible to its upstream supplier. The first is raw volume, because a workflow that generates heavy traffic is a workflow the lab can see is worth building. The second is the harness. If your agent runs inside the lab's own tooling, the lab holds the configuration, the memory, and the corrections, which is the argument we made in the open-weight alibi, and it holds them in a form that's trivially productizable. The third is the data path. A direct API call under an enterprise contract with zero retention is one exposure. The same workflow routed through a consumer-grade tool, or through an aggregator the lab can observe, is another, which is why the second hop matters here too. Most companies have audited none of the three, because they evaluated the model as a supplier and never as a potential entrant.
Isn't the answer just a better contract?
A contract limits what the lab can do with your data. It does nothing about what the lab can do with your category.
Zero-retention terms and training exclusions are worth having, and you should have them. They don't address the problem, because the upstream competitor doesn't need your data specifically. It needs to know that the category exists, that it's valuable, and roughly what the workflow looks like, and it learns all three from aggregate patterns no contract covers. Your traffic contributes to a picture the lab assembles from everyone's traffic, and the product it ships is built from the picture, not from you. This is a cousin of the crossfire clause, where your access ends over a fight between other companies. Here your advantage ends over a product decision at your supplier, and no clause you can negotiate reaches a decision like that.
What does a defensible position look like?
A workflow the lab can't see in enough detail to copy, running on a model the lab doesn't control, with the learning accruing on your side.
The move is the one we keep recommending, and the upstream competitor is the sharpest reason yet to make it. Put the model socket between your workflow and every lab, so the lab sees a stream of requests and never the orchestration that makes them valuable. Keep the harness, the memory, and the corrections on your side of that boundary, so the recipe lives with you. For the workflows that are closest to your core, run an open model you hold, because a model nobody else serves is a model nobody else learns from. And treat the lab's vertical product roadmap as competitive intelligence, which means reading the launches in your category the way you'd read a rival's. None of this stops the lab from entering your market. It stops the lab from entering with your recipe.
What should you do about the upstream competitor?
The question you're really asking is which of your AI workflows a supplier could ship as a product, and the answer is any workflow where the supplier can see the whole loop.
Take your three highest-volume agent workflows. For each, answer two things. Could the model vendor, from what it observes, reconstruct what this workflow does and why it's valuable. And if the vendor shipped it next quarter as a feature, would the business notice. Where both answers are yes, you've found an upstream competitor and a workflow worth moving behind a boundary you own. Start there. Move the orchestration and the corrections to your side first, because that's what makes the workflow copyable, and switch the model second, because that's what makes it visible. The lab will keep shipping products. The goal is that when it ships one in your category, the version it built from the outside is a generation behind the one you've been running on the inside.
If you want your core workflows moved behind a boundary your supplier can't see through, start with an AI Blueprint or reach us at contact@theyor.com