Palantir CTO Shyam Sankar 与全球商务负责人 Ted Mabrey 的访谈

说实话，Palantir 并不是我此前报道过的公司。我写过关于你们 S-1 的文章，稍后我们也会谈到这一点，所以我想先说明，虽然 Palantir 是一家上市公司，但我会把这次访谈更多地当作我做过的创始人系列访谈之一。我个人目前处于一种探索模式，想更好地了解你们的业务，所以你们可能会稍微轻松一点。我并不是要把你们逼到墙角，但我确实对你们构建的东西非常感兴趣。

Shyam，你不久前联系我谈你们的业务，我也听到了很多好评。我确实回头看了几段提到我的投资者视频，这显然是让我愿意参与的好办法。但我想回到更早的时候，回到起点。Shyam，你说过你是第 13 号员工，对吗？

SS： 没错。

Ted，你是什么时候加入公司的？

TM： 2010 年。

2010 年。好的，Palantir 正式成立于 2003 年，我记得虽然对外报道是 2004 年。那时候是什么样子？当时向你展示的 Palantir 愿景是什么？那个愿景延续到了今天，还是发生了转变？那是在产品之前、一切之前，是什么让 Shyam Sankar 当年决定加入的？

SS： 长期以来始终如一的，是我们想要实现的目标所具有的雄心。在 9/11 之后的那个世界里，一群人聚在一起说：“我们为什么要争论隐私和安全哪个更重要？这两者显然都重要。我们如何构建能让你同时拥有更多两者的技术？”这不是一个简单的 Web 应用，也不是一个微不足道的技术愿景，正是这一点让我深深投入其中。

在这段历程中，我们必须构建的技术、我们不断提升和扩展的雄心——虽然最初确实非常专注于政府，但技术能够对我们这个世界赖以运转的机构的运作方式产生深远影响，以及这种影响为何会从政府延伸到商业机构，我认为在后金融危机时代这一点非常清晰，这一直以来都惊人地保持一致。

你提到了雄心的提升，并将其置于从政府起步的背景下。显然，围绕 Palantir 的巨大增长故事，我认为很大程度上是围绕你们的企业业务，我们稍后会谈到这一点。但你曾谈到过，Palantir 在很多方面是最“重”的重型初创公司，你觉得自己必须从上到下构建整个系统才能兑现承诺。这个想法是最初愿景的一部分，还是在你弄清楚需要做什么的过程中逐渐扩展出来的？

SS： 正如 Ted 有时所说，他会问：“你要对什么负责？”你要对所构建软件的某种狭义定义负责吗？因为我们的思考方式是，我们的成功就是客户的成功，我们根据实地经验上真实有效的情况，不断扩大我们认为软件需要做的事情。你认为有效的东西实际上没有效果，所以如果那在我技术栈的下游，我就必须把它掌控起来，因为我需要它能正常运作。

如果你想帮助士兵从战区归来，没有人会说：“嗯，我用的是 Gartner 象限顶部的软件。”标准要绝对得多，那么你该如何追求——从“你在学什么”的角度来看，它变得越来越厚实，就是一个软件的波将金村。并不是说我认为这些软件真的无法编译，显然不是，而是它根本无法满足企业的需求，而当你身处一线时，你会发现所有这些秘密、所有这些真相，它们不知怎么就在组织的官僚体系中迷失了——什么有效、什么无效、为什么。

那么有没有一个特别的时刻，发生了真正的转变，比如：“好吧，我们处于后 9/11 时代，人们说你必须在安全和隐私之间做选择。我们认为我们可以两者兼得，我们要创办一家能实现这一点的初创公司。”在构建它的过程中，你是不是会说：“好吧，我们实际上需要构建这个，需要构建这个，需要集成那个。”有没有一个顿悟时刻，让你有了这个概念——你现在在所有财务报告的开头都使用这个说法，即你们是企业的操作系统。当然，现在显然还是政府时代，但有趣的是 S-1 文件中用了这句话，但它位置靠后，并不是主打内容。这是后来才出现的，还是从一开始就有“不，我们必须成为一切的接口”这个想法？

SS：我认为其中的关键部分是真正意识到，我们构建最初产品时预设了客户的数据已经完成集成，这样我们才能专注于数据集成之后的分析工作。我觉得那种创始创伤就是意识到，实际上每个人都声称他们的数据已经集成，但其实完全是一团糟，而我们业务中更有趣、更有价值的部分，其实是开发让我们能够将数据集成产品化的技术，而不是让它变成一个五年都没有尽头的咨询项目，这样我们才能去做我们当初创业真正想做的事情。

所以分析才是目标，但结果发现你实际上必须先打造自己的镐和铲，自己的镐铲工厂，才能开始做分析，而这从长远来看反而更有价值。

SS：没错。

嗯，就这个转变而言，这说得通。

Gotham 与 Foundry|

那么请给我讲讲，Gotham 是什么？我们稍后会谈到 Foundry，但我想先彻底弄清楚：这个产品是什么？谁购买它？它用来做什么？

SS: Gotham 是面向国防情报组织的操作系统，它让这些组织能够整合多模态数据。这些数据可以是卫星图像、视频、结构化和非结构化文本数据、传感器数据，将它们融合在一起，形成一个通用作战图景。我如何了解当今世界实际正在发生的事情，并将其用作——你可以把它想象成一个单一的数据面板，让你拥有一个“单一玻璃窗格”，然后据此向前规划。也就是说，基于当前正在发生的情况，我们可以做些什么来在世界中创造我们想要的效果？

我们俩一直在用“操作系统”这个词，不过这个词是从你那里学来的——这是你们需要进去和其他国防承包商合作，在他们之上构建某种东西，还是你们只能靠自己摸索？你们是如何从单纯的分析软件走到这个操作系统理念的？

SS: 这其实是 Ted 为这门生意所发展的核心理念之一，也就是对决策的执着。不是从数据出发——我有什么数据？我如何把它们整合起来？——而是真正审视一个机构或一项行动，把它看作一系列相互关联的决策。我如何为这些决策带来更好的情报、协调和复利效应，并把它们串联起来？要做到这一点，我需要什么？这就是“单一玻璃窗格”变得非常重要的原因——这是我做决策的地方。那么，我如何优化进入这个决策的信息？然后，我如何帮助你理解这些决策在上游和下游产生的后果？

那还只是单人模式，但那并不有趣，真正关键的是正在同时发生的大规模多人决策，而你要让技术来驱动这种协调。这并不是因为 Shyam、Ben 和 Ted 恰好彼此认识，也不是因为我们制定出了什么 SOP（标准作业程序），而是因为我的决策所产生的数据正在改变我做事的方式。

