Editor's Note: As large language models continue to advance, the AI application layer is facing a widespread anxiety: If model companies like OpenAI and Anthropic control the underlying models while also possessing distribution channels and brand advantages, what's left for startups to do at the application layer?

This is precisely the question a16z partner Joe Schmidt attempts to answer in this article. He uses the "Yellow Brick Road" from The Wizard of Oz as a metaphor, dividing AI application opportunities into two categories: one is the main road that model companies are themselves entering, such as code generation, writing, image generation, general-purpose agents, and horizontal office assistants. The other is "the rest of Oz"—those vertical scenarios that involve deep integration into industry workflows, rely on complex processes, data accumulation, compliance governance, and systems integration capabilities.

In his view, the real opportunity for startups lies in the latter.

From sales to insurance, Joe Schmidt repeatedly emphasizes the same logic: what enterprises are truly willing to pay for is not a smarter chat window, but a system that takes responsibility for business outcomes. It needs to understand the messy state of customer data, handle multi-person approvals and edge cases, shoulder compliance and audit responsibilities, and also manage migration, routing, and cost optimization for customers as models continuously upgrade.

This also forms this article's core judgment about the next generation of enterprise software: underlying models will become increasingly powerful and also increasingly replaceable; but what is truly irreplaceable is the data, processes, governance capabilities, and operational memory accumulated around specific industries and specific workflows. The opportunity for AI application companies lies not in competing with model companies for the "Yellow Brick Road," but in venturing into those places that are more complex, messier, slower, yet closer to real business value.

The following is the original text:

Lately, I keep hearing the same question from founders and prospective employees: Is there anything left to do at the AI application layer? Or will OpenAI and Anthropic ultimately kill everything?

There's a typical AI-style anxiety behind this question. Some have already concluded that if you don't want to be permanently stuck in the infrastructure layer, the only positions with long-term value are either inside the major model labs or starting companies in robotics, hard tech, or similar frontier areas—theoretically, doing things the "labs don't touch." Because if every category of software is going to be swallowed, either directly by Codex or Claude absorbing the corresponding work, or made obsolete by some future model, then the best choice seems to be: run!

I admit I'm almost an AI maximalist myself, and I think they are half right. The big model labs are indeed entering large swaths of the application layer. But the "application layer" is not a homogeneous set of opportunities. The truly important criterion is: Are you on the "Yellow Brick Road," or somewhere else in Oz.

The "Yellow Brick Road" is what we use to describe the path the major model labs are walking and investing massive resources in. Problems like code generation, writing, and image creation are naturally suited for the labs because they get better directly as the raw capabilities of the model improve: every dollar invested in pre-training and post-training directly improves product quality.

But elsewhere in Oz, there are more complex, often more vertical problems. They are not simply about giving an enterprise user a horizontal tool and letting it connect to standard tools and computer capabilities. Here, value comes more from the scaffolding around the model: the scaffolding that makes the output credible, compliant, and truly integrated into business processes within a specific industry. The raw capability of the underlying model is still important, of course, but it's no longer the whole story.

We are seeing this play out in real time. OpenAI and Anthropic are effectively admitting to the market: they cannot solve all problems with a universal AI colleague. They have announced massive, front-line deployment joint ventures and built entire companies around configuring and customizing models for enterprises. If they truly believed the next model release would solve these problems, they wouldn't be investing billions of dollars into these kinds of projects.

So, if you want to make money building AI applications, don't walk the Yellow Brick Road. Go build elsewhere in Oz. Here are some lessons we, and founders in our portfolio, have learned in practice.

The Yellow Brick Road

If you're starting a company, the Yellow Brick Road is the most obvious path, but also the most dangerous one. Take a high-performing model, connect it to some off-the-shelf connectors like Google Drive, Slack, Salesforce, Notion, GitHub, and layer an agent orchestration on top. It looks like magic.

The problem is, this is exactly what the big model labs are doing with Cowork and Codex. They obviously own the models, which means they have better margins, more control, and can exert pricing power over all downstream players. But perhaps more importantly, they also control the architectural choices that dictate what problems a product is suitable to solve. So far, they have been very intentional about adopting a "model + tool calling" pattern, which is precisely the pattern needed for those horizontal, low-step-count jobs on the Yellow Brick Road. Even if a startup could somehow surpass Codex or Claude Code, the big model labs still have massive distribution and the strongest brand halo in AI.

If you're an AI application company playing the same game—connecting the same connectors, with no underlying sub-agents or configuration, and no distribution—you're likely on a road to nowhere.

Elsewhere in Oz

The picture isn't all bleak for startups. Significant opportunities remain outside the Yellow Brick Road. Startups can own customers and solve complex problems here.

