Saurabh Lahoti is the founder of GTMDialogues, helping early-stage B2B startups scale with sharper GTM strategy, inbound marketing, and founder-led storytelling.
OpenAI, Anthropic, and Google are not just model providers. They are product companies with sales teams, enterprise contracts, and roadmaps that extend directly into the markets their API customers are building in.
If your product sits on their infrastructure without a structural moat of your own, you are not just a customer. You are a competitor they have not prioritised yet.
Joe Schmidt at a16z calls it the Yellow Brick Road: the path the labs are committing extraordinary resources to, covering code generation, writing, document processing, and horizontal AI tools. If your product lives on that road, the labs are already building what replaces you.
The founders who last will be the ones who own the system of work, the surface where a customer's work actually runs. The model is fungible underneath. The system of work is not.
This article is a structured way to think through which one you are building.
There is a version of an AI product that looks compelling from the outside and is quietly fragile on the inside. It wraps a capable model, connects to a few standard tools, and produces outputs that impress in a demo. What it doesn't have is structural separation from what a foundation model lab could ship with a single product update.
The labs are best suited for problems that improve with raw model capability: code generation, writing, image creation.
If your product is essentially one of those tasks with a layer of configuration on top, your competitive position narrows every time a new model ships. The move that changes this is going deep into a specific vertical, a specific workflow, and a specific set of problems that only compound when you stay close to them.
The strongest AI application companies pick one industry or function and build for its specific workflows, edge cases, and regulatory demands. Consider the difference between an "AI assistant for businesses" and an "AI underwriting assistant for mid-market commercial insurance carriers."
The first competes on the same ground as every horizontal AI product a foundation model lab ships. The second competes on terrain that requires deep insurance-specific knowledge, carrier appetite rules, and regulatory context that no general-purpose product is built to handle.
Vertical AI enters the workflow with pre-loaded domain knowledge that a generalist model would have to acquire from scratch. Every task and edge case handled makes the next decision better, and makes the gap harder to close.
Breadth works against when every feature you build to serve a second vertical is a feature you didn't build to go deeper in your first one.
There is a meaningful structural difference between a system and a tool. A system is what the customer's team uses to actually run their work, handling data capture, approvals, governance, and audit records. A tool sits on top of a workflow the customer already owns elsewhere.
The honest test happens when a major AI lab launches a directly competing product next month, would your customers have a genuine reason to stay? A legal AI that owns the full contract review process, from intake and redlines through escalation rules, partner sign-off, and audit log, is a system.
A plugin that highlights risky clauses in a document editor is a tool. Companies sitting alongside the work find their switching costs were lower than they appeared; companies sitting inside it find the opposite.
Horizontal AI platforms handle simple, forgiving, single-step tasks well. That is their advantage, but your target should be the opposite: workflows with many steps, messy inputs, multiple people approving at different stages, and where being wrong has real consequences.
An insurance submission workflow that pulls data from five sources, routes to an underwriter for an appetite check, escalates for outlier risks, and logs every decision with its rationale is not one-shot AI.
The more steps and decision gates involved, the harder it is for a general-purpose AI to replicate what you have built. Complexity is the foundation of your position.
Most founders building at the application layer believe they have a data advantage. Very few have actually built one. There is a difference between data you collect and data that makes your system measurably better with every cycle. The first is a byproduct. The second is a moat.
The strategic question in 2026 is not how much data you have. It is what your system learns from that data, and how quickly that learning compounds into something a new entrant cannot replicate from day one.
Foundation model labs train on everything publicly available. What they cannot train on is the judgment that comes from reviewing 10,000 mid-market insurance submissions, the claims logic built from years of carrier-specific edge cases, or the intake patterns that predict which legal matters will escalate.
That knowledge exists in the workflow, and only a product embedded deeply enough in it can accumulate it. According to The Strategy Stack, companies that started building this kind of data position in 2024 are already 18 to 24 months ahead of those starting now, and the gap widens with every cycle.
The instinct in many early-stage AI products is to minimise the number of times a human overrides the system. That instinct is wrong. Every override is a labeled example that no foundation model lab can generate from a public dataset:
As The Strategy Stack notes, the most defensible data moats are built from feedback loops that improve inference quality faster than any competitor can replicate. What you ship at launch is not the product that wins.
The compounding effect of a well-built data flywheel is not linear. As Menlo Ventures describes it: an agent ingests domain-specific data, develops judgment a general-purpose model cannot match, earns trust to go deeper into live workflows, and generates correction signals that improve the system further with every cycle.
The companies hardest to displace are those whose product sees across customers. A permit-processing platform that has handled filings across hundreds of municipalities learns which documentation sequences clear fastest in each jurisdiction.
That knowledge exists nowhere else. As a16z notes, it is precisely this compounding that makes the system of work non-fungible even as the underlying models change.
There is a contractual prerequisite most founders overlook until it is too late. If your customer agreements do not explicitly grant you the right to use workflow data for model improvement, you do not have a flywheel. You have a data collection problem waiting to surface at your next enterprise renewal.
Getting this right early means being explicit about:
Enterprise customers in regulated industries will ask all three. Having a clear, defensible answer is not just a legal necessity. It is a signal that you are serious about the system you are building, and it is often the difference between a customer who trusts you with their most sensitive workflows and one who keeps you at arm's length.
Most AI application companies are single-vendor by default. They picked the model that worked best at the time they built, and never revisited the decision. That is a pricing and availability risk dressed up as a technical choice.
The model layer is commoditising fast. Token prices fell roughly 80% between 2025 and 2026 even as usage exploded, according to Digital Applied's 2026 inference cost analysis. The companies that capture those gains are the ones with a routing layer ready to adopt every new cheaper or more capable model the moment it ships. Single-vendor products absorb price increases and capability gaps with no structural way to respond.
When you build your product around one provider's API, that provider sets your floor. Every price increase flows directly to your cost structure. Every capability gap in their model becomes a capability gap in your product. And when a better model ships from a competitor, your customers notice before you can do anything about it.
As a16z notes, the model is fungible underneath the system of work. The practical implication is that the model layer should be treated as infrastructure, not identity. Your product's value is not that it runs on a specific model. It is what your system does with the output.
Not every step in your workflow needs the most capable or most expensive model. A document classification step, a data extraction task, and a multi-step reasoning decision are three different problems that warrant three different models.
Running all of them through a frontier model because that is what you used in the demo is a unit economics problem that scales with every customer you add.
Tiered model routing — directing simpler tasks to smaller, cheaper models and reserving frontier capability for high-stakes reasoning would commonly deliver cost reductions of 40 to 70% without any degradation in output quality on the tasks that matter.
For an enterprise AI product running thousands of workflow cycles a day, that difference compounds directly into margin. The routing logic itself becomes part of your product architecture, and building it well is one of the few places where engineering investment pays off at the business level immediately.
Every time a new model ships, your enterprise customers face a choice: stay on what works or invest in migration and re-evaluation. In regulated industries, that migration cost is prohibitive. Most buyers will stay on an older, less capable model longer than is good for their outcomes simply because moving is too expensive.
When you own the routing layer, you absorb that work on their behalf. A better model ships, you evaluate it, you route the right tasks to it, and your customers see better outputs at their next renewal without having touched anything.
IDC projects that by 2028, 70% of top AI-driven enterprises will use multi-model architectures to manage routing across providers. The application companies that build this layer now become the integration point their customers depend on and not one of the vendors their customers have to manage.
Most AI companies treat governance as something you bolt on before a procurement review. In regulated industries, that order is wrong. Buyers in financial services, healthcare, insurance, and legal are not evaluating your AI capabilities in isolation. They are evaluating whether your product can live inside their compliance environment without creating new risk.
The founders who understand this build governance into the product architecture from day one, not as a feature, but as the layer that makes everything else deployable at enterprise scale.
72% of S&P 500 companies disclosed at least one material AI risk in 2025, yet only 26% have comprehensive AI governance policies in place. That gap is your product opportunity.
The most defensible position in the application stack is owning the governance layer are the permissions that determine what the AI can and cannot do, the audit trail that records every agent action, and the approval gates that keep humans in the loop on high-stakes outputs.
A product that owns this layer is infrastructure, and infrastructure does not get replaced at the next budget cycle.
According to Gartner 2026, organizations deploying AI governance platforms are 3.4 times more likely to achieve high governance effectiveness. The companies winning in regulated industries are the ones making that easy for their customers to achieve, not asking them to build it themselves.
The temptation when building guardrails is to create one configuration and apply it across your entire customer base, but that approach fails, and it fails in ways your most important customers might notice first.
A guardrail calibrated for a growth-stage SaaS company doing internal knowledge retrieval is not the right guardrail for a regulated bank supporting credit decisions. The risk tolerance is different, the regulatory exposure is different, and the consequences of a wrong AI output are different by orders of magnitude.
The teams shipping agents into regulated industries have moved past "we run guardrails" to "we run guardrails, audit logs, version-controlled policies, blast-radius gates, and a documented incident response process."
Per-customer, per-use-case calibration is the standard your enterprise customers are already expecting and building it into your architecture means you can walk into a procurement conversation with a bank, a hospital, or an insurer and show them exactly how their specific risk parameters are enforced, versioned, and audited, that is a different conversation than showing them a demo.
There is a structural difference between a vendor who says "we take security seriously" and one whose contract explicitly takes on regulatory compliance responsibility. The first is a claim. The second changes the nature of the relationship.
ISO 42001 certification is increasingly the evidence format enterprise buyers request, and NIST AI RMF 1.1, released in March 2026, has become the baseline for US federal procurement and enterprise vendor questionnaires.
If you sell to enterprises in regulated industries, you will be asked to demonstrate alignment with both. A clear answer moves you from the vendor list to the shortlist.
Contractually owning compliance also changes the economics of the relationship. A customer who has outsourced their AI compliance risk to you has a switching cost that goes well beyond the product itself.
Replacing you means re-evaluating compliance coverage, renegotiating contracts, and absorbing the risk gap in between. That is not a decision any procurement team makes lightly.
Everything in this article comes down to four honest questions, the ones you answer when the room is empty. Buyers and investors are now scrutinising data quality, governance, model dependencies, and pricing stability in ways they weren't eighteen months ago. The founders who are ready for those conversations have already asked themselves these questions and built the answers into their product.
Work through the full AI Application Layer Self-Assessment Checklist with your team.
The AI application layer sits between foundation model infrastructure and the end customer. It is where products are built on top of models and APIs provided by labs like Anthropic, OpenAI, and Google. It matters because those same labs have strong commercial incentives to build the application products themselves, as Joe Schmidt at a16z documents in detail. Founders at this layer need to understand what makes their position structurally defensible before that competition arrives.
A system owns data capture, approvals, governance, and audit records. A tool sits on top of those things that the customer manages elsewhere. The answer tells you more about your structural position than your revenue ever will.
For any AI application company competing on workflow quality, domain knowledge, and outcomes, vertical focus is the right structural move. The only exception is if you are building infrastructure that other application companies depend on, where breadth is by design. Every feature you build to serve a second vertical is a feature you did not build to go deeper in your first one.
It is when your system gets measurably better with every workflow cycle in a way a new entrant cannot replicate from day one. The most defensible moats come from capturing institutional knowledge that does not exist in any public training dataset and turning every human correction into a learning signal. Without data rights explicitly written into your customer contracts, none of that compounds.
Treat the model as infrastructure, not identity. Build a routing layer that directs different workflow tasks to the right model tier based on complexity, cost, and risk, rather than running everything through one provider. Multi-vendor architecture protects your margins and lets you absorb model upgrade migrations on behalf of your customers. That last point is a retention lever most founders underestimate.
Before the first enterprise procurement conversation. The founders who build the governance layer early find that it compounds into a structural advantage, customers who have outsourced their AI compliance risk to you have switching costs that go well beyond the product itself.
Run the four positioning tests in this article honestly with your co-founder or team, and mark each one complete only if you have genuinely addressed it, not if it is on your roadmap. The gap between where you are and where you need to be is the work. The founders building lasting AI companies are the ones who go deep enough that no infrastructure provider can simply replicate what they have built.
Saurabh Lahoti is the founder of GTMDialogues, helping early-stage B2B startups scale with sharper GTM strategy, inbound marketing, and founder-led storytelling.
.png)