我们常常这样描述：大多数分析系统把数据当作“废气”，就好像废气是交易系统产生的副产品，也许你会去分析它，但实际上数据是燃料。如果你反过来想：“这将为我的业务运营提供动力”，那么你对技术栈的看法、对操作和使用软件的人员角色的看法会有什么改变？我认为“操作系统”这个比喻在这里非常重要。这不是一个终端仪表盘，也不是分析工具，它实际上关乎决策，而且你会有很多次机会做这类决策，你希望明天针对同一问题的决策比上一次更好。所以如果你在想：“看，我处于一个学习循环中”，我该如何运用手头的一切，让自己每天都在这方面做得更好？

TM：可以说，用 Shyam 的话讲，这是创业的“创伤”，数据是割裂的。我认为第二个创伤是洞察的实用性，或者说缺乏实用性。所以首先要做的是把数据整合起来，我需要建立单一事实来源。标准的流程是“获取数据、组织数据、分析数据、基于数据采取行动”，那个看似存在于最后一步的鸿沟——“一旦我了解了某件事，我就能有所行动”——但接着你会想：“这个洞察如何部署到一个多人协作、复杂的价值链中？”

我们一次又一次地发现，一个洞察的假设价值，当部署到真正做决策的一线人员的实际运营中时，中间存在巨大的鸿沟。所以我们真正需要回答的是：在决策点上需要什么样的信息智能？我们需要什么样的信息框架？为什么现有的底层数据无法提供这个框架？然后，当你拥有这个框架并做出决策时，如何更智能、更自动化、更协作、随时间不断复利地做到这一点？

那你们是怎么做到的？理论上我能理解这一点：你现在做了一个决策，记录下你做了这个决策，你可以追踪其结果，看看发生了什么或没发生什么。这仅仅是闭环的问题吗，还是其中有沟通的层面？这一切听起来很美好，但在军方或国家安全机构中，它实际上是如何体现的？

TM：对我们来说很幸运，我认为其中存在大量的共性。无论你是国防领域的操作人员，还是想弄清楚如何钻探地下矿井，或者如何更高效地制造飞机、发现新药、配送疫苗，无论是什么场景，现有软件栈在帮助操作人员做决策方面失效的地方，其实有很多共性，所以我们把这看作是工作流复杂程度的层层递进。

这个工作流的第一部分是：“我是否对做出本地决策所需了解的一切拥有360度的全面感知，并且有及时的数据以我能理解的方式呈现在眼前？”如果我是菲亚特克莱斯勒或空客工厂车间的一名蓝领工人，这个视图将与一位制定长期战略决策的CEO截然不同。但会有大量数据来自CRM、传感器数据、ERP等等。我能否在AI的意义上获得这些数据，也就是那个上下文窗口，恰好包含我做出该决策所需的上下文？

这一切都很好，因为它让我不必与许多不同的系统搏斗、在不同屏幕之间来回切换、用Excel宏创建自己的本地事实来源、在数据仓库中建立不同的视图等等，而是在事务层面直接获得我所需要的东西，以及随之而来的全部上下文。

接下来，我希望在执行过程中变得更加智能。所以我想把一些事情自动化，比如一些简单的事情：“我该如何确定哪件事应该优先处理？”要做好这种优先级排序，我需要那个整合的上下文窗口，然后我还需要能够部署模型和智能，以及从简单代数到人工智能模型的各种规则，来帮助我驱动决策的优先级排序。

所以，如果我对客户服务工作流有一个整合的视图，那么在我掌握完整的产品使用情况以及关于该客户价值的所有信息时，当下最紧迫的客户是谁？因此，当我们思考360度全面感知时，现在要在其上叠加智能。也许用一个具体的例子来描述最恰当：“如果我运营一个海上石油平台，我需要油井360视图，但随后我还需要告警功能，当从井下传输数据的光纤数据流显示出有出砂风险时能发出警报。”

在我看来，你想表达的是，把这些原本分散在各个不同系统中的大量数据，基本上让它们在当下变得更加实时可访问。这就是你不得不跨越的鸿沟吗？

TM： 那是第一层的鸿沟，就是跨所有不同系统的实时数据，以对操作人员可用的上下文呈现出来。但接下来我还需要两样东西：我需要能够将模型整合到那个视图中，这样它就不仅仅是数据的呈现，我还需要所有能由模型注入其中的智能，所以这必须是同等重要的。然后至关重要的是，还要能够对我所掌握的信息采取行动。那么，我如何能从同一个应用程序中真正在现实世界创造物理层面的改变？我不是先看着某个东西，然后再琢磨如何在SAP中实现它。我是在执行、编写和行动。

明白了。这就是你之前提到的那个巨大的鸿沟。好，这说得通。我认为这是一个很自然的过渡，转向 Foundry。Foundry 的历史是怎样的？所以这是你们的两个主要产品，Gotham 面向政府，Foundry 面向企业。帮我理解一下，它们是完全不同的软件栈吗？有很多共同点吗？还是说 Apollo，你们的部署系统，才是它们的共同点？Foundry 从一开始就在愿景之中吗？还是说这是“看，我们的创始理念是解决这个政府国家安全问题，结果发现我们有这种能力在其他地方也很有用”？我问了一大堆问题，但基本上就是给我讲讲 Foundry 的故事。

SS： Foundry 虽然始于商业领域，但如今已经发展壮大，你可以这样理解：Apollo 位于整个栈的最底层，是生产基础设施，Foundry 在其之上，算是全栈式的，Gotham 则构建在 Foundry 之上。

明白了。所以 Gotham 是 Foundry 针对政府领域的具体体现。Foundry 在某种程度上是操作系统，而 Apollo 是基础设施？

SS： 是的。我们可以说，Foundry 始于商业领域，几乎是加倍押注于这样一个认识：数据集成是行不通的，你能获得的工具可以在第零天让它运转起来，第一天也能运转，但你要如何应对多年来数据中宇宙般的熵增，以及随之积累的东西，你需要什么样的工具？所以这一切的核心是：我们如何像对待代码一样对待数据集成？我们如何把越来越多的企业内容当作代码来对待？我们如何将 Ted 刚才谈到的那个组件产品化，它不仅能让你将数据抽象并整合到一个语义层中，还能将你的模型绑定到这些数据上？然后在此基础上构建集成的决策工具，让客户既能满足底特律汽车厂工人的需求，也能满足海上石油工人或医院运营人员的需求。这就是它的起源。