These companies are building agent experiences: models woven into complex networks of tools, automation, and integrations—in other words, software. This also makes most of these startups inherently vertical. They can focus on multi-step, multi-party workflows, design sub-agents for different roles and vertical scenarios, and handle problems that Anthropic and OpenAI's horizontal platforms struggle to reach: gathering context across systems and routing tasks to multiple people who need to approve at different stages.

This kind of work often involves one or more legacy systems, frequently requires deterministic outcomes because ambiguity is unacceptable, and is sometimes directly tied to an important business outcome. The big model labs certainly know how valuable these problems are: that's why they are building their own outsourced configuration teams, and why an entire category of RLHF-as-a-service companies for enterprise customers is emerging.

Why "Elsewhere in Oz" Won't Be Completely Taken Over by the "Wizard"

One rebuttal to the above is: betting against the model or the lab's continued progress has been a bad trade so far. They will likely keep getting stronger and eventually eat the markets these application-layer companies serve.

The big model labs will certainly continue to progress. But I believe companies elsewhere in Oz have several ways to defend themselves in the long run.

Data & The Learning Flywheel

Much of what you truly internalize in a business doesn't exist in any training set: unwritten industry conventions, undocumented standards, tribal knowledge in practitioners' heads. None of this is on the public internet. No amount of training compute can substitute for getting inside the workflows where this knowledge lives.

Two flywheels compound here: a cross-customer flywheel, where patterns compound as you see more variations of the same problem; and an intra-customer flywheel, where the reasoning behind specific decisions, unspoken exceptions, the company's own rules of thumb, only surface when users truly interact with the system.

Even if customer data can't be used cross-customer, application companies can still leverage pattern recognition of different customer problem types to guide architecture for future problems. A company that has had its agents handle a hundred legal redline revisions, a thousand insurance underwriting cycles, or ten thousand SDR prospecting activities has a form of understanding about the problem shape that a newcomer can't replicate by spinning up a new agent for the first time.

Theoretically, a horizontal agent could also build the same learning infrastructure. But the reason it doesn't, beyond lack of focus, is user experience. Capturing this kind of knowledge depends entirely on what workflow interface you expose to users. Vertical players can design these interfaces around the information truly needed for specific workflows, which horizontal tools can't. Evaluation sets, labeled outputs, edge-case classification systems can compound into a vertical-specific data flywheel, further supporting fine-tuning. Later entrants without equivalent scale of production exposure will struggle to generate this flywheel. Its feasibility depends on data rights, accumulated production usage, and customer contract structures, but pattern recognition itself will continue to accumulate.

Managing Model Volatility & Complexity

The big model labs already do routing internally: calling different model classes for different requests, using model ensembles under the hood. What they can't do is route across vendors, easily evaluate competitor models for a specific sub-task, or use the truly optimal open-source fine-tuned model for a narrow piece.

Companies elsewhere in Oz will pick the most suitable model for each sub-task across the entire model market, not just the model their parent lab released. They will also absorb the work no one wants to do: rerunning evaluations with every new model release, recalibrating prompts for customer edge cases, shipping updates without breaking production. The big model labs won't do this for the customer. They sell you a new model and tell you to migrate. Companies elsewhere in Oz absorb the migration cost. The customer gets the best intelligence available across the market, plus continuity across every upgrade.

Cost Optimization

Dumping every query to Opus 4.7 is the fastest path to negative gross margins. The best Oz companies will route between tiers of models: hardest tasks to frontier models, most tasks to mid-tier models, using smaller custom or fine-tuned models where proven viable.

Some of these companies are now doing their own post-training on top of this, optimizing models to the narrow slice of work the customer actually cares about, serving it at a fraction of the cost of a frontier API call. The big model labs price the "floor": the cheapest intelligence you can buy for X dollars. Oz companies sell the inverse: the cheapest dollar cost at the intelligence level a specific workflow actually needs. This is only possible when you know exactly what level of intelligence each sub-task requires. And the big model labs are structurally incapable of knowing every task inside every vertical. Ultimately, this translates directly into lower, more manageable outcome-based pricing.

Governance

Becoming the control plane for how a customer runs AI in a vertical area creates substantial value. This control plane is where permissions, audit logs, what agents are allowed to do, and what agents actually did all come together.

This control plane is built on guardrails specific to the use case, and guardrails vary wildly across industries and job types. Because these companies own the tools, workflows, and data the agents touch end-to-end, they can provide deterministic outcomes in ways a horizontal tool struggles to. They also absorb regulatory complexity for the end buyer: the Federal Rules of Civil Procedure and rules of professional conduct in law, HIPAA in healthcare, SEC and FINRA rules in finance, state-level insurance regulation, etc. Horizontal players cannot credibly do this without turning themselves into a hundred different verticals. What a CIO needs is a partner that can explicitly promise in a contract: it will own the compliance handling for the agents it provides.

