# 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 精神错乱（AI psychosis）。有些人断定，想要避免沦为永久底层阶级，唯一的出路就是进入大实验室，或者去前沿领域深耕机器人、硬科技等业务——理论上，只要是“实验室触不到”的领域都可以。如果每一款软件都即将被吞噬——要么是被 Codex 或 Claude 直接吸收工作流，要么是被某个未来的模型直接取代，让你现有的产品变得毫无必要——那就快跑吧！
听着，我和几乎所有人一样，都是个 AI 极大主义者（maximalist），但我认为他们只说对了一半。实验室确实正在蚕食应用层很大一部分表面。但“应用层”并不是一个均质化的机会。正确的判断标准在于，你是在黄砖路上，还是在奥兹国的其他地方。
所谓黄砖路，是我们用来指代实验室正在行进的路径的简称，也就是它们投入了非凡资源的地方。实验室最适合解决代码生成、写作或图像生成这类问题，是因为这些问题会随着原始模型能力的提升而改善：花在预训练和后训练上的每一分钱都能提高产品质量。与此同时，奥兹国的其他地方则充斥着更复杂、往往是垂直领域的问题，这不像给商业用户一个配备了标准工具和计算机使用能力的通用工具那么简单。其价值较少来自于底层模型的原始能力（尽管这依然重要！），而更多来自于围绕模型构建的脚手架，正是这些脚手架使得输出在特定行业内变得值得信赖、合规且可落地。
我们正在实时目睹这一进程，正如 OpenAI 和 Anthropic 实际上在向市场表明，它们无法仅凭一个通用的 AI 助手解决所有问题。它们已经宣布了大规模的前瞻性合资企业，围绕为企业配置和定制其模型来构建完整的公司。如果你认为下一次模型发布就能解决所有问题，你就不会向这些项目投入数十亿美元了。
所以，如果你想通过构建 AI 应用发财——那就避开黄砖路，去奥兹国的其他地方建设吧。以下是我们在实际操作中学到的东西，以及我们一些投资组合的创始人们总结出的经验之谈。
## 黄砖路
如果你正在创办一家公司，黄砖路是一条最显而易见的路径，但也是最危险的。拿一个高性能模型，插上一堆现成的连接器（比如 G Drive, Slack, Salesforce, Notion, GitHub），然后在此基础上发布某种代理编排层。魔法！
问题在于，这正是实验室正在用 Cowork 和 Codex 做的事情。显然，它们拥有模型，这赋予了它们更好的利润率、控制力，以及对任何下游参与者施加定价压力的能力。但也许最重要的是，它们还拥有定义其产品擅长解决哪些问题的架构选择权。迄今为止，它们在“模型 + 工具调用”的模式上一直颇具匠心，而这正是黄砖路上那些低步骤数的通用工作所要求的。即使某家初创公司能在某种程度上超越 Codex 或 Claude Code，实验室也拥有庞大的分发渠道和 AI 领域最大的品牌光环。
如果你是一家 AI 应用公司，执行着同样的剧本，使用着同样的连接器，没有下层子代理，没有底层配置，也没有分发渠道，那你很可能正走在一条通往虚无的道路上。
## 奥兹国的其余地方
对于初创公司来说，并非全是末日般的景象。在黄砖路之外有着巨大的机会，初创公司在那里拥有明确的路径来锁定客户并解决复杂问题。
这些企业正在构建代理体验，模型被编织进一个复杂的工具、自动化和集成网络中（读作：软件），这导致这些初创公司绝大多数默认都是垂直领域的。它们可以专注于多步骤、多参与方的工作，拥有针对角色和特定垂直任务的子代理，这是 Anthropic 和 OpenAI 无法通过通用平台触及的：跨系统收集上下文，然后路由给多个在不同阶段必须进行审批的人员。这通常涉及一个或多个遗留系统，往往需要确定性的结果（不容许模棱两可），有时还与某些宝贵的业务结果绑定。实验室深知这些问题价值连城：这就是为什么它们要建立自己的外包配置商店，也是为什么整个上层市场的强化学习业务类别会存在。
## 为什么奥兹国的其余地方不会被巫师（Wizard）占有
针对上述观点的回应会是，到目前为止，押注模型/实验室不会改进一直都是一笔糟糕的赌注。它们很可能会持续进步，并最终蚕食这些应用层业务所服务的市场。
实验室肯定会进步，但我认为奥兹国的其余地方有几种方法可以随着时间的推移保卫自己：
**数据与学习飞轮：**
你内化的很多东西并不存在于任何训练集中——未成文的行业规范、未记录的标准、存在于从业者脑海中的部落知识。这些都不在公共网络上。没有任何训练算力的投入可以替代身处这些知识实际存在的工作流之中。这里有两个叠加在一起的飞轮：跨客户飞轮（随着你看到同一问题的更多变体而积累的模式）和客户内飞轮（特定决策背后的“为什么”、未言明的例外、公司自己的经验法则，这些只有通过与系统的真实互动才能显现）。
即使客户数据不能跨客户使用，应用公司也能够利用跨客户问题类型的模式识别，并用它来为未来问题构建正确的架构。一家让其代理经历过一百次法律红线审查、一千次保险承保周期或一万次 SDR（销售开发代表）活动的公司，已经内化了问题的形态，这是新入局者仅靠首次启动一个代理所无法复制的。
原则上，通用代理也可以构建相同的学习基础设施。它之所以没有这样做，除了纯粹的关注点原因外，还在于 UX：捕获这类知识完全取决于你提供给用户的工作流界面，而垂直领域的玩家可以围绕其工作流确切需要呈现的内容来塑造这些界面。通用工具则做不到。评估集、标记输出和边缘情况分类法可以叠加成一个垂直领域特定的数据飞轮，这可以推动微调，而没有可比生产暴露的新入局者无法生成这种微调。这是否可能取决于数据权利、累积的生产暴露量以及客户合同的结构，但无论如何，模式识别都会不断积累。
**管理模型可变性与复杂性：**
实验室已经在内部进行路由了——针对不同的请求使用不同的模型类别，底层使用集成模型。但它们无法跨供应商路由，无法针对特定子任务评估竞争对手的模型，也无法在实际上表现最佳的狭窄部分使用开源微调模型。奥兹国的其余地方的公司会为每个子任务在整个模型市场上选择正确的模型，而不仅仅是其母实验室提供的模型。它还做着没人愿意做的工作——在每次有新模型发布时重新运行评估、针对客户的边缘情况重新校准提示词、在不破坏生产环境的情况下推出——实验室不会代表客户做这些；它们卖给你下一个模型并告诉你去迁移。奥兹国的其余地方的公司则吸收了迁移的痛苦。客户得到的是整个市场上可用的最佳智能，以及每次升级时的连续性。
**成本优化：**
让每个查询都跑一遍 Opus 4.7 是通往负毛利率的最快途径。最优秀的奥兹国其余地方的公司会跨模型层级进行路由——前沿模型用于最困难的任务，中端模型用于大部分任务，当它们赢得使用权利时，针对其客户关心的狭窄工作使用较小的定制或微调模型。有些公司现在在此基础上进行自己的后训练，针对其客户关心的狭窄切片进行优化，并以次前沿 API 调用成本的一小部分来提供服务。实验室定价的是地板：$X 价格能买到的最低智能。奥兹国的其余地方的公司销售的是相反的东西——工作流实际需要的特定智能水平的最低美元成本。只有当你确切知道每个子任务需要什么级别的智能时，这才可能实现，而实验室在结构上无法知晓所有垂直领域的这一情况。这直接转化为更低、可控的结果定价。
**治理：**
成为客户在该垂直领域运行 AI 的控制平面——即权限、审计、代理被允许做什么、以及代理实际做了什么——这一汇聚点具有相当大的价值。该控制平面由用例特定的护栏构建而成，这些护栏在不同行业和工作类型中看起来完全不同。因为它们拥有工具、工作流以及代理端到端接触的数据，它们能够以通用工具难以企及的方式提供确定性结果。它们也是为最终买家吸收监管复杂性的实体——法律领域的 FRCP 和律师协会规则、医疗领域的 HIPAA、金融领域的 SEC 和 FINRA、各州保险法规等等。通用参与者如果不一次性变成一百个不同的垂直领域，就无法令人信信服地做到这一点。CIO 们希望有一个合作伙伴在合同上声明他们正在为自己提供的代理处理合规性。
所有这些都归结为同一件事：专注。这可以是一个垂直领域（保险、法律、会计），或者是一个深入执行的功能（销售、客户支持、金融）。无论哪种方式，这项工作都需要一个团队埋头服务于特定的客户群体——其工作流、边缘情况和法规。实验室并非为此而生。它们必须无处不在，为所有人服务，这正是它们最初建造黄砖路的方式。同样的权衡使它们无法进入奥兹国的其余地方——你可以同时无处不在，也可以专注于把一件事做到极致。无法兼得。
## 以销售为例——来自 11x 技术型 CEO 的实用建议
在实践中你应该如何看待这个问题？以下是 11x 的 CEO Prabhav Jain 的一些实用建议。
**专注于结果**
构建一家对实验室具有抗性的公司的战术路径，就是仅仅从客户真正关心的特定结果出发。对我们来说，那就是帮助企业获得更多销售线索。从那里开始，问题就变得具体化了。我们要端到端拥有哪些真正能推动销售线索的活动？将每项活动分解为任务。哪些任务是代理性的，哪些不是。哪些需要深奥的领域洞察，哪些不需要。实验室也会发布工作流，但当工作流涉及许多步骤、杂乱的输入、难以解释的状态或现实世界的约束时，仅靠更好的模型无法让你达到目标。这项工作落在了老式的软件工程上，而在那个层面上，实验室相对于专注的应用公司没有任何优势。例如，以下是我们处理的一些任务，有些是代理性的，有些则不是：基于自定义信号的潜在客户开发、线索丰富、深度账户研究、从 CRM 获取上下文、特定渠道的消息撰写者、线索资格认证代理以及邮件投递系统。这些都不是你能一键完成的任务，需要深厚的工程能力。
在奥兹国的类比中，关键的洞察在于，任何真实工作流中大约有一半是非代理性的，没有任何实验室优势。它们在编写模型层之下的确定性软件方面并不比你强。而另一半具有代理性的任务，仍然需要你针对你真正想要的结果来调优、训练和约束模型。领域知识通常不存在于通用的训练数据中。这些技能是针对垂直领域或功能从零开始构建的，并在工作流的正确时刻输入给模型。例如，当我们的代理在电话中筛选入站线索时，我们必须接受针对特定行业和角色的“什么是好的销售对话”的培训。这是应用公司的工作，而且会不断累积。
更重要的是，这些技能很快就会过时，因为商业在不断进化，因此你不断进化这些工作流和上下文的能力就变成了竞争优势。举个例子，当我们开始扩展邮件外拓产品时，“AI”撰写的邮件才刚刚开始流行。快进到今天，人们对 AI 撰写和人类撰写的邮件已经有了敏锐的辨别力，关键是，这种情况每隔几个月就会变化。我们的代理必须根据市场动态不断调整，但这正是护城河的构建之处。事实上，尽管这种动态不断变化，但在过去几个月里，我们的正面回复率提高了 4 倍，我们为客户创造了数亿美元的销售线索。
**致力于复杂性高的问题**
复杂问题才是真正释放商业价值的地方。否则，你会发现自己在构建一个薄薄的包装层（wrapper）。
分解任何足够复杂的商业问题，混乱很快就会显现。以下是一个来自 GTM（进入市场）领域的例子，听起来微不足道：如果一家公司已经是你的客户，你不应该联系该公司的联系人。但这绝非易事。也许你的 CRM 中有与该公司关联的域名。对于那些拥有数十家子公司的公司呢？如果 CRM 记录的是母公司的域名呢？如果 Salesforce 中一个过时的匹配字段导致向现有客户的 CRO 发送了陌生推销邮件呢？现实世界的数据是杂乱的。人类对此都很吃力。模型无法神奇地跨越这一门槛。从这种混乱中理出秩序需要针对特定问题形状设计的专用代理，而不是一个指向 CRM 的通用副驾驶。事实上，根据我们掌握的数据，我们意识到我们数据的质量和新鲜度远高于我们的客户，因此默认情况下，我们要依靠自己的数据。
**护栏不仅仅是为了防止坏事发生。这正是客户付钱给你的原因。**
护栏被严重低估了。即使在同一产品内，每个用例也需要自己的护栏。对我们来说，一家受监管的金融服务客户所需的保证与一家中端市场 SaaS 客户不同，这些保证会落实到代理被允许如何撰写、可以联系谁、可以接触什么数据、在通话中可以说什么，以及如何记录每一个决策。
一刀切的系统在这种差异面前会崩溃。护栏必须针对每个用例构建，针对每个客户配置，并持续审计，这项工作完全由应用公司承担。这就是为什么我们配备了 FDE（前端工程师）和技术部署策略师，他们需要针对每个客户的要求进行调优。举个例子，我们与一家财富 1000 强机构合作，通过语音向其庞大的 SMB（中小企业）客户群进行经许可的外呼。最初的几次迭代接通率很低——我们必须快速迭代，学习如何让这类特定受众在通话的前 10 秒内产生互动。SMB 企业主的行为模式与大型 B2B 买家或消费者截然不同。我们现在一天为它们生成的销售机会，超过了它们整个销售团队该板块一个月的业绩。
## 以保险为例——来自 FurtherAI CEO 的实用建议
销售是一个例子。保险是另一个，它从不同的角度阐述了同样的观点。以下是 FurtherAI 的 CEO Aman Gour 的看法……