但它可以说是从栈的底层开始的，随着我们的认识不断深入，我们持续构建：“我可以处理非常复杂的实时数据集成，让你获得这种一级的 360 度感知”。现在我如何为你提供更多工具，将实时智能洞察引入其中？现在我如何为你提供一个数字孪生，让你能够进行动态模拟和反事实推演——“哦，如果我做了这个决定，我如何将其级联下去以理解其后果？”然后反过来，让你能够以编程方式自动生成场景。“这是我可以做的十个决定”，让我逐一推演它们的后果，然后让人类操作员从中进行选择。

然后，正如 Ted 所说，真正做出决定，并让它反馈到底层。

TM: 更关键的是，当你基于整合视图做出决策时，你同时也在创建一个数据资产，让你能够在它之上进行学习，因为我有了这个已执行的操作，也有了当时世界上正在发生的所有事情的上下文信息，我现在就拥有了训练数据资产，可以基于我实际做出的决策的上下文来训练模型，而不是基于我事后构建的某种聚合分析视图。

Foundry 操作系统|

嗯，这说得通。Shyam，你提到 2017 年是 Palantir 的关键一年，而你说尽管从财务角度来看，那可以说是公司历史上最糟糕的一年。为什么会这样？跟我讲讲 2017 年对 Palantir 来说的这个转折点。

SS: 那正是 Foundry 真正推向市场的时刻，我们得以让商业领域的客户把收入业务迁移到 Foundry 之上运行。

所以在此之前，只是针对所有这些不同客户做的一堆定制集成和定制部署？

SS: 是的。有一段时间我们在试验产品应该是什么样、它在技术栈中处于什么位置。可以说，我们当时构建的那些东西后来都变成了 Foundry 中的应用。Foundry 为我们提供了基础设施，让我们能够真正扩展所做的事情，不仅在商业领域，还覆盖了我们所有的政府客户，并且让我们具备了快速推进的能力。

TM: 我认为同样关键的是，既能快速推进，又能对同样的结果负责。所以在 2017 年，我们得以整合到 Foundry 上，同时也实现了 [Airbus] A350 产量 33% 的加速提升。那么，你如何推进高效前沿，精确构建人们解决其确切关键问题所需的东西，同时又建立在同一个共同基础之上，让其中存在共通之处，可以用于 Airbus、PB、Swiss Re 或其他任何客户？

所以基本上，这正是 Foundry 成为你所说的操作系统的关键所在。你谈到过企业这个概念，谈到它们产生 alpha、产生 beta 的理念，也就是每个人都想构建自己的定制软件，因为那会给他们带来优势，别人没有那样的软件，但在某种程度上，有很多事情是每个人都必须一遍又一遍重复去做的。如果把操作系统放在计算机的语境下来看，它覆盖整台计算机，但计算机有很多台，那么是什么横跨所有这些计算机？在一个非常简化的层面上，这似乎就是对操作系统本质的一种重新思考。

我实际上认为与微软有一个有趣的类比。微软专注于生产力领域，其中一个问题是 SaaS 爆发式增长，有各种不同的单一解决方案，但你如何真正把它们整合到某种共性之中？我认为微软在这一点上做得非常好，我认为这一点被低估了，即做得平庸的整合也胜过完全没有整合，我认为这一点被低估了。

我听到的、我脑海中的类比——如果我理解错了请纠正我——是 Palantir 在做类似的事情，但基本上是面向工业企业的，而且是大规模的。你谈过很多石油公司和制造客机的事，这与把聊天客户端和 Word 文档拼接起来有点不同，它实际上是在 SAP 和 ERP 系统以及类似系统的层面上。抱歉，我有点絮叨了，我只是想确保我对 Palantir 的理解是正确的，这样思考对吗？

SS：完全正确。我们的雄心是打造一个操作系统，让世界上每一个机构都能做出它们所做的每一个决策。当你想到这一点时，可以从两个维度展开。

一个是它们存在于价值链之中。从供应商的手到客户的手，会发生很多决策——它其实不是线性的，而是一张决策之网——这是一个维度。另一个维度是战略与运营之间。也就是公司高层想要做什么，以及将其转化为行动的过程。这两者往往相当脱节，我认为这正是我们如此专注于 alpha 的终极体现。如何交付 alpha 而不仅仅是 beta？答案就是连接战略与运营。这样，当高管层想要达成某个目标时，就有一个方向盘将其联系起来，并为开始做出的决策提供信息，从而形成一个反馈闭环。

那么为了确保这一点清楚，像 SAP 这样的公司相对于 Palantir 处于什么位置？你是想取代它们，还是在它们之上叠加一层？我用它们作为所有这些存在了很久、深度嵌入这些企业的工业级软件公司的代表。Palantir 相对于它们处于什么位置，是要推倒重来、彻底替换，还是怎么运作？

TM：我认为可以从两个方面来思考。一个是，你拥有所有这些工业级核心交易系统，然后我们会问一个问题——这也是我们在与客户开始合作时会问的问题：“你的决策中有多少是通过这些系统做出的？你每天有多少资源是通过这些系统分配的？又有多少是绕过这些系统分配的？也就是说，它们在哪里失灵了？”

第一件事是那些唾手可得的成果：“理论上，这是我的 ERP 应该做的。但实际上，我是通过 Excel、电子邮件、电话来做的，还有我必须做的那些定制化，以及那些根本无法撤销的定制化”。那么，我该如何面对这样一个事实：这个 beta 版本、这个“符合我的系统”的设计，并不是每家企业实际的运作方式？你如何提供灵活性，既能使用那些成熟、优秀、能提供高度自动化的功能，又能在需要贴近客户、需要智能来完成任务时不至于失灵？所以我认为这就是唾手可得的成果。

更高层次的问题则是：“那么，我该如何反映我经营业务的方式？”企业在其自然状态下，本来就是在思考如何分配稀缺资源。为什么我必须与现有的软件架构搏斗，去思考什么在我的 CRM 里？什么在我的 PI Historian 里？什么在我的 ERP 里？什么在我的 MES 里？我造飞机、造汽车，我希望能够通盘思考这些事情，并做出能够统筹整个价值链的决策。

所以，当我要调整生产计划时，我会把那个时点市场上的情况纳入考量，并以企业的自然状态来看待我的业务，这样我就能以高管的身份、按照我思考业务的方式来与它互动，而不是花三个星期去争取一份报告，来告诉我事情在我实际想要运营它的框架下究竟进展如何。

是的，我对我的 Teams 类比感觉非常好，因为我一直强调的一点是，微软之所以能在市场上把很多这类 SaaS 公司打得落花流水，是因为很多公司忘了自己不是重点。人们并不是为了买、比如拿 Slack 来说，聊天软件而来的。他们是为了真正经营自己的业务，只是在寻找能帮他们完成工作的东西。所以当你说“看，我是在造飞机”这样的话时，真的会引起共鸣。