All of this ultimately comes back to the same thing: focus.

This focus can be a vertical industry, like insurance, law, accounting; or a function done deep enough, like sales, customer support, finance. Either way, this work requires a team living with the same customer profile long-term, understanding its workflows, edge cases, and regulatory requirements. The big model labs aren't built for this. They have to serve everyone, cover everywhere, which is why they built the Yellow Brick Road in the first place. The same trade-off will make it hard for them to go elsewhere in Oz: you can be everywhere for everyone, or you can be exceptional at one thing, but not both.

Sales as an Example: Practical Advice from a Technical CEO at 11x

How does this look in practice? Here's some practical advice from Prabhav Jain, CEO of 11x.

Focus on Outcomes

A viable tactical path to building a company defensible against the big model labs is to start from a specific outcome the customer truly cares about. For us, that outcome is helping businesses generate more leads and sales pipeline.

From there, the problems become very specific: Which activities do we want to own end-to-end and that demonstrably drive pipeline growth? Break each activity down into tasks. Which tasks are suited for agents, which aren't? Which require complex domain insight, which don't? The big model labs will also ship workflows, but when a workflow has many steps, messy inputs, difficult-to-explain state, or real-world constraints, just having a better model doesn't get the job done. The work then returns to traditional software engineering, and at that layer, the big model labs have no advantage over a focused application company.

For example, some tasks we handle include: prospect sourcing based on custom signals, lead enrichment, deep account research, pulling context from the CRM, writing messages for different channels, a lead qualification agent, and email deliverability systems. Some of these are agent tasks, some aren't. These aren't one-prompt tasks; they require deep engineering.

The key insight from the Oz analogy is: in any real workflow, roughly half of the steps, at a glance, are non-agent tasks, and that half carries no lab advantage. Below the model layer, their ability to write deterministic software isn't better than yours. And the other half, the agent tasks, still require you to tune, train, and constrain the model around the specific outcome you actually want.

Domain knowledge often isn't in the generic training data. These capabilities must be built bottom-up from the vertical or function and fed to the model at the right moment in the workflow. When our agent qualifies an inbound lead over the phone, it has to be trained to understand what constitutes a good sales conversation for a specific industry, a specific user persona. This is work for the application company, and this capability compounds.

More importantly, these capabilities keep getting stale, because the businesses themselves evolve. So your ability to continuously evolve the workflow and context becomes the competitive advantage itself. For instance, when we first started scaling our outbound email product, "AI-written emails" were just emerging. Fast-forward to today, people have developed a keen sense for which emails are AI-written and which feel more human, and the key is, this judgment shifts every few months. Our agents have to adapt with market dynamics, but the moat is also built here. In fact, despite this dynamism, our positive reply rates have increased 4x over the past few months, generating hundreds of millions in sales pipeline for our customers.

Tackle High Complexity Problems

Complex problems are where real business value is unlocked. Otherwise, you easily find yourself building a thin wrapper.

Break down any sufficiently complex business problem, and chaos appears quickly. Here's a deceptively simple example from the GTM world: If a company is already your customer, you shouldn't reach out to a contact at that company. This is anything but simple.

Maybe you have the domain in your CRM for that company. What about companies with dozens of subsidiaries? What if the CRM record has the parent company's domain? What if an outdated matching field in Salesforce causes you to send a cold sales email to the CRO of an existing customer? Real-world data is messy. Humans struggle with this; models don't magically cross this threshold. Creating order from this chaos requires designing specialized agents around the specific shape of the problem, not just pointing a general copilot at the CRM. In fact, based on the data we hold, we've found our data quality and freshness is often higher than the customer's own, so by default we anchor on our own data.

Guardrails Aren't Just to Prevent Bad Things. This Is What Customers Pay For

Guardrails are severely underrated. Even within the same product, each use case needs its own guardrails. For us, the guarantees required for a regulated financial services lead are completely different from those for a mid-market SaaS customer. And these guarantees cascade down to how the agent writes, who it can contact, what data it can touch, what it can say on a call, and how every decision is logged.

A one-size-fits-all system breaks in the face of this variance. Guardrails must be built per use case, configured per customer, and continuously audited, and this work falls squarely on the application company. This is why we need frontline deployment engineers and technical deployment strategists to tune for each customer's requirements.

For example, we worked with a Fortune 1000 institution doing consented voice outreach to its massive SMB customer base. In the first few attempts, answer rates were low. We had to rapidly iterate, learning how to get engagement from this specific audience within the first 10 seconds of a call. SMB owners behave differently from large B2B buyers or consumers. Now, we create more sales opportunities for them in a day than their entire sales team could generate in a month for that segment.

