# Avoiding Death on the Yellow Brick Road
**作者**: Joe Schmidt IV
**日期**: 2026-05-27T14:26:45.000Z
**来源**: [https://x.com/joeschmidtiv/status/2059642470334677472](https://x.com/joeschmidtiv/status/2059642470334677472)
---
## Why The App Layer Isn't Dead
The question I keep getting from founders and prospective employees: is there any AI application layer left to build, or are OpenAI and Anthropic going to kill everything?
There's a particular flavor of AI psychosis behind the question. Some people have concluded the only durable places to avoid the permanent underclass are inside a big lab or out on the frontier building in robotics, hardtech, or similar – theoretically anything “the labs can't touch.” If every piece of software is about to be eaten, either by Codex or Claude absorbing the work directly, or by a future model that will make whatever you’ve built unnecessary, then run!
Listen I'm as much of an AI maximalist as almost anyone, and I think they're half right. The labs really are coming for a huge swath of the application surface. But "the application layer" isn't just one homogenous opportunity. The right framing is whether you're on the Yellow Brick Road or somewhere else in Oz.
The Yellow Brick Road is our shorthand for the path the labs are walking, where they’re committing extraordinary resources. The reason the labs are best-suited for problems like code generation, writing, or image-creation is because these problems improve with raw model capability: every dollar spent on pre-training and post-training improves product quality. Meanwhile, the rest of Oz is inhabited by more complex, often vertical problems, that aren’t as simple as giving a business user a horizontal tool with access to standard tools and computer use. The value comes less from the underlying model's raw capability (though that’s still important!) than from the scaffolding around it that makes the output trustworthy, compliant, and operational inside a specific industry.
We’re seeing this play out in real time as OpenAI and Anthropic are effectively telling the market they can't solve every problem with a generic AI coworker. They've announced massive forward-deployed joint ventures to build whole companies around configuring and customizing their models for the enterprise. You don't pour billions into those programs if you think the next model release is going to take care of it.
So if you want to get rich building AI apps – avoid the yellow brick road and build somewhere else in Oz. Here’s what we’ve learned, and what some of our portfolio founders have learned, about what works.
The Yellow Brick Road
If you're starting a company, The Yellow Brick Road is the most obvious path to go down, but it's the most dangerous. Take a high performing model, plug in some off-the-shelf connectors (like G Drive, Slack, Salesforce, Notion, GitHub), and ship some sort of agentic orchestration layer on top of that. Magic!
The problem with this is that this is what the labs are doing with Cowork and Codex. Obviously, they own the model, which gives them better margins, control, and the ability to exert pricing power on anyone who's downstream from them. But maybe most importantly also own the architectural choices that define what their products are built to solve well. They've been deliberate so far about the model plus tool calls pattern, and this is exactly what horizontal low-step-count work on the road requires. Even if a startup could somehow outperform Codex or Claude Code, the labs have massive distribution arms and the biggest brand halo in AI.
If you're an AI app company running that playbook with the same connectors, no sub-agents or configuration below it, and no distribution, you're likely walking down the road to nowhere.
The Rest of Oz
It’s not all doom and gloom for startups. There's an enormous opportunity outside the Yellow Brick Road, where startups have a clear path to own their customer and solve complex problems.
These businesses are building agentic experiences where the model is woven through a complex web of tools, automations, and integrations (read: software), leading most of these startups to be vertical by default. They can focus on multi-step and multi-player work, with sub-agents for role- and vertical-specific tasks, that Anthropic and OpenAI can’t reach with horizontal platforms: gathering context across systems, then routing through multiple humans who have to approve at different stages. It often involves one or more legacy systems, tends toward needing deterministic outcomes where ambiguity isn't acceptable, and is at times tied to some valuable business outcome. The labs understand how valuable these problems are: that’s why they’re building their own outsourced configuration shops, and why an entire upmarket class of reinforcement learning businesses exist.
Why the rest of Oz won't be owned by the Wizard
The response to the above would be that to date, it’s been a pretty bad trade to bet against the models/labs improving. They’ll likely just keep getting better and eventually eat into the market served by these application layer businesses.
The labs will certainly improve, but I'd argue there are a few ways the rest of Oz can defend themselves over time:
Data and learning flywheels:
A lot of what you internalize isn't in any training set — unwritten industry norms, undocumented standards, the tribal knowledge that lives in practitioners' heads. None of it is on the public web. No amount of training compute substitutes for being inside the workflows where this knowledge actually lives. There are two flywheels stacked on top of each other here: an across-customer one — patterns that compound as you see more variants of the same problem — and a within-customer one — the why behind specific decisions, the unsaid exceptions, the firm's own rules of thumb that only surface through real interaction with the system.
Even if customer data can't be used across customers, application companies will be able to leverage pattern recognition across customer problem types, and use that to inform the right architecture for future problems. A company that has run its agents through a hundred legal redlines, a thousand insurance underwriting cycles, or ten thousand SDR campaigns has internalized the shape of the problem in a way the next entrant cannot replicate by spinning up a fresh agent for the first time.
A horizontal agent could in principle build the same learning infrastructure. The reason it doesn't, beyond pure focus, is UX: capturing this kind of knowledge depends entirely on the workflow surfaces you give the user, and vertical players can shape those surfaces around exactly what their workflow needs to surface. Horizontal tools can't. Eval sets, labeled outputs, and edge-case taxonomies can compound into a vertical-specific data flywheel which can fuel fine-tuning the next entrant can't generate without comparable production exposure. Whether this is possible depends on data rights, the volume of production exposure accumulated, and the structure of customer contracts, but pattern recognition accrues regardless.
Managing model variability and complexity: The labs are already routing internally — different model classes for different requests, ensembles under the hood. What they can't do is route across vendors, or evaluate a competitor's model for a specific sub-task, or use an open-source fine-tune for the narrow piece where it's actually best. The Rest of Oz company picks the right model for each sub-task across the entire model market, not just what its parent lab ships. It also does the work nobody wants to do — re-running evals on upgrades, recalibrating prompts for the customer's edge cases, rolling out without breaking production — every time a new model lands. The labs aren't doing this on the customer's behalf; they sell you their next model and tell you to migrate. The Rest of Oz company absorbs the migration. What the customer gets is the best intelligence available across the whole market, plus continuity through every upgrade.
Cost optimization: Running every query through Opus 4.7 is the fastest path to negative gross margins. The best Rest of Oz companies route across tiers of models — frontier models for the hardest tasks, mid-tier for the bulk, smaller custom or fine-tuned models where they've earned the right to use them. Some are now post-training their own models on top of that, optimizing them for the narrow slice of work their customer cares about and serving them at a fraction of the cost of a frontier API call. The labs price the floor: the least intelligence available at $X. The Rest of Oz company sells the inverse — the lowest dollar cost for the specific level of intelligence the workflow actually requires. That's only possible if you know exactly what level each sub-task needs, which the labs structurally can't know across every vertical. It translates directly into lower, controlled prices for outcomes.
Governance: There is considerable value in becoming the control plane for how their customers run AI in that vertical – the place where permissions, auditing, what-the-agent-is-allowed-to-do, and what-the-agent-actually-did all converge. That control plane is built out of use case specific guardrails that look completely different across industries and job types. Because they own the tools, the workflows, and the data the agent touches end-to-end, they can provide deterministic outcomes in ways horizontal tools will struggle to. They are also the entity that absorbs the regulatory complexity for the end buyer — FRCP and bar rules in legal, HIPAA in healthcare, SEC and FINRA in finance, state insurance regulations, and so on. A horizontal player can't credibly do that without becoming a hundred different verticals at once. CIOs want to have a partner that contractually states they are handling compliance for the agents they are providing.
All of these come back to the same thing: focus. That could be a vertical (insurance, legal, accounting) or a function done deeply (sales, customer support, finance). Either way, the work needs a team that's heads-down on one customer set — its workflows, its edge cases, its regulations. The labs aren't built for that. They have to be everywhere, for everyone, which is how they built the Yellow Brick Road in the first place. The same trade-off keeps them out of the rest of Oz — you can be everywhere at once, or you can be great at one thing. Not both.
Sales as an example – practical tips from 11x’s technical CEO
How should you think about this in practice? Here’s some practical tips from Prabhav Jain, the CEO of 11x.
Focus on outcomes
A tactical path to building a company that is resilient to the labs is to just start from a specific outcome that your customers really care about. For us that was helping companies generate more pipeline. From there the questions get tactical. Which activities do we want to own end-to-end that actually drive pipeline? Decompose each activity into tasks. Which tasks are agentic and which aren't. Which require intricate domain insight and which don't. The labs will ship workflows too, but when the workflow has many steps, messy inputs, hard-to-interpret state, or real-world constraints, a better model alone won't get you there. The work falls to good old-fashioned software engineering, and the labs hold no edge over a focused application company on that surface. For example, here are some of the tasks that we handle, some agentic, and some not: lead prospecting based on custom signals, lead enrichment, deep account research, context fetcher from CRM, channel-specific message writer, lead qualification agent, and email deliverability system. These aren’t tasks you can just one-shot and require deep engineering.
The critical insight in the Oz analogy is that roughly half of any real workflow that is non-agentic carries no lab advantage. They are no better than you are at writing the deterministic software underneath the model layer. And the half that is agentic still requires you to tune, train, and constrain the models against the result you actually want. Domain knowledge often doesn't sit in general training data. Those skills get built from the ground up for the vertical or function, and fed into the model at the right moment in the workflow. When our agents are qualifying an inbound lead on the phone, I have to be trained on what a good sales conversation is for that specific industry and that persona. That is application company work, and it compounds.
More importantly, those skills become outdated all the time because businesses evolve, so your ability to evolve those workflows and context becomes a competitive advantage. As an example, when we started our scaled email outreach product, “AI” written emails were just starting to come into play. Fast forward to today, folks have a tuned sense of emails that are AI written vs human and crucially, this changes every few months. Our agents have to constantly adapt given the market dynamic, but this is where the moat is built. In fact, despite this dynamic, our positive reply rates have gone up 4x in the last few months and we’ve generated hundreds of millions in pipeline for our customers.
Work on problems where complexity is high
Complex problems are where real business value gets unlocked. Otherwise you’ll find yourself building a thin wrapper.
Decompose any sufficiently complex business problem and messiness shows up quickly. Here’s an example from the GTM world that sounds trivial: you shouldn’t reach out to a contact at a company if that company is already a customer. It’s anything but. Maybe you have the domain associated with the company in your CRM. What about companies with dozens of subsidiaries? What if the CRM record has the parent’s domain? What if a stale matching field in Salesforce sends a cold pitch to a current customer's CRO? Real-world data is messy. Humans struggle with it. Models don't magically clear that bar. Driving order out of that mess requires purpose-built agents engineered for the specific shape of the problem, not a general-purpose copilot pointed at a CRM. In fact, based on the data that we have, we have realized that the quality and freshness of our data is much higher than our customers, so by default, we anchor on our own.
Guardrails aren’t just to prevent bad stuff from happening. That’s what your customers are paying you for.
Guardrails are severely underestimated. Even inside the same product, every use case needs its own. For us, a regulated financial services prospect demands different guarantees than a mid-market SaaS customer, and those guarantees roll down into how the agent is allowed to write, who it can contact, what data it can touch, what it can say on a call and how every decision gets logged.
A one-size-fits-all system collapses under that variance. Guardrails have to be built per use case, configured per customer, and audited continuously, and that work sits squarely with the application company. This is why we have FDEs and technical deployment strategists that need to tune for each customer’s requirement. As an example, we worked with a F1000 institution to do consented outbound via voice to their large SMB customer base. The initial few iterations had low pickup rates - we had to quickly iterate and learn how to get this specific type of audience to engage in the first 10s of the call. SMB business owners behave very differently from larger B2B buyers or consumers. We now generate more sales opportunities for them in a day than their entire sales team for that segment in a month
Insurance as an example – practical tips from FurtherAI’s CEO
Sales is one example. Insurance is another, and it makes the same point from a different angle. Here’s how Aman Gour, CEO of FurtherAI, thinks about building off the road:
When we started deploying AI inside real insurance operations, we kept hearing a particular assumption: the model is the intelligence, and the workflow is just scaffolding around it.
The more carriers we worked with, the more convinced we became that this is backwards.
In insurance, a lot of the intelligence lives inside the workflow itself. Two carriers can run a submission through what looks like the same path: submission, review, quote, bind. But the path is the easy part. What separates the two carriers is everything inside it: which risks get escalated, which loss signals matter, which appetite rule wins when two of them conflict, when a human has to sign off, which external data gets pulled in, and how the final decision gets documented.
That logic does not live in one clean rules engine. It is spread across SOPs, manager reviews, underwriting philosophy, carrier-specific appetite, and years of operational experience. A lot of it is not written down in a form a model can simply read.
This is why we do not believe in a pure agent that reasons from scratch every time, and we do not believe in a rigid workflow that breaks the moment reality gets messy. And instead been building agentic workflows. The workflow gives you repeatability, auditability, and cost control. The agent handles variability and recovers when the happy path breaks. The human stays in the loop for the judgment calls where accountability matters.
On day one, this automates manual work. But over time, every escalation becomes a signal, every exception is a feedback and every human correction shows where the runbook was incomplete. Over time, the workflow stops being a script and starts becoming the carrier’s operating memory. This is the part the labs will find hard to reach. They will keep shipping better models and better general agents, and they should. But they do not sit inside a carrier’s production workflows long enough to learn why one account was escalated, why one risk was declined, or why an underwriter overrode the appetite guide and was right to do so.
That understanding only comes from running the workflow, in production, many thousands of times. The workflow you ship on day one is not the moat. The loop that production usage creates over time is.
For us, that is what it means to build off the road.
How do you decide if you are in the rest of Oz or not?
The tools-and-steps test: How many steps does the work take, and how complex are the tools you have to build to support it? Compare a horizontal AI search across Google Drive — one step against one tool with a forgiving outcome, the user reads the summary and re-asks if it's wrong — to a multi-step legal redline against three years of firm precedent: dozens of steps across many tools, output that has to clear partner review and may need to be argued in court. Both look like "an agent doing work," but only one of them requires the kind of deep software a focused team takes years to build.
The system test: Are you building a system the customer runs their work through, or a tool that sits on top of a system they already have? Systems own the workflow end-to-end — the data capture, the governance, the records of what got done — and they're what the customer points to when describing how the actual work happens. Tools on the other hand just add intelligence to a workflow the customer already runs. The tool case generates real revenue and the labs can take it because the customer isn't depending on you as the orchestration layer. High ACV is usually a signal of a system, since systems replace real headcount and get paid accordingly, but it isn't a guarantee. Ask yourself if the customer would still need your tool if a lab shipped something that supposedly directly competes with you. If yes, you're building a system. If no, you're a tool — even if your ACV is high.
The hedge fund / P&L test: While lab performance is judged against benchmarks, rest of Oz performance is judged against your customer's P&L. Your customer doesn't care that your model scored well on SWE-Bench or MMLU — they care whether your agent closed the deal, redlined the contract correctly, or bound the right policy. If they're fixated on their workflow-specific outcome, not on a generic capability score, you're in the rest of Oz. If they're paying for generic capability, you're selling them something they can get with a Claude or Codex seat. The best agent businesses are going to need to execute like hedge funds — winning on alpha measured in customer P&L, not in benchmark scores.
Both can (and will) win
We're going to see massive winners on and off the Yellow Brick Road. The models will continue to win because they own the model and they own the distribution for the horizontal tools they have designed.
The rest of Oz can win if they own the system of work — the surface where the work of the company actually executes and the data that flows from it gets captured. These companies own the data capture, the workflow system of action, and the governance. As more complex workflows mature in a vertical, they compound into one core experience the customer comes to depend on. As new model generations ship from incumbents and new entrants, the company becomes the layer that integrates and delivers them to the customer. The model is fungible underneath; the system of work is not.
The next generation of enterprise software is going to be built off the road.
If you're building it, reach out: jschmidt@a16z.com.
## 相关链接
- [Joe Schmidt IV](https://x.com/joeschmidtiv)
- [@joeschmidtiv](https://x.com/joeschmidtiv)
- [490K](https://x.com/joeschmidtiv/status/2059642470334677472/analytics)
- [massive forward-deployed joint ventures](https://techcrunch.com/2026/05/04/anthropic-and-openai-are-both-launching-joint-ventures-for-enterprise-ai-services/)
- [Prabhav Jain](https://www.linkedin.com/in/jainprabhav)
- [11x](https://www.11x.ai/)
- [Aman Gour](https://www.linkedin.com/in/amangour)
- [FurtherAI](https://www.furtherai.com/)
- [system of work](https://a16z.com/services-led-growth/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:26 PM · May 27, 2026](https://x.com/joeschmidtiv/status/2059642470334677472)
- [490.2K Views](https://x.com/joeschmidtiv/status/2059642470334677472/analytics)
- [View quotes](https://x.com/joeschmidtiv/status/2059642470334677472/quotes)
---
*导出时间: 2026/5/28 10:19:18*
---
## 中文翻译
# 在黄砖路上避开死亡
**作者**： Joe Schmidt IV
**日期**： 2026-05-27T14:26:45.000Z
**来源**： [https://x.com/joeschmidtiv/status/2059642470334677472](https://x.com/joeschmidtiv/status/2059642470334677472)
---
## 为什么应用层并没有死
我不断被创始人和潜在求职者问到的一个问题是：还有值得构建的 AI 应用层吗，还是说 OpenAI 和 Anthropic 会消灭一切？
这个问题背后有一种特别的 AI 焦虑。有些人已经得出结论：要避免沦为永久底层阶级，唯一长久之地要么在大实验室内部，要么在前沿领域——机器人、硬科技或类似方向——进行构建，理论上任何“实验室无法触及”的东西。如果每一款软件都即将被吞掉，要么被 Codex 或 Claude 直接吸收其工作，要么被未来的某个模型让你构建的东西变得毫无必要，那就快跑吧！
听着，我几乎和任何人一样是 AI 最大化主义者，我认为他们说对了一半。实验室确实正在进军应用领域的一大片版图。但“应用层”并不是一个同质化的单一机会。正确的思考框架是：你是在黄砖路上，还是在奥兹国的其他地方。
黄砖路是我们对实验室正在走的道路的简称，他们在那里投入了非同寻常的资源。实验室最适合解决代码生成、写作或图像创作这类问题，是因为这些问题会随着模型的原始能力提升而改善：花在预训练和后训练上的每一美元都能提升产品质量。与此同时，奥兹国的其他地方则栖息着更复杂、往往是垂直领域的问题，这些问题不像给业务用户一个配备标准工具和计算机使用权限的横向工具那么简单。其价值更多不是来自底层模型的原始能力（尽管这仍然重要！），而是来自围绕模型的脚手架——正是这些脚手架让输出在特定行业内变得可信、合规且可运营。
我们正在实时看到这一幕：OpenAI 和 Anthropic 实际上在告诉市场，它们无法用一个通用的 AI 同事解决所有问题。它们宣布了大型的前沿部署合资企业，围绕为其模型进行企业级配置和定制来建立完整的公司。如果你认为下一个模型发布就能解决问题，你就不会往这些项目里砸数十亿美元。
所以，如果你想通过构建 AI 应用来致富——避开黄砖路，到奥兹国的其他地方去构建。以下是我们总结的经验，以及我们一些被投公司创始人总结的经验，关于什么才是有效的。
黄砖路
如果你要创办一家公司，黄砖路是最显而易见的路径，但也是最危险的。拿一个高性能模型，接入一些现成的连接器（如 Google Drive、Slack、Salesforce、Notion、GitHub），再在其上发布某种智能体编排层。魔法！
问题在于，这正是实验室用 Cowork 和 Codex 在做的事情。显然，它们拥有模型，这给了它们更好的利润率、控制力，以及对任何下游玩家施加定价权的能力。但也许最重要的是，它们还拥有定义其产品擅长解决什么问题的架构选择权。到目前为止，它们一直坚持模型加工具调用的模式，而这恰恰是黄砖路上那种低步骤数的横向工作所需要的。即使一家初创公司能在某种程度上超越 Codex 或 Claude Code，实验室也拥有庞大的分发渠道和 AI 领域最强大的品牌光环。
如果你是一家 AI 应用公司，用相同的连接器执行这套打法，下面没有任何子智能体或配置，也没有分发渠道，那你很可能正走在一条通往虚无的路上。
奥兹国的其他地方
对初创公司来说，并非一片黯淡。在黄砖路之外存在巨大的机会，在那里，初创公司有一条清晰的路径来拥有自己的客户并解决复杂问题。
这些公司正在构建智能体体验，将模型编织进一个由工具、自动化和集成（即软件）构成的复杂网络中，这使得这些初创公司大多默认走向垂直化。它们可以专注于多步骤、多参与者的工作，为特定角色和垂直任务配置子智能体，这是 Anthropic 和 OpenAI 用横向平台无法触及的：跨系统收集上下文，然后路由到多个必须在不同阶段进行审批的人。这类工作往往涉及一个或多个遗留系统，倾向于需要确定性的结果——模糊性是不可接受的——并且有时与某些有价值的业务成果挂钩。实验室深知这些问题有多大的价值：这就是为什么它们在建立自己的外包配置部门，也是为什么整个高端市场会出现一类强化学习企业。
为什么奥兹国的其他地方不会被巫师占据
对上述观点的反驳会是：迄今为止，押注模型/实验室不会进步一直是一笔糟糕的交易。它们很可能持续变得更强，并最终蚕食这些应用层公司所服务的市场。
实验室当然会进步，但我认为奥兹国的其他地方有几种方式可以随时间进行自我防御：
数据与学习飞轮：
很多你内化的东西并不存在于任何训练集中——不成文的行业惯例、未成文的标准、存在于从业者头脑中的部落知识。这些都不在公共网络上。再多的训练算力也无法替代置身于这些知识真正所在的工作流之中。这里有两个叠在一起的飞轮：一个是跨客户的——随着你看到同一问题的更多变体，模式不断复利累积；另一个是客户内部的——特定决策背后的原因、没有明说的例外情况、只有通过与系统真实交互才会浮现的公司自身的经验法则。
即使客户数据不能跨客户使用，应用公司仍然能够利用跨客户问题类型的模式识别能力，并以此指导未来问题的正确架构。一家已经让自己的智能体经历过一百次法律红线修订、一千次保险承保周期或一万次SDR（销售开发代表）营销活动的公司，已经内化了问题的形态，而这种内化是新进入者通过临时启动一个全新智能体所无法复制的。
一个横向智能体原则上可以建立同样的学习基础设施。除了纯粹专注度之外，它之所以没有这样做，原因在于用户体验（UX）：捕捉这类知识完全取决于你提供给用户的工作流界面，而垂直领域的玩家可以围绕其工作流所需要呈现的确切内容来塑造这些界面。横向工具做不到这一点。评测集、标注输出和边缘案例分类可以叠加成一个垂直领域专属的数据飞轮，为微调提供燃料，而新进入者若没有相当规模的生产环境暴露，就无法生成这些数据。这是否可行取决于数据权利、积累的生产环境暴露量以及客户合同的结构，但无论如何，模式识别能力都会持续积累。
管理模型的多样性与复杂性：各大实验室已经在内部进行路由——针对不同请求使用不同的模型类别，底层采用模型集成。但他们做不到的是跨厂商路由，或针对特定子任务评估竞争对手的模型，或在实际表现最佳的细分环节使用开源微调模型。"绿野仙踪之外"的公司面向整个模型市场为每个子任务选择正确的模型，而不仅限于其母实验室发布的产品。它还承担那些没人愿意做的工作——每次新模型发布时，在升级版本上重新运行评测，针对客户的边缘案例重新校准提示词，并在不破坏生产环境的前提下上线。实验室不会代表客户做这些；他们只会把下一个模型卖给你，然后让你迁移。"绿野仙踪之外"的公司承接了迁移工作。客户得到的是整个市场上可用的最优智能，外加每一次升级过程中的连续性。
成本优化：让每个查询都经过 Opus 4.7 是走向负毛利的最快途径。最优秀的"绿野仙踪之外"公司会在不同层级的模型之间进行路由——最难的任务用前沿模型，大部分任务用中端模型，而在他们已经赢得使用资格的场景中，使用更小的定制模型或微调模型。一些公司甚至在此基础上对自己进行后训练，针对客户关注的细分工作领域进行优化，并以前沿模型API调用成本的一小部分来提供服务。实验室定价的是地板：以X美元获得的最低智能水平。"绿野仙踪之外"的公司销售的则是相反的东西——为工作流实际所需的特定智能水平提供最低的美元成本。这只有在确切知道每个子任务需要什么水平时才可能实现，而实验室在结构上无法了解每个垂直领域的这些细节。这直接转化为更低、更可控的结果定价。
治理：成为该垂直领域中客户运行AI的控制平面——权限、审计、智能体被允许做什么、以及智能体实际做了什么都汇聚于此——具有相当大的价值。这个控制平面由针对具体用例的防护栏构建而成，而这些防护栏在不同行业和工作类型之间看起来完全不同。因为智能体端到端接触的工具、工作流和数据都归他们所有，他们能够以横向工具难以企及的方式提供确定性的结果。他们也是为最终买家承担监管复杂性的实体——法律领域的FRCP和律师执业规则、医疗领域的HIPAA、金融领域的SEC和FINRA、各州保险法规等等。横向玩家若不同时化身为一百个不同的垂直领域，就无法令人信服地做到这一点。CIO们希望有一个合作伙伴能在合同中明确声明为其提供的智能体处理合规事宜。
所有这些都归结为同一件事：专注。这种专注可以是某个垂直领域（保险、法律、会计），也可以是深度耕耘的某个职能（销售、客户支持、财务）。无论哪种方式，这项工作都需要一个团队埋头深耕某一类客户——他们的工作流、他们的边缘案例、他们的监管规定。实验室不是为此而构建的。他们必须无处不在，服务所有人，这正是他们当初能够建成黄砖路的方式。而同样的取舍也把他们挡在了绿野仙踪的其余部分之外——你可以无处不在，也可以在一件事上做到卓越。但不能两者兼得。
以销售为例——来自 11x 技术型 CEO 的实用建议
在实践中应该如何思考这个问题？以下是 11x 的 CEO Prabhav Jain 提供的一些实用建议。
聚焦于结果
打造一家对实验室具有韧性的公司的战术路径，就是从客户真正关心的某个具体结果出发。对我们来说，那就是帮助企业生成更多销售管道。从这里开始，问题就变得具体化了。我们想要端到端掌控哪些真正能驱动销售管道的活动？将每项活动分解为任务。哪些任务是智能体化的，哪些不是。哪些需要深入的领域洞察，哪些不需要。实验室也会发布工作流，但当工作流包含许多步骤、杂乱的输入、难以解读的状态或现实世界的约束时，仅靠一个更好的模型是达不到目标的。这项工作就落到了传统优秀的软件工程上，而在这个层面上，实验室相较于一家专注的应用公司没有任何优势。例如，以下是我们处理的一些任务，有些是智能体化的，有些不是：基于自定义信号的潜在客户挖掘、潜在客户信息补全、深度客户研究、从CRM获取上下文、针对特定渠道的文案撰写、潜在客户资格审查智能体，以及邮件送达率系统。这些任务都不是可以一蹴而就的，需要深度的工程投入。
Oz（绿野仙踪）类比的关键洞见在于：在任何真实的非智能体（non-agentic）工作流中，大约有一半的内容并不给实验室带来任何优势。在编写模型层之下的确定性软件方面，他们并不比你更强。而剩下那一半涉及智能体的部分，仍然需要你围绕真正想要的结果去调优、训练和约束模型。领域知识往往并不存在于通用训练数据中。这些能力需要针对特定垂直行业或职能从零构建，并在工作流中恰当的时机注入模型。当我们的智能体在电话上甄别 inbound 线索时，它必须接受针对特定行业和特定人群的“什么是好的销售对话”的训练。这就是应用层公司的工作，而且这种积累会不断复利。
更重要的是，这些能力随时都会过时，因为业务在演变，因此你演变这些工作流和上下文的能力本身就成了一种竞争优势。举个例子，当我们刚推出规模化邮件外呼产品时，“AI”撰写的邮件才刚刚兴起。快进到今天，人们已经能够敏锐地分辨出哪些邮件是 AI 写的、哪些是人写的，而且关键是，这一点每几个月就会变化。面对市场动态，我们的智能体必须不断适应，但这恰恰是护城河形成的地方。事实上，尽管存在这种动态变化，我们的正向回复率在过去几个月里提升了 4 倍，我们已经为客户创造了数亿美元的商机管道。
在复杂度高的问题上下功夫
复杂的问题才是真正的商业价值被释放的地方。否则，你会发现自己只是在做一个浅层封装。
把任何足够复杂的商业问题拆解开来，混乱会很快浮现。以 GTM 领域的一个看似微不足道的例子来说：如果某公司已经是客户，你就不应该去联系该公司的联系人。但事情远没有那么简单。也许你在 CRM 中已经关联了该公司的域名。那有几十家子公司的公司怎么办？如果 CRM 记录里存的是母公司的域名呢？如果 Salesforce 中一个过期的匹配字段把冷启动推销发给了现有客户的 CRO 呢？现实世界的数据是混乱的。人类应对起来都很吃力。模型也不会神奇地越过这道坎。要从这种混乱中理出秩序，需要为问题的特定形态量身打造的智能体，而不是一个对着 CRM 的通用副驾驶。事实上，根据我们掌握的数据，我们发现我们的数据质量和新鲜度远高于我们的客户，所以默认情况下，我们以自己的数据为准。
护栏不仅仅是为了防止坏事发生。这正是客户付钱给你的原因。
护栏被严重低估了。即使在同一个产品内，每个用例也需要自己的护栏。对我们来说，受监管的金融服务潜在客户需要与中型市场 SaaS 客户不同的保障，而这些保障会层层落实到：允许智能体如何撰写内容、可以联系谁、可以触碰哪些数据、在电话里能说什么，以及每一个决策如何被记录。
一套放之四海而皆准的系统在这种差异面前会崩溃。护栏必须按用例构建、按客户配置、并持续审计，而这些工作正是应用层公司的职责所在。这就是为什么我们配备了需要为每个客户需求进行调优的 FDE 和技术部署策略师。举个例子，我们曾与一家财富 1000 强机构合作，通过语音向其庞大的 SMB 客户群进行经授权的外呼。最初几次迭代的接听率很低——我们必须快速迭代，学习如何让这类特定受众在通话的前 10 秒内参与进来。SMB 企业主的行为方式与大型的 B2B 买家或消费者截然不同。现在，我们一天就能为他们创造比其该细分领域整个销售团队一个月更多的销售机会。
以保险为例——来自 FurtherAI CEO 的实用建议
销售是一个例子。保险是另一个例子，它从不同的角度印证了同样的道理。以下是 FurtherAI 的 CEO Aman Gour 对在“铺好的道路之外”构建产品的思考：
当我们开始在真实的保险运营中部署 AI 时，我们不断听到一种假设：模型才是智能所在，工作流只是围绕它的脚手架。
与我们合作的承保方越多，我们就越确信这种观点是本末倒置的。
在保险行业，很多智能就存在于工作流本身之中。两家承保方可以用看似相同的路径处理一份投保申请：提交、审核、报价、承保。但路径是最容易的部分。区分两家承保方的是路径之内的所有东西：哪些风险需要升级、哪些损失信号重要、当两条核保规则冲突时哪条优先、什么时候需要人工签核、引入哪些外部数据，以及最终决策如何记录归档。
这些逻辑并不存在于一个干净的规则引擎里。它分散在 SOP、经理审核、承保哲学、承保方特有的风险偏好以及多年的运营经验之中。其中很大一部分并没有以模型能直接读取的形式写下来。
这就是为什么我们既不相信那种每次都从零开始推理的纯智能体，也不相信那种一旦现实变得混乱就会崩塌的僵硬工作流。我们转而在构建智能体化工作流（agentic workflows）。工作流给你可重复性、可审计性和成本控制。智能体处理各种变化，并在“理想路径”断裂时进行恢复。人类留在回路中，负责那些问责至关重要的判断决策。
第一天，它能自动化人工工作。但随着时间推移，每一次升级都成为一个信号，每一个例外都是一条反馈，每一次人工修正都揭示了操作手册的不足之处。久而久之，这个工作流不再是一个脚本，而开始成为承保人的运营记忆。这是实验室难以企及的部分。他们会持续推出更好的模型和更好的通用智能体，这是应该的。但他们不会长时间停留在承保人的生产工作流中，去了解为什么某个账户被升级、为什么某个风险被拒保，或者为什么某个核保员推翻了承保偏好指南而且做得对。
这种理解只能来自在生产环境中成千上万次地运行工作流。你第一天交付的工作流并不是护城河。生产使用随时间形成的循环才是。
对我们来说，这就是“在道路之外构建”的含义。
你如何判断自己是否处于“奥兹国的其他地方”？
工具与步骤测试：这项工作需要多少步骤，你需要构建多复杂的工具来支持它？对比一下：在 Google Drive 上进行横向 AI 搜索——一步操作，使用一个工具，结果容错性高，用户读一下摘要，如果不对就重新提问—— versus 针对事务所三年判例的多步骤法律文件修订：跨越多个工具的几十个步骤，输出必须通过合伙人审查，还可能需要在法庭上辩论。两者看起来都像“智能体在干活”，但只有其中一个需要那种专注团队需要花数年才能构建的深度软件。
系统测试：你构建的是客户通过其运行业务的系统，还是架设在客户已有系统之上的工具？系统端到端地拥有工作流——数据采集、治理、工作完成记录——当客户描述实际工作如何发生时，他们指向的是系统。而工具只是为客户已经运行的工作流增加智能。工具场景也能产生真实收入，实验室也可以拿走它，因为客户并不依赖你作为编排层。高 ACV 通常是系统的信号，因为系统取代了真实的编制人数并据此获得报酬，但这并不是保证。问问自己：如果实验室发布了据称与你直接竞争的产品，客户是否仍然需要你的工具。如果是，你在构建系统。如果不是，你就是一个工具——即使你的 ACV 很高。
对冲基金 / P&L 测试：实验室的表现用基准测试来评判，而“奥兹国的其他地方”的表现则用客户的损益表（P&L）来评判。你的客户不在乎你的模型在 SWE-Bench 或 MMLU 上得分多高——他们关心的是你的智能体是否成交了那笔交易、是否正确修订了合同、是否承保了正确的保单。如果他们执着于工作流的特定结果，而不是通用能力分数，那你就在“奥兹国的其他地方”。如果他们为通用能力付费，那你卖给他们的是他们用一席位 Claude 或 Codex 就能得到的东西。最好的智能体企业将需要像对冲基金一样运作——靠以客户 P&L 衡量的 alpha 取胜，而不是靠基准测试分数。
两者都能（也都会）获胜
我们将看到黄色砖路内外都出现巨大的赢家。模型将继续获胜，因为它们拥有模型本身，并且拥有它们所设计的横向工具的分发渠道。
“奥兹国的其他地方”如果拥有工作系统——即公司实际业务执行的界面，以及从中捕获的流数据——就能获胜。这些公司拥有数据采集、作为行动系统的工作流，以及治理。随着更复杂的工作流在垂直领域走向成熟，它们会复合成客户依赖的一个核心体验。当在位者和新进入者推出新一代模型时，这些公司就成为向客户集成并交付这些模型的层。底层的模型是可替代的；工作系统则不是。
下一代企业软件将在道路之外构建。
如果你在构建它，请联系：jschmidt@a16z.com。
## 相关链接
- [Joe Schmidt IV](https://x.com/joeschmidtiv)
- [@joeschmidtiv](https://x.com/joeschmidtiv)
- [49万](https://x.com/joeschmidtiv/status/2059642470334677472/analytics)
- [大规模前置部署合资企业](https://techcrunch.com/2026/05/04/anthropic-and-openai-are-both-launching-joint-ventures-for-enterprise-ai-services/)
- [Prabhav Jain](https://www.linkedin.com/in/jainprabhav)
- [11x](https://www.11x.ai/)
- [Aman Gour](https://www.linkedin.com/in/amangour)
- [FurtherAI](https://www.furtherai.com/)
- [工作系统](https://a16z.com/services-led-growth/)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年5月27日晚上10:26](https://x.com/joeschmidtiv/status/2059642470334677472)
- [49.02万次浏览](https://x.com/joeschmidtiv/status/2059642470334677472/analytics)
- [查看引用](https://x.com/joeschmidtiv/status/2059642470334677472/quotes)
---
*导出时间: 2026/5/28 10:19:18*