服务与可扩展性|

我们来聊聊这个。关于 Palantir，我发现非常引人注目的一点是：传统软件方面，你不仅仅是购买软件，然后你还必须找系统集成商，或者也许你直接与某家公司签约，他们有一个服务部门来实际实施和安装软件。那是在软件合同之外的一份单独合同。Palantir 现在还是这样吗——没有安装合同，这只是服务的一部分？如果你签约 Palantir，Palantir 会进来帮你把软件装好，现在还是这样吗？如果是这样，你们这样做能得到什么回报？

TM: 是也不是。我认为这有两个有趣的维度。其一是我们的 FDE（前沿部署工程师），这个 FDE 模式，我们视之为我们最大的秘密之一，也是公司最了不起的特点之一。我们认为它最重要的原因在于，它为我们提供了一种问责机制，使我们与客户保持一致，去追问：“软件是否真正做到了客户需要的事情？”不仅仅是有人在使用它，而是我们交付的功能是否真正有效——而不是仅仅符合软件产业综合体对这个功能的期望和对现有技术栈的理解。它真的在起作用吗？我们如何设身处地站在客户的角度走一英里？

当你思考——以及我们对软件的理解——我们为它迄今为止的成果感到自豪。我们认为它交付的成果是实实在在的，但我们认为我们只构建了所需软件的 1%。那么，正如 Shyam 所说，我们如何持续建立一种问责机制，即对客户最终成果负责？这正是 FDE 为 Palantir 提供的核心服务：机构身处一线，坐在那里追问：“它真的起作用了吗？它真的产生了影响吗？”

同时，我们希望以一种能随时间实现最大程度可扩展性的方式来做到这一点，所以我们一直在投资于——我认为创新反馈将永远是 Palantir 的一部分——但也有其他客户开始提供同样程度的问责能力，不只是安装软件，而是真正有效的成果。所以我们开始看到其他第三方在独立实施软件，而这对我们真正有效的地方在于，这些客户与其最终客户高度一致。例如，我们看到这种模式正在 EPC 工程领域扩展，比如 Jacobs Engineering 这样的公司。他们在做实际的物理工作，他们承接植被管理业务，以防止野火被点燃。对我们来说，他们是实施软件方面非常好的扩展伙伴，因为他们提供了与我们的 FDE 在实施时所提供的同样的问责功能。

SS: 这其中很大一部分也关系到产品反馈闭环，也就是面向客户的部分。在产品方面，我希望软件的实施时间尽可能短，而随后获得的价值能够复利增长。通过承担这一责任，我不会与信号脱节——“我可以构建什么来让速度提高一倍，或者让你能做双倍的事情？”通过将这一成本内部化，我们有了极大的动力去投资于此。而我认为对许多其他公司来说，这里存在一个代理问题：“我这样做是不是在剥夺合作伙伴的某些东西？”

在多大程度上存在产品反馈循环——也就是说，你在做这件事的过程中需要为某个客户构建特定的集成，然后再将其复用于其他客户？

SS： 这当然是其中的一部分。我想你可以说，“看，你可以通用地集成任何数据”，但随着我们越来越接近非常复杂的工业系统，情况就变成“好吧，这些相当特殊”，以及你希望如何建模。我想说，某种程度上更有意思的是：你想要的语义模型是什么，它能帮助你定义从零到产生价值的过程？我如何实现人们试图用这个系统完成的用例，这样我就不只是交付一个数据连接器，而是交付一个更完整的集成链条——“这是让你在几天内获得第一美元回报的黄金路径”？

一个中间件平台|

那么一家公司使用 Palantir 的生命周期是怎样的？听起来这呼应了操作系统的比喻——一开始你几乎是在建造计算机，但我从你这里听到的是，你不会去买一套新的 ERP 系统。你不会买一套新的 CRM 系统，你已经有大量现成的组件，所以 Palantir 最初的目标是把这些组件整合在一起，用你的话说，就是“单一视图面板”。但在某人拥有 Palantir 之后，是否预期今后一切都直接在 Palantir 上进行，这就是终点——当然，他们可能会继续保留 SAP 合同，但未来不会再购买任何其他企业软件——这是你的观点吗？

SS： 不，我们生活在一个“棕地”现实的环境中。不仅长期以来已经存在大量系统，而且他们未来也会希望保留随时转向任何所需方向的灵活性。

那么具体会发生什么呢？假设你已经使用了一段时间，你是一个更成熟的客户，也许你在这个平台上有数万名用户，这时它就成为解决业务中出现的下一个用例或问题的理想场所，因为你所有的数据都已经在数字孪生中完成了建模。你可以访问企业中所有的 AI 模型，而且它已经与你的交易系统打通，所以当你做出决策时，你可以真正将其激活执行，然后你开始积累相互关联的应用——我有一个采购应用和一个生产应用，当我拿到原材料折扣时，我可以非常顺畅地理解这将如何影响我的生产计划。

当然，这其中的“最后一公里”在于，你不会希望这一切都封闭在围墙花园里，也就是说，Ontology SDK 允许你将所有这些数据、所有数字孪生仿真动态带入企业中已有的应用程序。无论是定制开发的应用，还是你只是希望数据流入的第三方应用，这样它就为你提供了一种类似企业缓冲层的东西，这更接近操作系统的隐喻，即“看，我可以构建自己的应用程序，我可以从中提取和写入数据。”

我们的应用程序会处理许多底层细节，比如数据来自哪些事务性系统、如何实际写回这些系统、如何协调和集成这些内容。这就解放了应用程序开发者，让他们专注于自己已经熟悉的业务，并构建能够改变业务的应用程序，而不是与过去做出的任何技术决策纠缠不休。

嗯，因为你们几乎是在充当一个中间件层，因为他们是写入 Palantir。所以问题是，你是否看到不仅是内部业务应用的发展——即一旦 Palantir 部署到位，他们就直接写入 Palantir——而且你是否预见未来会出现一个第三方企业应用市场，这些应用开箱即用即可与 Palantir 协同工作，并默认 Palantir 已经部署到位？

SS：是的，我认为我们已经做到这一点了。也许 Ted，你愿意谈谈我们构建的一些生态系统企业吗？