Insurance as an Example: Practical Advice from the CEO of FurtherAI

Sales is just one example. Insurance is another, illustrating the same point from a different angle. Here's Aman Gour, CEO of FurtherAI, on what "building off the Yellow Brick Road" means.

When we started deploying AI into real insurance operations, we repeatedly heard an assumption: The model is the intelligence, the workflow is just scaffolding built around it.

But the more insurance companies we worked with, the more we became convinced it's the opposite.

In insurance, much of the intelligence exists *within* the workflow. Two insurers can have a submission walk what looks like the same path: submit, triage, quote, underwrite. The path itself is easy. What distinguishes insurers is everything inside the path: which risks need escalation, which loss signals matter, which underwriting guideline wins when two conflict, when a human signature is mandatory, what external data to pull, and how the final decision gets recorded.

This logic doesn't live in a clean rules engine. It's scattered across SOPs, manager reviews, underwriting philosophy, company-specific risk appetite, and years of operational experience. Much of it isn't written down in a form a model can directly read.

That's why we don't believe in pure agents that reason from scratch every time, nor in rigid workflows that break at the first sign of real-world complexity. Instead, we've been building agentic workflows. Workflows bring repeatability, auditability, and cost control; agents handle variability and recover the process when the ideal path breaks; humans stay in the loop where judgment and accountability are involved.

On day one, this system automates manual work. But over time, every escalation becomes a signal, every exception is feedback, every human override tells you where the original playbook was incomplete. Over time, the workflow stops being just a script and becomes the operational memory of the insurance company.

This is precisely the part the big model labs can't reach. They will keep shipping better models and better general agents, and they should. But they won't live long-term inside an insurer's production workflow, learning why a particular account was escalated, why a risk was declined, or why an underwriter overrode the risk appetite guide and turned out to be right.

That understanding only comes from running the same workflow thousands of times in production. The workflow you ship on day one isn't the moat. The loop formed by production usage over time is the moat.

For us, this is what "building off the Yellow Brick Road" means.

How to Know If You're "Elsewhere in Oz" or Still on the "Yellow Brick Road"?

The Tool & Step Test

How many steps does this work require? How complex are the tools you need to build to support it?

Compare a horizontal AI searching Google Drive: it's a one-step action against a tool, and the result has high error tolerance. The user reads the summary, and if it's wrong, asks again.

Now consider a multi-step legal redline revision task based on a law firm's precedent from the last three years: it might involve dozens of steps, multiple tools, and the output must pass partner review and potentially be argued in court. Both look like "an agent doing a thing," but only the latter requires the kind of deep software built over years by a focused team.

The System Test

Are you building a system the customer uses to run work, or are you adding a tool on top of a system the customer already has?

A system owns the end-to-end workflow: data capture, governance, work completion records. The customer points to this system when describing how actual work happens. A tool just adds a layer of intelligence to a workflow the customer is already running.

Tool products can also generate real revenue, but they are easier for big model labs to take because the customer isn't reliant on you as the orchestration layer. High ACV is often a signal of a system product because systems replace real headcount and get paid accordingly. But this isn't a guaranteed rule. You need to ask: If a big model lab launched something that looked directly competitive, would the customer still need your tool? If the answer is yes, you're building a system. If the answer is no, you're a tool—even if your ACV is high.

The Hedge Fund / P&L Test

Big model labs are judged on benchmark scores; companies elsewhere in Oz are judged on their customer's P&L.

Customers don't care about your model's score on SWE-Bench or MMLU. They care: did your agent close the deal, did it correctly revise the contract redlines, did it underwrite the right policy. If the customer is focused on specific workflow outcomes, not general capability scores, you're elsewhere in Oz. If the customer is paying for general capability, you're selling something they can get via a Claude or Codex seat.

The best agent companies need to execute like a hedge fund: they win on alpha, and alpha is measured in the customer's P&L, not benchmark scores.

Both Can Win, and Will Win

We are going to see massive winners both on and off the Yellow Brick Road. Models will keep winning because they own the models and the distribution built for horizontal tools.

Elsewhere in Oz can also win, provided they own the system of work: the interface through which the enterprise actually executes work, and the data that flows through and is captured. These companies own data capture, workflow action systems, and governance. As complex workflows in a vertical mature, they compound into a core experience the customer can't live without. As incumbents and new entrants keep shipping the next generation of models, this company becomes the layer that integrates and delivers them to the customer. The underlying model is replaceable; the system of work is not.

The next generation of enterprise software will be built off the Yellow Brick Road.