TM：当然可以。以 SkyWise 为例，这是空客的数字化项目，它在底层使用 Foundry 作为其操作系统。它部署在 150 家不同的航空公司，为他们提供不同的应用程序。其中一个应用用于促进信息的安全交换，让驾驶飞机的人能够将信息反馈给设计和维修飞机的人，同时也让设计和维修飞机的人能够部署预测性维护应用程序——面向 150 家航空公司，并且能够在同一个共同的本体之上大规模地做到这一点，该本体抽象掉了每家航空公司底层系统之间的所有差异。

明白了。那么这些航空公司，它们是与 Palantir 签订合同，还是这一切都是通过空客进行的？

TM：这一切都是通过 SkyWise 进行的。

有意思。

TM：所以 SkyWise，你可以把它看作是空客在 Foundry 之上构建的一套应用程序，他们将其出售给他们的航空公司客户。

有意思。我很好奇，这个产品的市场推广策略是什么样的？这又回到了“臃肿创业公司”的概念，Palantir 正是这方面的典型。你们起步时有一个非常明确的目标——“围绕恐怖主义的国家安全问题”，而当时美国也愿意打开钱包，所以这是一个很好的切入点。但现在你们面对的是这些大型机构，无论是空客、石油公司还是其他制造商，听起来这是一个相当大的要求。你实际上是在要求他们彻底转型整个公司的运作方式，正如你所说，因为仅仅靠公司里某一个团队说“哦，这个很有用，让我们效率更高”是无法获得 Palantir 的价值的。这里说的是“除非一切都上到平台上，否则你得不到好处”。那么你们的推销话术是什么？你们如何切入？如何让公司做出这样的承诺？

TM：嗯，情况并不完全是这样，但从高层次来说，我会这样描述：我们的实施基本上是随着客户的雄心而扩展的。正如 Shyam 提到的，通过内部消化大量成本、加快实现价值的速度，并将数据集成层产品化，我们得以在大幅降低门槛的同时，也抬高了我们能做的事情的上限。举个例子，过去两年我们所做的——

你们积累了大量部署这些系统的经验，所以你们觉得自己可以走进任何一家公司，很快就把事情搞定。

TM：我们的 POC（概念验证）到生产环境的中位时间——注意，POC 结束时你得到的不是一个 POC，而是一个生产级应用，用户在六到八周内就能使用——这让我们可以从一个具体问题入手。这通常需要我们的客户说：“我意识到我有一个现有软件栈无法解决的问题”，否则我们会很被动。但这个问题可以非常具体，是我们在几周内就能解决的。

你们只解决问题吗？如果你们的解决方案涉及集成大量不同的软件，你们实际上是不是为了解决一个问题而安装了一个操作系统？也许它只以一种方式表现出来，或者你们能不能进去说：“看，我们只是有一个 CRM 问题”、“我们只是有……”之类的问题。这个概念验证环节是什么样的？因为不把整套东西都装上，你们怎么开展工作？

TM: 通常，这些事情的起点是：“我意识到自己遇到了哪一类 Palantir 能解决的问题？”而这往往以非常具体的方式呈现出来。我的供应链波动性很大，所以我要么 OTIF 达标率不达标，要么库存爆炸式增长，而利率又高企，我无法应对——这就是我明确知道自己存在的问题。要解决这个问题，我可能需要整合底层的多个不同系统。但我可以用软件定义的方式来切入，可以说：“我可以用一个几周内就能上线投产的应用，开始解决你的库存过剩问题。”

然后他们往往会看到这一点后说：“好，现在我有了这个，我还想整合我的定价策略、我在给自己制造这些问题的过程中如何做合同管理、我如何做生产计划、我如何应对供应商短缺。”但这就是经典的“落地再扩展”策略：横向数据整合，非常聚焦、非常可问责，最终用户生产应用的 ROI 是多少？大多数合作都是这样开始的。

明白了。那么，如果你能在几周内解决第一个问题，是否可以说，你往往几乎能在几天内解决第二、第三个问题，因为数据已经都在那里了？

TM: 完全正确。这正是有趣的地方，也是我们最终真正受制于客户雄心的地方——他们看到这一点后会说：“好，一旦我有了这个，我接下来能做什么？接下来能做什么？接下来能做什么？”

这几乎就像 Palantir 这家公司本身的类比：因为你一开始就怀有宏大的抱负，而一旦你意识到自己在解决所有问题，现在你就可以走进客户，基本上默认地安装你的宏大抱负，因为这就是你解决单一问题的方式，然后随着他们逐渐领会，机会就从那里展开。我听起来有点像粉丝了，但显然，Shyam，你在一些投资者交流中说过类似的话，即从某种意义上说，你们是在聚合问题解决能力，因为你们已经收集了所有数据，它们已经都在同一个地方，因此解决一个新问题的边际成本会急剧下降。

SS: 完全正确。最能体现这一点的一个关键场景就是危机。我们非常自豪的是，我们能够响应、能够帮助我们的客户应对危机，因为解决问题的成本如此之低，你拥有全部的敏捷性，你已经掌握了可以调用的数据，然后你就可以推动它去改变运营、改变决策方式。

TM: 我怎么知道新冠疫情的情况？首先，我没有任何一个横跨 6000 家医院的一体化全国数据资产。接下来，我需要知道个人防护装备（PPE）的情况，我需要弄清楚如何分配 PPE。然后问题不再是 PPE，而是疫苗问题。我如何针对当前具体问题的具体表现不断进行迭代？而且在这些危机中，问题往往是滚动的，今天的问题和明天的问题是不一样的。

但如果所有数据都整合在一起，应对起来就会容易得多。这完全说得通。市场推广的反面是流失，一旦一家公司部署了 Palantir，还会有人流失吗？是不是到了某个时候就会说：“你解决了我的问题，花了好多钱。是的，你干得不错，但我不确定我们以后还能负担得起”？还是说这是世界上最强的锁定效应？

TM: 我们真的没有兴趣和不想与我们合作的客户合作。就像我说的，我们真的还处于起步阶段，我们需要那些迫使我们加速创新、推动我们产品未来方向的客户，这只有在我们与客户高度一致时才能实现。所以如果我们做了什么造成不一致的事情——

需要说明的是，锁定本身并不是坏事。我想“锁定”这个词听起来不好，但你可以把它重新表述为一套可用的 API，完全接入我现有的数据，并且是构建下一步东西的显而易见的选择。操作系统是地球上最好的锁定，因为它对所有参与者都有利。从计算机运营、硬件、开发者到用户的角度，它都极大地扩展了市场的可用范围。所以这不是批评，至少是一种赞美，也许我们只是自然而然地觉得，哦，锁定，听起来不好。

SS: 嗯，我会说它很有粘性。

说得对，粘性。

SS: 这是一个有粘性的命题，当然客户对此很精明，他们能认识到——有时欧洲人称其为决策的可逆性——所以一切都是开放的。你必须与他们一起走过这段旅程去理解，也就是：“看，如果我想退出，我能做到吗？”所以我们对此非常投入，而且正如 Ted 所说，我们以此标准要求自己，但我们想成为那个地方——解决下一个问题最合理、成本最低的地方。我们要如何在这方面持续创新？

解决难题|

你认为为什么其他公司没有采取这种在某些方面全盘包揽、而不是只做单点解决方案的做法？

TM：这真的很难，非常难。而且在每个维度上都很难。你必须为结果负责，你必须让那些本可以在硅谷享受舒适体验的软件工程师，愿意去前线部署，或者部署到那些充满庞大官僚机构、数据权限访问等各种问题的财富 500 强机构中。所以第一，你得激励真正有才华的人去做这件事，这非常难。

然后你还得弄清楚如何打造真正能解决问题的产品，这本身就是一道实质性的难题。接着你还要想清楚，如何在解决这些问题的同时，创造出横向的、能为下一个你尚未解决的技术问题承重的基础技术，这会带来很多内部摩擦。我怎么让 FDE 和那些职责不同的开发人员协作？当那个开发人员要为 350 个不同的客户解决问题时，我怎么把他的工作放到我的关键路径上，去解决客户的关键需求？这非常难，我们内部也不总是能做对。我想说，我认为我们是全世界做这件事最出色的，但我们做得很糟糕，因为这实在太难了，我们在通用性与具体性之间的把握总是失衡。而且这种做法非常非传统，所以你总是会受到批评，而这些批评往往与我们认为自己正在做的事情毫无关系。我们甚至不在乎那些批评，但这需要极大的纪律性和投入，才能让自己与客户完全保持一致。

你觉得现在到了有趣的部分了吗？

TM：我们是乐观的，我想说，也许现在比以前更有趣了。事情依然一直很难，但我认为现在有一件事变得非常有趣，那就是随着大语言模型的有效性出现，或者说是跨越了某个临界点，我们正看到市场正在发生转变。

我们马上就聊这个，但关于动力还想再问一个问题。在留住这些工程师来构建这个庞大系统方面，这一点有多重要？你只要想一想，我想你只需要想两分钟，就能想象出你不得不做多少工作、构建多少东西。那个最初的核心动力因素——我们是在为国家安全做这件事——有多重要？

[CEO] Alex Karp 在 S-1 文件发布时发表了那封信，直接把立场摆了出来。“看，我们相信西方治理模式，我们与民主国家站在一起，我们不会向中国出售产品，我们不认同硅谷那种一群高管坐在办公室里对别人发号施令的愿景”。那封信只是为 IPO 写的一篇漂亮文章，还是一种持续的动力？它是否与你近二十年来坚持下来并构建这套系统的能力有关？

TM: 我们俩或许都应该就这个问题给出自己的回答，但我的想法是：“我认为没有这个，你根本不可能做到。”

SS: 这至关重要。

TM: 这是根本性的，而且之所以根本，是因为它无处不在。我在公司的商业部门工作，但这种使命感导向同样适用于所有地方。当你在一家以使命为导向的公司工作时，你就会承担起客户的使命。无论那是有人在蒙古建矿，还是在瑞士研究如何为保险定价，你都必须认同那个使命，并相信在那个使命中，西方的成功就是经济的实力，就是雇佣人才的能力，就是持续把创新真正推动到经济核心的能力，而不仅仅是在硅谷，等等。没有这个，你根本不可能接受这种痛苦。

SS: 看看 Palantir 员工的留任时间，很奇怪，来过这里的人往往会留在这里并一直待下去，我认为很大一部分原因是：“看，在世界上所有我能参与改善、能够触及的事情中，以及我能做到的事情的多样性上”——这就是你加入这家公司的原因。但这也是你在经历巨大痛苦时继续保持动力的方式：你要应对客户的官僚作风，应对世界的不完美，而且你不能像大多数科技公司想做的那样，放下玩具一跑了之。你拥抱这种复杂性，并根据你能够带来的改变来定义拥抱它的回报，因此这推动了整个公司及其人才的协同一致。

Palantir AI

好了，现在我们进入 AI 部分。我并不是故意把它放在后面，我确实认为先铺垫更广泛的背景很有意思。Shyam，你上周刚做了一场主题演讲——我想等这篇文章发布时应该是几周前了——谈到了你们的新 AI 平台。给我讲讲吧，给我做个推介。我想你们显然已经接入了所有这些数据，为什么是现在？为什么是今天？我的意思是，为什么不是以前？2023 年有什么特别之处，让它到了该问世的时候？

SS: AIP 是一套核心的基础技术，它真正能让企业把 LLM 引入其私有网络上的数据，让他们的软件把 LLM 连接到企业的工具、他们的 AI 模型、他们的地球物理模拟器，连接到已经存在的、他们已经投资的技术，并且以一种受控、有治理的方式来实现，从而让他们最终能够信任它并符合法规要求。

这里面有很多复杂性，你几乎可以把 LLM 看作是第一公里。在还有大量其他工作要做的情况下，你如何运用它来做决策？我认为，从很多方面来说，我们用 Foundry 和 Gotham 所做的所有工作，其实一直都在等待 LLM 的到来。我的心智模型是：LLM 并不会取代你的软件，也不会取代人，它取代的是人在使用你的软件时所做的事情。

所以，如果退回到前 LLM 时代，Foundry 是企业的操作系统，而现在你把 AIP 引入其中，它将极大地增强你在决策方面的体验。用最精炼的话来说，我们认为有机会用 AI 赋能企业做出的每一个决策，而 AIP 将带来这种体验。

有几个要素是普遍必需的，我们一直在投入，而且我认为它们让我们特别适合做这件事。第一点是，你对操作系统中的类型安全越执着，你从 LLM 中实际获得的杠杆就越大。我们整个技术栈实际上都极其执着于类型安全，但如果我们只谈人类与之交互的那一层，这能让他们走得更快、更远。一种理解方式是：当你进入一家企业时，你实际上是要设法把作为整个企业的状态机以某种方式纳入上下文，而你要解决的问题——我认为如果没有一套基础技术来建模语义层、为你提供数字孪生，然后再给你在检索增强生成或实际计算工具之间来回迭代的工具以计算出答案——是无法做到的。

你们是使用第三方 API 的模型，然后在其上叠加企业的数据，还是开发了自己的模型？

SS： 我们是把模型带给客户，这样你可以自托管模型，选择你自己的开源模型。我们认为，持续对这些模型进行微调存在巨大机会。本质上，我们对世界的看法是：模型的进步速度令人难以置信，你的企业中最终可能会有一系列各种各样的模型。你将能够以非常低的成本对它们进行微调以满足特定需求，而最大、最强的模型并不天然就是最可能胜出的那一个。

我们认为模型的强大能力与迭代速度之间存在一个恰到好处的平衡点。如果你身处这样的环境中，我认为你将能够开发出帮助你应对特定应用场景的模型，而我们要实现的目标，基本上就是一种近乎无需提示词的体验。我的理解是，提示词是开发者的工具，而真正的关键在于如何在操作系统本身中实现神奇的交互体验，并让构建这些应用的开发者能够站在这个基础之上，打造由大语言模型驱动的体验。

据我理解，如今大语言模型的运作方式是：你有一个核心模型，然后可以用自己的数据进行微调。微调可以是针对特定用例或特定类型的数据，比如你做编程，但存在一个基础部分，而你并不是直接从基础部分跳到应用，中间还有一个环节。你提到过“你可以替换任何数据，可以使用开源模型，可以做各种事情”，这是否意味着存在一个独立的环节——我有点不清楚这是如何运作的。如果你是一家企业，你是说“我想使用 OpenAI 的模型”或“我想使用谷歌的模型”，然后有一个中间环节，用你自己的数据对其进行微调？还是说，不，这是一个完全独立自成一体的东西，你有这些开源选项。抱歉，我只是对它实际如何运作有点困惑。

SS： 是的，这是个好问题，我们放慢一点来拆解一下。AIP 开箱即带预定义的集成，对接这些大型基础模型，并且这些集成已经与平台中的通用体验打通。在此基础上，你可能还想构建非常具体的应用。

那中间还会有一个环节吗，作为 AIP 交付的一部分，这个微调环节？

SS： 开箱即用时并不预设微调。它只是让你能够捕捉越来越多的具体性，越来越多地——让你从独特的用例中获取更多价值，这些用例可能不存在于公共互联网上，也可能不存在于这些基础模型的训练数据集中，这时你就需要微调。但它并不预设这一点，我认为很重要的一部分是，我如何真正给这些大语言模型提供工具？

所以第一部分是，我有一个应用程序，我正在使用它。我想在我的私有数据上做一些事情，而这些数据显然不在模型里。再加上大语言模型本身的弱点——我让它做的事情很可能导致幻觉，或者我让它做的事情我无法完全信任。我该如何把大语言模型的优势与我企业中已有的一整套工具结合起来？如果我让大语言模型直接回答一个问题，那和让它生成我需要的查询是完全不同的——后者我可以利用传统的信息检索（IR）技术以及相应的安全机制来正确地回答问题。那么，我该如何帮助你把这些组合起来，让你既能获得大语言模型的体验，又能发挥现有企业工具的杠杆作用？

那么，让这一切运作起来的关键秘诀究竟是什么？在你的主题演讲中，这几乎感觉像是一个世界上最强大的 SQL 查询构建工具——我觉得这其实非常有吸引力，也很有道理——但它在日常工作中究竟是如何体现的呢？

SS： 如果把主题演讲拆分成几个不同的部分，第一部分是：如何将数据集成到我的本体（ontology）中？你可以把它称为——如果你眯起眼睛看的话——世界上最强大的 SQL 构建工具：我只需说，这是我的目标，这是我的数据源，你能把这些点连接起来吗？但有了本体之后，我该如何向它提问？我在那里展示的例子是：我收到一封邮件，说我的一个配送中心出现了中断。那么我如何直接把这封邮件粘贴进去，让它帮我可视化受影响的客户订单，然后通过一系列步骤来弄清楚，鉴于发生了这次中断，我该如何重新调配库存？

那么是否可以这样理解：大语言模型——你已经构建了这个操作系统，你有办法把所有这些数据引入进来以做出决策，而你的期望基本上是，大语言模型将以一种人们无需知道如何操作这个操作系统的方式，把这些已经存在的潜在能力全部释放出来——因为就像微软的说法那样，它就是你的 Copilot。

TM: 也许我还想回到之前对话中提到的两个根本性创伤，我认为它们在 AIP 的背景下非常相关，只是雄心达到了全新的量级。第一个是：“我的数据整合得有多好？”在 LLM 的世界里，这个问题变成了：“我如何管理一个非常小的上下文窗口？”想象一下每个企业中每个人所做的每一个决策，都有一股数据流经企业，提供那个上下文窗口。人们常常要和他们的 ERP、CRM、Access 数据库、Excel 宏搏斗，才能获得做出决策所需的上下文。所以，如果我能为你提供一个与作为运营者的你的决策相关的自动化上下文窗口，这就是我需要做的第一要务。

确保你在需要做决策的那一刻，始终拥有做出决策所需的全部数据。

TM: 是你需要的，你的上下文窗口是准确的，因为接下来要谈的是，现在是由 Agent 来做这些事，而不是用户。所以这必须是自动化的、程序化的，我必须能够在任何给定的时间点持续地向用户提供正确的上下文。

但我认为第二个创伤同样重要。你会看到很多类似“让我总结非结构化信息，让我做语义搜索”的东西，这是人们涉足生成式 AI 的低垂果实，但这其实并不特别有趣。在企业环境中我们很清楚，我必须能够做成某件事，它不是一个洞察，而是一个行动。那么我如何为 LLM 提供正确的上下文窗口，同时也提供工具，让它能够说“我要调用一个订单重新分配模型”？那个模型是 LLM 所没有的工具，是它需要的查询之一，但它还需要知道：“在什么条件下我可以执行这种重新分配？”

现在，如果我需要具备这样的基础设施，能够说：“我想提高自动化程度，我想能够非常严格地定义 LLM 从数据角度可以访问什么、在什么情况下可以采取什么行动、人类需要在哪些环节参与管理。”我现在基本上有能力转向那个操作系统，只是其中大量的操作由专注于非常具体任务的自主 AI Agent 来完成，它们可以获取上下文并开始在其间迭代。但在最终状态下，你预计会有数百个不同的 Agent，潜在地整合并完成其中的各个部分。那么，我如何拥有管理所有工具、安全、操作等的基础设施，让它们去做比写诗更有意思的事情——正如 Karp 会说的那样——真正做成一件事。

我认为这与你主题演讲中说的内容有关，Shyam。也许“世界最好的 SQL 查询构建器”这个说法不太恰当。它是世界上最伟大的——我想我其实是在重复你说的话，因为这已经豁然开朗了——某种程度上是最伟大的提示词工程师，这就是你如何使用通用模型的原因，因为那个上下文窗口——基本上你可以通过单个查询把它传进去。所以不仅仅是用户类型，而是用户数据的方方面面。

And you said this, Shyam, WYSIWYG reimagined that AIP, or you said, “Every UI is going to change, this is the integration point.” And it sounds like what this is, if I can analogize it to the operating system, is the shift from the command-line to the GUI, where all the capabilities you’ve built, they’re all there, but there’s still a steep learning curve for the user to even know what they’re able to do. Yes, you’ve got all the data in one place. Yes, they can do all this operations on it, you’ve done that hard work, but you have to be an advanced user to know how to use a command-line. And your bit is, “Look, all those capabilities and all those decision points can be passed into the prompt”, basically, so that it’s already constrained to what’s possible. What is it, what’s your WYSIWYG? “What you say is what you get”.

SS: “What you say is what you get”, exactly. I think that’s a very good, I think it’s the same revolution from command-line to GUI, GUI to LLMs are going to power that. And I do think there’s a part of this where the initial experimentation that has mostly been happening —

Right, just to jump in with one thing, a bit about the command-line to GUI is you’re not exposed to the capabilities of the operating system and what it can do with the hardware that you’re on. In this bit it’s, “How do you expose and show someone all of the data they have access to?”, that’s the hard problem here and to what AIs are uniquely able to expose. There’s no one — you can’t keep that all in your head just like you can’t keep all the functionality of the computer in your head, except for, at least most of us anyway.

SS: That’s right. I think it itself acts as a funneling mechanism to expose the data you need, the decisions that are possible and relevant in that moment, against the operating context that you actually have. And if you continue going down that path, I think it also changes how developers build software, which is the same way that the GUI changed what developers were actually building as well, and how they thought about what they were building. You can think about, if you thought about a prompt-free user interface, you may have buttons that behind it are actually calling the LLM. When you’re using Copilot to write code, you’re not asking for it to solve a function for you, it’s based on the intent of you as a user in the context of the code that you’re writing what comes next, and so really hone in on those Copilot experiences or what’s possible here, and I think what redefines the user interface.

I think this makes sense in my initial question, which is why 2023, something you guys have both talked about is “Look, it’s hard to understand Palantir because we’re building for something that’s five to ten years out in the future and you have to trust us on that”. And then it’s, “Oh well here’s Palantir coming along six months after ChatGPT, we got an LLM product”. But your point here is not that you’re not building that product, because you’ve basically spent years, to your point, making very type-safe data, the best labeled data sets in the world, for all intents and purposes, that’s custom to an enterprise. Now that LLMs have showed up, you can leverage them in a way no one else can.

SS: Exactly. Or more importantly, our customers can leverage them. When we were working with an insurance company, we were able to build an agent to subrogate insurance claims in two days. But I think a fairer version of it is, it was four years of their ontology, their set-up, running their operations on this thing plus two days.

TM: And I think to come back to when we look at the implementations of our software, generally, is the ability to integrate the next order, integrate LLMs into that. Does it provide an opportunity to fundamentally alter the outcomes that our customers have with that software? And if it does, then it’s something that we need to focus on, we need to run at very quickly. I think where we’ve gotten confidence, right now, is that this will turbocharge the value of our software to our customers and the early adopters. Shyam mentioned the insurance, you saw in the keynotes what J.D. Power’s doing as they think about redefining the experience of how their customers and interact with their data. What Jacobs is doing, when you think about how you redefine entire sewer or wastewater management networks. It’s very exciting, mostly because of, gosh, our customers are going to be really successful with this.

Well this is why I put the disclaimer at the beginning where, I’m probably insufficiently grilling you in part because I think the picture you’re painting is very compelling. This bit about actually working in the real world, actually solving real problems, building real structure around this and having this operating system approach and now you’re like, the UI has shown up, the AI-as-UI bit makes a lot of sense and it’s very compelling.

TM: And I would also say the other thing we’re excited about is, also the demands on our software is showing up. So instead of something that is, now I have incremental efficiency in implementing a nineties on-prem data stack using cloud compute with what I expect from data, now we have CEOs saying, “Shoot, this tech got scary. I need this for what I think will be the survival of my institution over the next five years.” That’s a market that’s very compelling for us, because we’re built to sign up for that accountability.

Is there a bit where you are worried about your addressable market, in that people are just going to be grabbing for LLMs left and right?”

SS: It’s the opposite. So the alpha side of this is, “Wow, this obsession we’ve had on type safety has met its moment, and that’s unique to us”. The beta on this is, “Finally everyone expects their software to actually work fast, and that’s expanding our market”.

Interesting. So do you think there’s going to be a lot of companies that take an off-the-shelf solution, do fine-tuning, whatever it might be, but that’s actually the completely wrong direction? Because the hallucination problems are not going to be overcome-able, because they haven’t properly defined their data. Whereas you guys, by coming from the opposite direction, do whatever model you want, but because we’ve defined what we have and what we don’t, the hallucination bit is a feature, not a bug.

TM: It is, but I also think it’s more than that, because it’s not just can it be accurate, but can it do something? And I think this is where our opinion that the chat interface is such a limiting interface for this technology, because it makes everyone says, “Can I get an accurate answer to a chat?” Who cares? There’s so much more that you can do with it if you think of it, “How can I operate with these things”? And so yes, accuracy is presuppose as a requirement to even get to a point where you could contemplate doing that but then how do I get to a point where I’m doing something?

Because it’s generating stuff without you instigating the generation, it’s just doing it on its own and that requires a much higher degree of trust, because you don’t even know what went into the prompt.

SS: And the tooling to think about it, it’s like the old version of this would be cron job. If we go a few paradigms out, it’s, “Okay, well how am I building the agent? How does the agent know when to start? How have I modeled the state machine as the enterprise? What part of that state machine do I trust them on, under what circumstances? What are the assertions I’m building in so that I know whether it’s hitting its guardrails or not?”

Then the output of the agent is going to be, realistically, a set of scenarios for a human to evaluate. That’s where it also meets the reality of change management within any institution. We’re going to develop trust experientially with it. This can’t come out of the lab, so how am I giving co-pilots or agents to these humans and creating these human agent teams? And I think the speed with which enterprises can leverage that to achieve real transformation is exciting.

Very good. Well we have gone long and gotten I think very much into the weeds, but I think this was a very interesting overview. I think the overlying picture is really compelling and I appreciate you guys coming on and talking about it.

TM: Yeah, thanks for having us.

This Daily Update Interview is also available as a podcast. To receive it in your podcast player, visit Stratechery.

The Daily Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly.

Thanks for being a supporter, and have a great day!