No. 80·中文精读

保险外包一年700亿美元,这家AI公司要把毛利率从10%做到80%

What’s the Future of Vertical SaaS in an AGI World? Jamie Cuffe, CEO of Pace

Pace CEO 杰米·卡夫用 AI 替代保险业传统外包,从邮件分诊到理赔处理省下五到七成成本,并谈如何让强监管行业信任自主 Agent。

节目音频00:00 / 51:55
中文精读由 AI 基于原始访谈改写,非官方翻译,可能存在偏差或错误;表述以原节目为准。

麻省理工那份流传很广的报告说,95%的企业AI试点以失败收场。这期播客的客人Jamie Cuffe给出的数字刚好相反:他创办的Pace,至今每一个试点都转进了生产环境,一个没死。

Pace做的事,一句话能讲完:保险业的「代理式流程外包」。全球银行、金融、保险三个行业每年花在BPO(业务流程外包)上的钱接近4000亿美元,跟整个全球云软件市场的规模相当,光保险就占700亿。撑起这门生意的是几十万人肉坐席,行业里几家几百亿美元市值的上市公司,毛利率只有10%到15%。Jamie的判断是,未来十年这笔钱会整体转向「外包给AI」,而Pace给自己定的毛利率目标是80%。

这是红杉资本播客Training Data的一期,标题问的是「AGI世界里垂直SaaS的未来」,聊下来,答案比标题具体得多。Jamie的履历有点绕:普林斯顿毕业,进红杉做过投资,后来在Retool从零搭建前部署工程师团队。但他的起点其实就是保险。他生在伦敦,长在纽约、伦敦和百慕大之间,全是保险业重镇。爸爸先在一家再保险公司管运营,后来去伦敦劳合社的承保代理做同样的活。

真正的转折发生在Retool。这家公司的大量客户来自金融服务,从Ethos、Vouch这样的新锐保险公司,到Progressive、伯克希尔哈撒韦。他做前部署工程师,等于坐在第一排看这些公司的运营难题:保单管理、理赔、提交受理。客户甚至用Retool搭内部工具,专门给BPO的流程提效。

那个阶段,软件能做的事很有限,把BPO支出优化个10%左右,这就是OCR和RPA那一代技术的天花板。ChatGPT出来之后,账变了。软件第一次有机会整体替换这项服务,替它打补丁的时代结束了。

为什么先挑保险?Jamie给的理由很实在:这个行业的通用语言是邮件和PDF。产业链里中介太多,经纪人有经纪人的系统,承保商有承保商的系统,彼此之间没有API,沟通只能靠邮件、PDF和电话。当年BPO生意就是从这儿长出来的:总得有人手工把文档里的数据敲进系统。现在,同样的活恰好是AI代理最擅长的。催生外包的原因,成了AI进场的原因。

毛利率从10%到80%,做不到就算失败

主持人问Jamie晚上睡不着都在想什么,他的答案很直白:怕Pace最后只做成了一家「更大的BPO」。

他算过账:BPO行业里有多家几百亿美元市值的上市公司,毛利率10%到15%,员工几十万级别,干的就是这些活。那样的公司很优秀,但在他的定义里,做成一家更大的BPO,就是这场创业的失败案例。

真正的目标分三层:先把保险的后台流程接过来,毛利率从10%推到80%,几十万员工换成几十万个AI代理加一小队保险专家;再把这套打法复制到更多行业。

Pat Grady补了一个视角:盯BPO预算还有个隐藏好处。客户和BPO之间本来就有成熟接口,目标写得清清楚楚,活干完要验收,有的客户还让多家BPO互相竞争。这等于自带了评测标准和对比基线。

关于毛利率,他的观点值得单独记下来:毛利率不必第一天就高,但你得有一条通往高毛利率的路径。Pace的飞轮是这么设计的:每次产品改进,都直接推高毛利率。今天数字低没关系,接的活越来越难,这个数字得一路往上走。

别把AI塞进小盒子

聊到产品,Jamie吐槽了市面上常见的一种做法:搭一个工作流编排器,画一张流程图,把AI当节点塞进几个格子,外面再包一层代码。

「如果你把AI硬塞进这些小格子里,再在外面包一层代码,你就错过了今天AI真正能做到的事。」

他的逻辑是:BPO这行存在的理由,恰恰是这些流程没法用确定性代码写清楚。里面有人的判断,有层出不穷的边缘情况。把AI塞进小盒子再包代码,等于把今天AI能做到的事硬生生做小了。

Pace的做法,是把客户的标准操作流程(SOP)翻译成「代理操作程序」。产品里像一份Notion文档,用自然语言写清楚每个步骤,中间挂上各种工具:从几百页的复杂文档里做长上下文检索,对成堆的规则做推理,再把结果写回保险公司的核心系统。碰上没有API的老系统,干脆用网页代理直接操作界面,经纪人对着承保商门户录数据这种场景也能跑通。

人在环上吗?绝大多数工作流没有人工介入,AI端到端跑完。上线初期准确率大概90%,客户的要求是99.5%以上,中间的差距靠标注样本和自我改进循环拉平。等数字达标,人手就转向下一个更难的任务。

他还给大模型实验室列了张愿望清单。推理模型的扩展曲线已经让复杂文档抽取的可靠性超过人类;下一个前沿是网页代理,保险后台的典型任务是「在管理界面上做增删改查」,跟订餐厅、订机票那种演示完全两码事;更远期是强化学习,代理从输入一路跑到输出,每一步都有标准答案可打分,天然适合做奖励函数,可以按客户、按工作流规模化地训练。

95%的试点会失败,他们一个没死

Lauren Reeder在节目里提到MIT那项研究:95%的AI试点以失败告终。Jamie的回应很平静:Pace到现在,每一个试点都进了生产环境,他对这个纪录相当骄傲。

他归因于公司的核心价值观之一:closing the distance,拉近距离。团队飞到客户现场办公,只做保险,队伍里有一批保险老兵,客户一开口就知道这帮人懂行。脏活累活前置:帮客户调提示词、从运营数据里搭出干净的评测集、接内部系统,全在签下七位数合同之前干完。

具体怎么开工?从客户的COO办公室聊起,找机会点。Jamie特意说不喜欢「概念验证」这个词,Pace从不在演示数据上跑,一上来就用客户的真实数据。第一步是把成功标准定死,甚至鼓励客户拿出最苛刻的验收条件,他们对自己的产品有信心,不怕考。

现场能看到的东西很生动:客户的SOP是一份50到100页的文档,写着60来个步骤,哪里要从系统A取数、哪里要录进管理后台,文档里用红框标出来。Jamie说,因为服务对象是BPO,这些流程大多已经写得很清楚,但总有缝隙,文档没写的潜规则,只有贴着客户干活才能发现。

结果是,好几个客户说Pace是他们合作过的公司里,从接触到跑通概念验证最快、从概念验证到生产环境也最快的。

Jamie在Retool时建过业界规模数一数二的前部署工程师团队。他认为这个岗位最合适的人选是「当过创始人的人」:想往商业走的工程师,或者懂技术的商务。标准只有一条,想尽一切办法让客户成功。

Pat Grady把这件事放进更大的图景:AI应用公司做分发,自下而上和自上而下是两个极端,最好钉死在一端。ChatGPT、OpenEvidence是自下而上;Harvey、Sierra、Pace是自上而下的解决方案型公司。这个阶段这类公司卖的核心东西是信任。客户看得见AI的魔力,也看得见它会出错。前部署工程师既给客户吃定心丸,又把一线的真实问题带回公司,省得团队在办公室里空想需求。

那前部署工程师会不会只是过渡?两人的判断一致:终局是软件化的工作流,但短期多招前部署工程师错不了。Pace的前部署工程师自己也写代码进生产库,面试就考这个,看到问题当场修,不发工单等排期。已经有客户在Pace的人搭好头一两个工作流之后,自己的业务分析师接着建到了九个、十个。公司现在80%是工程师,上面一层前部署,再上面是市场团队,三层比例要配平。

招人怎么办?两头都招,坐在一起。一边从前五大保险公司挖运营专家,他们亲手干过这些关键流程;一边找YC出身的AI创业者,站在代理技术最前沿。让他们紧挨着跟客户一起干活,互相学,两边上手都快。

省钱只是开胃菜

先说钱。客户的BPO年支出八位数美元起步,Pace在很短时间里帮一些客户做到了50%到75%的成本节省。

但Jamie说,客户很快会发现更值钱的东西:

  • 速度。一份风险提交不会只发给一家承保商,谁回得快谁先签约。AI把响应时间压下来,直接变成成单率。
  • 弹性。保险业务季节性极强,1月1日的投保高峰,眼下的飓风季。以前要临时扩BPO人力,现在AI全天候干活,积压还没形成就清完了。
  • 可观测性。BPO过去是个黑箱,活干到哪一步、卡在哪里,客户看不清。现在每一步、每条推理都摊开,客户反过来重构自己的流程。

准确率这事儿也有反转。行业里总在问AI能不能达到人类的准确率,Jamie说很多场景里AI能远超人类。他举了个画面:一份300页的理赔文件,几百条规则要核对,周五下午,一个真人盯着这份文件,第298页的那条规则大概率就漏了。AI每次都用同样的质量跑完全部规则。这件事的本质,是把团队里最好的那个BPO员工的能力,复制成可以规模化的产能。

Pat Grady用Waymo打了个比方:坐过旧金山无人车的人都懂,一个注意力永远在线、把每个边角案例见过一百万遍的司机是什么概念。训练得当的AI,已经能证明它在很多工作上比大多数人干得好。

顺带一张行业底牌:BPO的平均错误率有5%到10%,有些客户那边实际更高。所谓「人类基线」,没大家想的那么高。

他想做服务业的Constellation

Jamie在红杉实习时学到一件事:合伙人Andrew Reed最喜欢的公司是Constellation Software。这家加拿大公司的创始人Mark Leonard掌舵30年,把一堆单独立不住的垂直软件小生意聚合起来,用联邦制管理,做到加拿大市值最大的公司之一,七八百亿美元。

Jamie想干的是同一件事,只是对象从软件换成服务。BFSI的BPO年支出接近4000亿美元,跟全球云软件市场一样大,保险占700亿。把这些垂直服务聚合到一个平台上,再把行业经济学改造一遍,是他看到的终局。Pat Grady补了一句,这类市场往往「sneaky big」,没有家喻户晓的名字,比外人以为的大得多。

公司名字Pace,本意是步速。三条价值观:closing the distance,拉近距离;be the rock,做客户的磐石,保险是在客户最难的日子里出现的,Pace要在客户每天的工作里顶上;set the pace,定步速,跑得比谁都快。

红杉办公室电梯口有块屏幕,写着「我们只和我们下一笔投资一样好」。Jamie说这句话渗进了Pace的文化:每个季度归零,你只和你下一个客户一样好。

明天就能用上的四件事

这期节目听完,不同的人能带走不同的东西:

  • 管着外包流程的运营负责人:把那份50到100页、写了60个步骤的SOP翻出来。只要这个流程已经外包出去、量大、有验收标准,它就是AI代理的现成说明书。从提交受理、首次报案这类流程顶部的大流量环节试起。
  • 正在做AI产品的人:先别急着画工作流图。问自己两个问题,这个流程能不能让代理从头跑到尾,输出有没有标准答案可以打分。能打分,后续才谈得上用强化学习继续抬准确率。
  • 想创业的人:Jamie的建议是去当前部署工程师,公司里的人要么在造东西,要么在卖东西,这个岗位两样都干,是离真问题最近的创始人训练营。
  • 采购AI方案的人:判断供应商有个简单标准,看它敢不敢在开工前把成功标准定死,敢不敢直接拿真实数据跑,绕开演示数据。Pace甚至鼓励客户拿出最苛刻的验收条件。

二次创业的Jamie还留了几条经验。从Retool学到的:一门心思盯客户和收入,融资、律师这些事大多是干扰项,团队用着Cursor、Codex这类工具,省下的时间全砸在客户身上。关于单打独斗:早期确实需要联合创始人一起穿越沙漠,可方向一旦清楚,剩下的全是执行风险,让整个团队参与价值观、招聘和产品决策,反而能招到更强的人。他大学时为了结识红杉的Bryan Schreier,熬了个通宵写出20页的普林斯顿创业报告,对方此后看着他走完职业每一步。找到愿意一次次押注你的人,比找到一笔钱重要得多。

Pace成立才一年,故事刚开头。但这场对话留下了一个清晰的坐标:全球最老、最重的行业里,那些最脏最累的活,恰好是AI今天最能干的活。BPO这门4000亿美元的人肉生意,正在变成AI代理的第一块试验田。

文稿来源:sequoiacap.com;机器转写可能有识别错误,人名与数字请以音频为准。
id="podcast-transcript" data-framer-component-type="RichTextContainer" style="transform:none">IntroductionJamie Cuffe: And I think if you sort of try to shoehorn AI into these, like, tiny little boxes, and then you add, you know, kind of this code layer around it, you’re sort of missing the point of what can be done with AI today. I think if you build for the ability for these AI agents to take any standard operating procedure and be able to run that process end to end, that’s the direction that we’re sort of taking at Pace. Lauren Reeder: On this episode of Training Data, we sit down with Jamie Cuffe, the founder and CEO of Pace, to explore how AI agents are quietly revolutionizing insurance and what that means for the future of work in high complexity, highly regulated environments. Jamie shares why the real breakthrough isn't just automating tasks, but architecting AI to handle nuanced end-to-end processes previously thought to require a human touch and human judgment. We dive into building trust with some of the biggest and oldest companies in the world, why forward-deployed engineers are becoming a secret weapon for AI companies, and how AI replacing BPOs could fundamentally rewire entire sectors of the economy. Enjoy the show. Main conversationLauren Reeder: Jamie, thank you for joining us. Jamie Cuffe: Thanks for having me. It’s great to be here. Lauren Reeder: We would love to dig right into what you’re building. I’m curious, you started a company last year. What are you building and why? Jamie Cuffe: Yeah, so Pace is the agentic process outsourcer for insurance. And what that means is, you know, we have seen over the last couple of decades a big shift from onshore to BPO work. And our thesis is that over the next decade we’re going to see a big shift from outsourcing to outsourcing to AI. And so we focus exclusively on insurance carriers, helping them to automate a lot of the critical back office operations that traditionally are being outsourced to BPOs. Pat Grady: Can I ask about the path that brought you here? So top of your class at Princeton, investor at Sequoia, rising star at Retool, insurance BPOs. Not obvious that that would have been the next step on the journey. Can you explain kind of how you got there? Jamie Cuffe: You know, it’s a circuitous path, and what’s funny is I actually started there. So I grew up around insurance my whole life. I was born in London, grew up between New York, London and Bermuda, which are kind of all the capitals of insurance. And the throughline there is my dad actually ran operations for a reinsurer and then a Lloyd’s cover holder in London. And so I kind of always knew about this problem but, you know, starting my company out of college and, like, immediately run towards that until I got to Retool. And actually Retool, a ton of our customers came from financial services. And, you know, from the outside in, I think a lot of people think of Retool and they think startups but, you know, Retool is really tackling a lot of this, you know, bigger market around custom software. And the places where there’s most custom internal tooling are the businesses that are most operationally intensive. And financial services firms are a lot of those because they don’t have a lot of great software that’s been built off the shelves. And so what we were seeing is a lot of very large legacy insurers were using Retool all the way through to the most tech forward ones. So you had, like, the Ethos and the Vouches, you know, those types of businesses, all the way through to Progressive and Berkshire Hathaway and businesses like that. At that point it was, you know, being in a forward-deployed engineering capacity, you kind of get this front row seat to seeing a lot of the problems that these companies are handling. What was really cool is a lot of times people would build retail applications that would actually help to streamline some of their BPO operations, and so I got to sort of see a lot of the problems I think my dad was also dealing with in his business of policy administration, claims, submission intake, a lot of the core workflows that are critical to insurance operations. And at the time, I think with software you can make a little dent on BPO spending, you can make it, like, 10 percent better. And I think that was a lot of the promise of OCR and RPA and some of these prior technologies. But what happened after the ChatGPT moment and when I was lucky to be working on a lot of Retool AI and some of the new products coming out of Retool, is you saw this opportunity to now completely change the economics of that industry. And so instead of augmenting outsourced services with software, you could actually go and completely replace the vertical service. And so insurance is a particularly good starting point for that, because the lingua franca of the industry is emails and PDFs. Pat Grady: Mm-hmm. Jamie Cuffe: And the main reason for that is there are a lot of intermediary players and there is no, like, common system on which they all work. And so, you know, with the lack of an API, the sort of alternative is, you know, email, PDFs, phone calls. And so now, you know, AI agents really have the ability to kind of bridge that gap. And so what gave rise to a lot of BPO work, which was this sort of manual data entry handling of these documents, emails, is now also what’s perfectly positioned for AI agents. And so we see that as a really good starting point within the sort of opportunity to build the agentic process outsourcer across many industries longer term. Lauren Reeder: So Jamie, how do you build a better business than the last generation of BPOs, even though you’re taking over the same workflows and a lot of the same spend that’s going on today? Jamie Cuffe: Yeah. People often ask, like, kind of what keeps me up at night, and that’s the main thing. That’s the main thing [inaudible] which is, you know, we are very lucky right now to be getting with lots of incredible customers. And you have this sort of opportunity. You could build, you know, a very large company just, you know, being a BPO is there are multiple tens of billions of dollar public companies that, you know, are running at 10, 15 percent gross margin with tens to hundreds of thousands of people doing this work. And obviously those are great businesses and, you know, exceptional teams. But for us, we think there’s, like, a much, much bigger outcome. And so when I actually talk with our team about kind of what we’re shooting for, that’s the failure case. So we build this sort of multi-billion dollar BPO, but don’t change anything about the economics of the industry. The goal of what we’re going for is how can we take that from, you know, a 10 percent gross margin business to an 80 percent gross margin business, where instead of having hundreds of thousands of people, it’s hundreds of thousands of AI agents and a small team of insurance experts. And so that I think is a much, much larger company. And then I think the last step is how do we do that not just in one vertical, but across many verticals. And so those are the two things I think about. And I think people say, like, okay, push gross margins to later, or it’s not that important or, you know, I think people have a lot of perspectives on gross markets. I think it is important, and I don’t think it’s important to necessarily have it from day one, but you need to have a path to it. And, you know, people talk a lot about flywheels, and the flywheel that we want to create is every time we’re making improvements in the product, the gross margins go up. And so that’s the big thing that I think we’re pushing on is, you know, even if we’re lower gross margin today, as we take on harder and more complex tasks, how are we just constantly seeing that number shift up over time? Lauren Reeder: As you’re building with agents and starting to plug into these email and document processing workflows, I’m curious what you’re seeing is working in practice. We’ve talked to folks from OpenAI who were doing fine tuning. They have all the data, they have this amazing infrastructure. We’ve seen companies with much lighter processes on the back end. What actually works for you in practice? Jamie Cuffe: Yeah, so a lot of the types of workflows that we focus on are these sort of like mission critical processes that have been outsourced, and so they want you to do that work sort of end to end. And so I think, you know, the prior generation, pre-AI, when you’re sort of tackling these problems, yes, like, extracting data from unstructured documents is great, but it’s sort of just like one part of the problem. It’s extracting it, it’s maybe reasoning over that, applying this sort of human judgment. And then it’s also being able to sort of write back into those internal systems and really sort of solving what previously could only have been done with humans. One way you could think about this is hey, let’s build one of these sort of like workflow DAG kind of builders, and sort of infuse sort of AI nodes in different places where you’re like, okay, now we can do, you know, document extraction or we can do an email sending back and forth or something like that. Part of the reason that, you know, BPO work exists is it was so hard to codify that work deterministically. And the reason is there was this sort of human judgment component and lots of edge cases that came up. And I think if you sort of try to shoehorn AI into these, like, tiny little boxes, and then you add, you know, kind of this code layer around it, you’re sort of missing the point of what can be done with AI today. I think that product stance is actually, like, relatively short on AI. I think if you build, you know, for the ability for these AI agents to take any standard operating procedure and be able to run that process end to end, that’s the direction that we’re sort of taking at a Pace. Pat Grady: So do you have a human in the loop right now or no? Jamie Cuffe: So for the vast majority of our workflows, there’s no human in the loop, and it’s AI processing end to end. We do have our own operations team that we’re building out for sort of the most complex workflows. And kind of the way we see that sort of role of human in the loop is we have our operations team to do it, we can escalate to our customers, but primarily where that is used is in the onboarding process. So as we’re sort of getting customers up and running, we basically want to be able to just label a bunch of examples and make sure that the agent is doing this, you know, at—you know, starting out of the box is, you know, maybe 90 percent accuracy. And then how do we get it up to, you know, the 99.5 percent-plus that our customers require to be in these critical workflows. And so that’s sort of where we see this sort of human labeling component and then a self-improvement loop that sort of helps us get there. And then over time we just sort of reduce the amount of human in the loop there and move that sort of operations team to work on the next most difficult task. Pat Grady: So when you engage with an insurance carrier, and they have X number of workflows that they’re currently outsourcing or that could be outsourced to some sort of traditional insurance BPO, I presume you can’t do all of them today. Jamie Cuffe: Yeah. Pat Grady: Pretty amazing if you could. Which can you do today? And how do you engage such that you kind of pick off the workflows that are sort of really applicable to AI today, and then how do you sort of grow over time to take up more of those workflows? Jamie Cuffe: So we tend to focus on the use cases that are one, already really nicely outsourced. So they have to already be using a BPO at scale. The reason for that is it’s already codified as a standard operating procedure, there’s already a way to check for accuracy because, you know, this is already being reviewed usually by someone internally or at least sort of like QAed on a sampling basis. The last part is sort of as you think about the change management, it’s much easier to sort of spin down a BPO service than it is to sort of retrain or move a W2 workforce. So we start with operations team BPO, the large carrier. We tend to focus on the most high-volume use cases where we think there’s the biggest ROI. So you just look at kind of the line item for a BPO. Where are they sort of spending the most, and where can they get the most ROI from AI? Usually what that means is we start at the very top of the funnel, so submission intake, where they’re getting a new risk, extracting that data, running their business logic over it, and then writing back into their own new business underwriting platforms. The same can happen also on the claim side. So first notice of loss or claims intake, getting that information into their internal systems. And then once you do that, customers ask you to sort of work down the policy servicing life cycle into endorsement processing and other policy administration tasks, all the way through to billing. And on the claims side, the same thing from claims intake all the way through to payout and quality assurance. That’s usually the path we take. Pat Grady: What’s a typical before-and-after situation? You know, human BPO and then Pace AI BPO, like, what sort of metrics change, you know, when they go from before and after? Jamie Cuffe: Yeah, so it’s interesting. In the BPO world, I think a lot of where you start is, okay, there’s a new technology that can now help me save a lot of my costs. And you know, with a couple of BPOs, I think, you know, the MPS is quite low, and it’s a massive line item for a lot of our customers, you know, eight figures plus of spend. And it starts oftentimes with cost. And that’s big. And for some of our customers we’ve been able to achieve, you know, 50 to 75 percent cost savings, you know, in a very short period of time working with them. But usually what happens after that is they realize that there are a number of other things that are actually much more important to them. And usually, it’s the things that previously just couldn’t be done with BPOs that now with sort of AI working at superhuman speeds, you now have this sort of capability to do. So an example of that is if you think about a submission intake process, usually that carrier that’s receiving that submission is not the only one that’s receiving it. And so if you can get back much faster, you can actually close business faster. Same thing, you know, when you think about scalability. So, like, you know, BPO work is not just kind of like, you know, perfectly linear over the course of the year. It’s highly seasonal. So you can think, like, a Jan 1 enrollment period or you know, hurricane season like we’re in right now. And so if there’s a massive spike of hurricane claims, you have to go and spin up a bunch of other BPO for your workforce to do that work. And now you can have AI sort of working for you 24/7 to just crank through that backlog before it even becomes a backlog. Those are a few of them. And then I’d say the last thing is sort of observability, which is a lot of this BPO work in the past has been sort of a black box. It was very hard to see kind of like what was getting done, what stage each task was in, where the bottlenecks might be. And some of this is sort of just like good old-fashioned software workflows, which is, you know, now that you’re sort of able to do this work with agents and sort of be able to literally see exactly the task is taking and the reasoning and the why is you can now surface a lot of that information back to customers such that they can actually redesign their workflows, not just do the same stuff that they were doing with a BPO. Lauren Reeder: I’m curious, as you work with these massive companies with these mission critical, like, core business workflows such as processing claims or payouts, what does it take to actually help them succeed? Like, on our end, we see studies from MIT saying 95 percent of AI pilots fail. And then we also see our portfolio companies not failing. What do you see? How do you make sure that you succeed? Pat Grady: A lot of companies not failing. [laughs] Lauren Reeder: Yes, exactly. Jamie Cuffe: Yeah. You know, I think the 95 percent number hit the headlines and everyone was like, “Oh my gosh, like, what’s going on?” You know, I think that the truth is definitely that getting AI working in production is not, like, a done deal when you walk in. And there are certainly challenges that we’ve seen across the industry of other vendors or building in house where they haven’t been successful. And so for us, what we really focus on is—one of our core values of the company is closing the distance. And we’ve been lucky that every single one of our pilots has been a hundred percent successful in going through to production. And I’m very proud of that. Pat Grady: Yeah. How did you pull that off? That’s not normal. Jamie Cuffe: Yeah. I think the main thing is we really believe in forward deployed engineering. So anyway, I think that might be a little bit of a hot take, and I’d be curious for your thoughts on this. But ... Pat Grady: You know my thoughts on this. Jamie Cuffe: [laughs] You know, you talked the other day about kind of like technology out versus customer back. And we’re just very much taking the customer back point of view. You know, when we’re going in there, we’re going in on site with our customers, we’re flying to them. We deeply understand the insurance industry, and we are only focused on these workflows. We have, you know, a ton of insurance experience on our team, and so that immediately, you know, so we go into these customers and they talk to us and they’re just like, “Okay, they’re speaking our language. They understand what we’re doing.” But the next thing is like, we have to do the hard work. And oftentimes that’s doing the hard work upfront, not necessarily like, you know, once you’re live in production with your seven figure-plus contract. It’s, you know, working with a customer as a partnership to prove out that this can work. And this is even more important in AI where people—you know, there were a lot of, you know, exciting demos early on that maybe didn’t pan out. And so, you know, we focus on, with our customers, just really helping them get to value and get to something in production as quickly as possible. So what that means is for our forward deployed engineering team—this was a team I was really lucky to build out at Retool, and I think at the time deployed engineering after me, Palantir—like, Retool had maybe one of the most, like, scaled deployed engineering teams. And the profile that really, really works for deployed engineering is basically former founders. So it’s like engineers that want to be commercial or commercial people that are technical. And the critical thing is you just do whatever it takes to make the customer successful. So it’s understanding the use case, it’s helping them when they need help with an AI model, we help them prompt, tune and make that successful. It’s diving into the operations data and figuring out how to create a really clean eval set for them. It’s helping them get integrated into their internal systems. And it’s all the sort of like hard work that actually makes these pilots successful. Pat Grady: One thing I’m curious about—because we’ve seen this in a bunch of the other kind of domain-focused AI application companies—do you hire AI people and teach them insurance? Do you hire insurance people and teach them AI? Do you just hire athletes and they learn as they go? How do you think about sort of the intersection of the technical skills, the domain knowledge? What do you look for? Jamie Cuffe: Yeah, I think the critical thing is you’ve got to hire both on the team and, you know, sit them really closely together alongside your customers, and that way you kind of like get this constellation approach where everyone kind of like learns from each other. You know, for us, like, that means hiring people directly from the insurance industry that have worked on exactly these sort of mission critical operations at top-five carriers at scale, and then sitting them right next to a former YC founder that has worked on an AI company that is at the cutting edge of building AI agents, and then them kind of like coming together to get this done for the customer. So I think it’s sort of that our experience has been there’s not that many people that are already ramped up on AI agents. And then in the insurance world we’ve been lucky to find some incredibly forward-thinking people that are excited about helping usher in this change. I think part of that is, you know, people resonate with the thesis of—many have worked in kind of like the BPO world and they see, okay, like this is where the world is going. And I’ve been super, super impressed by people that we’ve been able to get from both of those backgrounds, and their ability to pick this up really, really quickly to sort of get the full set of skills you need. Pat Grady: And back on the topic of forward-deployed engineers. Jamie Cuffe: Yeah. Pat Grady: Is that a temporary phenomenon because the capabilities coming out of the AI world are not quite there in terms of what we need to deliver a full reliable solution to customers? Or do you think 10 years from now you guys still have forward-deployed engineers on every account? Jamie Cuffe: Yeah, I think I need to—I’ll answer this and I’ll flip the script to you of some of your thoughts. So I actually think that you and I both agree on the end state. And the short term is, I think, it’s hard to go wrong actually, getting more and more deployed engineers into working with our customers. And the main reason is we have this sort of flywheel both within our customers of helping them get successful with the product and then going on to larger and larger use cases where you really expand into this sort of like very large set of budgets that they have around BPO spend. And then the same thing, we have a flywheel sort of internally which is, you know, our forward-deployed engineers can work inside of our product and work with our customers, but they can also ship code and code into the production code base. And they do. And so that’s something we, like, test for the interview, you know, at the onsite and then, you know, throughout their work. And so what’s really important is you have this very, very tight feedback loop of working with the customer and you see some issue, and then you immediately go back and fix that. It’s not like I create this ticket and I pass it to somebody else who maybe does it and then maybe I get it back to the customer. It’s just so you get that done really, really quickly. And so what should happen over time, what we’re already seeing is deployment times are going down. The amount of work that deployed engineers are doing is becoming much, much higher leverage, because we’re sort of pushing that back into software workflows. So in the short term I’m, like, very pro continuing to build with our customers and build earlier with forward deployed engineering, but I agree with you that I think the long term is—like, software codified workflows is ideal, right? You know, we enable our customers to build inside of our product, you know? And it’s not all just forward-deployed led. You know, we maybe get the first one or two up and running, and we have customers where we’ve turned and now they have nine, ten in production because, you know, they have a business analyst that has just been kind of like building out additional workflows. Pat Grady: Yeah. Jamie Cuffe: And so that’s very much, you know, the way that we think about building the product. And I think the critical thing is when you think about a team, you’ve got to make sure that, like, kind of the layers and where you’re investing in the team match up with that. So if your forward-deployed engineering team is like this and your engineering team is like this, you’re going to have kind of a problem where you’re not actually, like, really, really investing in the product. For us right now, you know, basically 80 percent of our team is engineering, and then we have forward-deployed engineering, and at the very top we have this go-to-market team. And I think as long as you keep that in balance, we’re going to be able to really get that flywheel going. But yeah, I think the timelines is maybe kind of like the big thing that I’d be curious for your thoughts on, which is sort of for me, I think it’s okay for us to continue doing this for a long period of time as it just makes our customers successful, and then, you know, maybe we can check back in 10 years as we’re going public. I actually think it’s a great story to have in the public markets of seeing you’ve got this big forward-deployed engineering team and you’re just constantly figuring out how to make them higher and higher leverage so they can do more and more. Pat Grady: Yeah, I think we’re pretty well aligned on this. Our observation on this market has been—maybe to overstate it a bit—if you think about bottoms-up distribution versus top-down distribution as two ends of the spectrum, you kind of want to be pegged out at one end or the other. You don’t want to be stuck in the middle. You know, bottoms up, ChatGPT is a bottoms-up distribution product. OpenEvidence is a bottoms-up distribution product. Like, these are not comprehensive solutions, but they are wonderful tools that people see and they love and they figure out what to do with. And I think on the top-down end of the spectrum, you know, Harvey is a solution for law. Sierra is a solution for customer communications. You guys are a solution for insurance, right? And I think if you’re going to go the solution route, we’re at a moment in time in this market where the thing that you’re selling to your customers is kind of trust as much as anything else. Like, they can see the magic of AI, they want to believe in the potential, but they can also see the issues, and they can see where it can go wrong. And I think the role that you guys or Harvey or Sierra plays in some ways is just saying, “Hey, trust us. We’re going to make sure you’re good.” Right? “Like, we’re going to make sure that this new world of AI is to your benefit, you know, and it’s going to make your business better, and we’re going to do whatever it takes to make that happen.” And so I think forward-deployed engineers in that context, you know, not only, like, really helps to give the customers confidence, to your point, it also creates that feedback loop into the organization so that you’re not theorizing as to what problems you can go solve. You’re actually there where the rubber meets the road, and constantly, like, going deeper and deeper and deeper into their workflows. Jamie Cuffe: Yeah, I think that’s spot on. The trust point is so important also, particularly in our industry. I mean, insurance is sort of like the business of trust, you know? Pat Grady: Yeah. Jamie Cuffe: One of our other values is “be the rock,” which is basically like our customers are there. Pat Grady: “Be the rock” or “beat the rock?” Jamie Cuffe: Be the rock. Pat Grady: Okay, got it. [laughs] Jamie Cuffe: Be the rock. And basically, the idea there is like, our customers are there for their customers. They’re insured on their hardest days. And we are there for our customers every single day. And that’s what we want to do. Pat Grady: Love it. Jamie Cuffe: And, you know, this industry is like—the industry is built around trust. I think a lot of what we think about is working with, like, the most trusted brands, the very, very top insurers at the top end of the market, building that brand or trust and credibility, and the results speak for themselves. And then, you know, looking to expand through the market. I think similarly to, you know, Sierra and Harvey and a number of other companies that have done that really, really well, which is, you know, go and work with the top, top customers in that industry where you can get—you know, they have the highest volumes, they have the highest ROI, they’re the ones that stand the most to gain, make them really successful. And then the product sort of speaks for itself as you go to your next set of customers. Pat Grady: We’ve gotten two values out of you so far. We’re going to close the gap and beat the rock. What else? What are the other company values? So we’re two for two on good ones. What else do you have? Jamie Cuffe: We only have one more. Pat Grady: Okay. Jamie Cuffe: Keeping them short. The last one is my favorite, which is “set the pace.” So, you know, you both know me really well, and I think I have, like, a pretty high level of, like, urgency and maybe impatience at times. Maybe just like, you know, I just feel—we feel very, very lucky to be in the position that we’re in. I mean, it is such an amazing time to be building a business. I’m sure you all see this from your vantage point as well, to be investing in businesses as well. And we are so lucky to be working with the companies that we’re working with and to be, you know, charting this path. And, you know, I think it’s ours to go and make this future a reality. And so I feel “set the pace” really encapsulates that. You know, naming the company Pace, it’s all about speed. And that’s a lot of the value that our customers are seeing, but it’s also what we want internally. And then I think it’s also sort of intentional. It’s like this step, a pace towards kind of our bigger mission. And we’re moving as fast as we can to get there. Pat Grady: Nice. Lauren Reeder: Tell us about that bigger mission. I’m curious where you go once you’ve gone deep in insurance. There’s a lot of room to expand, but your ambitions are much bigger than that. Jamie Cuffe: Yeah. And maybe this starts actually when I was lucky to be an intern here. One thing I learned that summer was that Andrew Reed, his favorite company is Constellation Software. I don’t know if that’s ... Lauren Reeder: [laughs] Jamie Cuffe: Hopefully that’s still the case. Pat Grady: I’m pretty sure technically we’d have to say that his favorite company is Figma. Jamie Cuffe: Figma. Yeah, okay. Pat Grady: Or Robinhood or Klarna or, you know ... Jamie Cuffe: We can rerun this as ... Pat Grady: No, no. All good. All good. Jamie Cuffe: ... favorite non-Sequoia portfolio company in the public market—not investment advice—is Constellation. Pat Grady: [laughs] Jamie Cuffe:  And so for those who don’t know about Constellation, and I think what is really, really exciting about that company until actually, I think, last week it was run by this incredible founder, Mark Leonard, who built this company for 30 years. And his vantage point was let’s build a business that can span many, many different verticals. And what they did in software was basically aggregate all of these niche vertical industries that in and of themselves were not, you know, scaled enough to be sort of like legendary long-term businesses, but at scale in a sort of federated model that they have is an incredible business that’s, you know, compounded massively over the last couple of decades in the public markets to I think one of the largest companies in Canada, you know, like, $70-80 billion. And there’s this really interesting opportunity right now to do kind of the same thing that was done in software, but for the services market. You know, as we’ve talked about, the services market is like orders of magnitude larger, and so if you look at BPO spend, BPO spend in just banking, financial services, insurance, which is sort of the markets that we see immediately in front of us is about $400 billion, just a little bit under $400 billion. Pat Grady: About the same as global cloud software. Lauren Reeder: Every year. Jamie Cuffe: Yeah, $70 billion of that in insurance, and basically yeah, the full BFSI BPO spend’s the same as, like, all the cloud software. And so, you know, if we can be a platform on which you can aggregate all of these niche vertical services across BFSI and maybe beyond longer term, there is just a huge opportunity there. And I think the most interesting opportunity is that it’s not just about aggregating them, it’s also about transforming the economics of the industry. Pat Grady: Yeah. Yeah, this is one of the things that I think is interesting about Pace or other kind of domain-specific application-layer AI companies, is a lot of the markets that people are going into are, like, sneaky big, you know, much bigger than you might realize because they’re not household names, they’re not B2B SaaS products, right? The other thing that I think is interesting—and you alluded to this earlier, but I just want to hit on it again—this idea of going after the BPO spend, right? You have a clean interface with your customer because there’s already an interface between the customer and the BPO. You have concretely defined objectives, because they have to define those to be able to interact with the BPO. You sort of have built in eval, because when that work comes back, they’re checking it somehow to make sure that it’s actually right, and a lot of times they’re doing, you know, champion-challenger models with different BPOs. Jamie Cuffe: Yep. Pat Grady: And so I feel like this interface that you found, it’s not just that the services spend is big, it’s also that the sort of the route to market that you’ve chosen with the BPO interface is also like a really clean way to do it. And I think that strikes me as an important aspect of what you’re building, too. Jamie Cuffe: Yeah, I think that’s exactly right. I mean, I think that a lot of our customers are really tuned into the fact that AI has this opportunity to dramatically transform their business, particularly in areas where there is this high volume of highly repetitive tasks that require, you know, human judgment. You look at your BPO and that’s exactly where that is, and the fact that there’s already these standard operating procedures that we can model in our product and then, you know, the ability to do the accuracy checking and the built-in eval, also do the change management afterwards much faster so that customers can really get, you know, hard cost savings, hard ROI savings is really great. And then it’s also helpful, you know, as we go to market with our customers is that there’s a baseline in place. And, you know, transparently, sometimes that baseline is not as high as we think it should be. You know, the average accuracy rates in BPOs is, like, you’re making five to ten percent error rates. And that’s kind of where I think most people feel it is. But for some of our customers we’ve seen it’s actually, like, much, much higher. And the main reason is like, if you’re doing—you know, when people talk about accuracy with AI are usually like, “Okay, can the AI be as accurate as a human?” We think in a lot of the use cases that we’re working on, it could be way more accurate. Pat Grady: Yeah. Jamie Cuffe: And the reason is—so, like, let’s say you’re doing, like, a claims QA or a policy QA. You’ve got a 300-page document, you know, maybe this big claims file, and you’ve got, like, hundreds of rules. Pat Grady: Yeah. Jamie Cuffe: And, you know, if you’re looking at this thing at, you know, the 15th on a Friday and you’re trying to figure out, “Okay, how do I apply these, like, hundred rules to this policy document,” you know, that’s a really hard task for any person to do. And chances are you’re going to miss on page 298 of this 100-page rule list. And that’s something that AI is really, really good at, and can do that same thing at the same quality every single time. So the consistency, you can really scale your best BPO rep, that’s, I think, the kind of like promise. Pat Grady: Yeah. I think anybody who’s ridden a Waymo in San Francisco, you know, appreciates the benefit of, like, a driver that always has perfect attention, has seen every corner case a million times. You know, like, I think that we have the existence proof that a properly trained AI can do a lot of jobs better than most people. And I think applying that to all these other verticals makes sense. Lauren Reeder: Tell us a little about what it looks like concretely when you’re on site with a customer. What are some of the things that you’re hearing from them? How do you get implemented? And then what are the metrics that you track to at the end to make sure that you were successful? Like, we’ve talked at a high level. I’m curious just to get some specific examples. Jamie Cuffe: Yeah, absolutely. So a lot of our engagements start with—you know, we usually start with kind of the office of the COO. So really understanding, you know, where do they see the opportunity for AI, and coming together on some sort of—I hesitate to say proof of concept, because I actually think, like, POCs are not really—they kind of get this bad rap, and they’re not really the right thing to do in AI. It’s basically just like, get them to success as quickly as you can. And so what we focus on, it’s not like on dummy or demo data, it’s like, how can we actually go in and make them successful? So we pick something to work on. And then what’s really critical is you define the success criteria up front, which is like, where do we want to get to? And sometimes, like, you know, we encourage customers to give us, like, their hardest success criteria. Like, we want to show them that we feel confident in our product and we’re up for that challenge. And so defining those success criteria up front is really, really important. And then it’s really about, like, having this great partnership. And we’re super lucky with that with a lot of our customers is you can just—we fly on site, we work with them, we take in their existing standard operating procedures. And these are usually, like, these documents that are, you know, 50 to 100 pages long. They have, like, 60 different steps. And it’s like, you know, it’ll be like a highlight in this document of, like, you got to get this thing out from here, and then you got to enter it into this, like, admin panel and there’ll be a little, like, red box around it. Like, it’s crazy! Pat Grady: Are there, like, shadow SOPs? So, like, if you just implemented the standard operating procedures exactly as they’re given to you, would that actually give them what they want? Or are there kind of like shadow rules that are not codified in the document that you would figure out over time? Like, people are actually doing things a little bit different than what the procedures say. Jamie Cuffe: Yeah. So I think we’re lucky that because we work mostly on BPO workflows, they had to be, like, pretty well codified. Pat Grady: Okay. Jamie Cuffe: Because, like, you know, you got to hand these off to folks. But there is always a little bit of gap there, and that’s part of what when you close the distance and stand next to the customer, you figure that out really quickly. Going back to it, basically we take these standard operating procedures, we get them into what we call agent operating procedures. And so in our product that means is there’s sort of—it’s almost like a Notion-like document where you can basically write out all the steps that you need to do in natural language, and then use various different tools along the way that, you know, enable these agents to do everything they would need to do in the insurance industry. So a good example is, you know, we have a lot of tooling for long context retrieval and extracting information from really, really challenging document sets. We have a tool for, you know, doing human reasoning over lots of rules. We have a tool for, you know, writing back into a lot of the sort of mission critical vertical systems record. And then similarly a lot of our customers deal with systems that don’t have APIs. Either they haven’t been built out yet, or they might not even own that end system because it’s, you know, some intermediary. Think like a broker working with a carrier portal. And there, you know, we actually just use web agents to be able to sort of write back to this. And so that’s the critical part that I think a lot of the [inaudible] drives is, like, building out these tools with our customers to be able to get these agents live. And the critical thing is sort of doing whatever it takes to get them live. And, you know, if there’s an API, we’ll use the API. If there isn’t, we’re going to use the web agents and we’re going to make them successful. And then the last thing is sort of getting live into production from there. And so, you know, we’ve been lucky with a lot of our customers. You know, we’re working on—again in the context of their most mission critical use cases—a lot of cases, we have been their fastest company ever to POC, and their fastest company ever to production. Lauren Reeder: That’s been awesome to see. Jamie Cuffe: And that’s just going on site and spending time with them. Lauren Reeder: As you build these agent workflows, technology’s come a long way over the last even 12 months here. But I’m curious what’s on your wish list for things that you wish were easier or what you want to come next. Jamie Cuffe: Yeah. You know, I think we’ve definitely, like, benefited a ton from the scaling curve of reasoning models, particularly for our kind of very complex documents that we handle. And that is, you know, not a hundred percent solved problem, but for us a lot of the document traction stuff we are able to get, you know, much better than human reliability. The next frontier, I think, really for us is web agents. And so yeah, for any folks listening from the big labs here, we’d love the best possible web agents. Please send them our way. We are really, really lucky to be a company that I think is running a lot of those workflows and has a lot of really great use cases in insurance. It’s sort of like the canonical kind of like task is basically doing crud operations on insurance admin panels. But I’ll be honest, they look very different from booking a restaurant or booking a flight or a lot of the sort of web agent demos that we see. Lauren Reeder: Yeah. Jamie Cuffe: And so a lot of our work is just making those successful. So web agents would be really great. And I think the last one is sort of thinking about longer term, so the opportunity for RL and reinforcement fine tuning in what we do. Because of the way that we’ve structured our product and because we are, you know, long AI and what it can do longer term, you know, our product is set up in a way where it’s not sort of this workflow diagram builder, which where the AI agent only has context for, you know, that individual block that it’s in. The analogy I draw here is like, if you had your best person on your team, you’re not going to put them in this box and be like, “Okay, you need to categorize these documents,” and not have any sense of what happened before or after in the workflow. And so what we’ve really built into the product is the AI being able to make the decisions end to end and follow these agent operating procedures. And so what that means longer term is it really sets us up well to benefit a lot from RL. Because the agents are working from input all the way through to output in a way that is highly gradable, where you can see kind of the accuracy of the work that’s being done, there’s an expected output that you can grade against and create a reward function, it makes it very, very easy to actually do RL for each of these individual workflows for our individual customer at scale. And so I think if you think about kind of the long term of the product, it’s not codifying all this stuff into determinism to try to make the agent successful. It’s really giving the agent sort of this perfectly-modeled world that it can work in and being able to do sort of RL end to end across all the tool calls. And so I think that’s one of the big wish lists and sort of areas that we see the world going. Pat Grady: What has surprised you about building with AI, or what advice would you have for other founders who are building an AI or thinking about doing so? Jamie Cuffe: I think two things have surprised me. One is how much fun it is. I mean this is like such a great time to be building, and there’s all this stuff. People talk about being able to build faster with AI—and certainly that’s the case, you know, we’re lucky to use all, you know, the cursors and cog codes and codexes that help our team be really, really successful—but even more than that, there’s all this stuff that was, like, really hard to codify in software that is now really, like, easy to codify with LLMs. And so we’ve been able to just build workflows that, like, traditionally I think would have taken decades to build the software and all the sort of knobs and dials and requirements to sort of get those live into production, because you can offload a lot of that to the agent. So it is a really fun time to be building. The second thing I think that’s really, really important, and maybe it’s some advice for founders, is to go be a forward-deployed engineer. Pat Grady: [laughs] Lauren Reeder: [laughs] Jamie Cuffe: And ideally come do it at Pace. But I really do think that is, like, the best training ground for becoming a founder, because you go and spend a lot of time with customers, you see their problems and you help them get it into production. And that’s, you know, really at companies, like, you’re either building or you’re selling, and forward-deployed engineers basically do both. So that’s my big advice. If you’re thinking about starting a company, it will get you close to problems, it’ll get you working on the right stuff, and you’ll build the right skill sets to build a company. I was very lucky with that at Retool. I think, you know, I was very fortunate. I think both David Hsu, our CEO, and Bryan Schreier, who we’re lucky to be working with again on Pace, really were very kind to sort of take a big bet on me early on at Retool to sort of figure out how do we build out our post-sales motion, how do we take a lot of our new products from zero to a hundred? And I think that really, really set me up to start a company in a way where it’s never easy, but it has felt much, much more tractable this time than the first time I started a company. And I think that is—yeah, I’m very, very grateful for that, and I encourage other folks to sort of find that path and find people like that that will kind of back you again and again. And yeah, I feel very fortunate for that. Pat Grady: Awesome. Lauren Reeder: Shall we do some hot takes? Jamie Cuffe: Let’s do it. Lauren Reeder: Okay. What was your hot take from interning at Sequoia? What did you learn? Pat Grady: Other than Andrew Reid’s love of Constellation Software? Jamie Cuffe: [laughs] I’m not sure if you remember this one, Pat, but we were out on the back patio in the 2800 office, and I think you asked me a similar question, which was sort of what did you find most surprising about Sequoia? And my answer then is still my answer today, which is Sequoia is a place that has benefited from an incredible amount of success, but no one ever rests on their laurels here. We were very lucky to be incubated out of Sequoia’s office in New York. And every time you walk out of the elevators, there’s this sort of graphic that’s going on on the screen there that says “We’re only as good as our next investment.” And it’s awesome. Like, I just love that mentality. And I think that’s like one thing that permeates also over to our culture at Pace is just like, you know, every quarter you’re set back to zero. Every new customer, you’ve got to make them successful. I mean, they care that you’ve done this in the past but, like, you’re really meant to—you know, like, you got to make them successful. And so, you know, you’re only as good as your next customer. Pat Grady: Love it. Love it. Lauren Reeder: All right, company number two. What are you doing differently this time? Jamie Cuffe: I think there’s a couple of learnings that I think have been pretty critical this time, and there’s a couple of things we’ve done the same, which were also great. So one of the ones that I feel like I was very lucky to learn at Retool is one of Retool’s values was Retool is a business. And basically, you know, Retool is very focused on delivering value for our customers and revenue. And I think we take a very similar perspective, which is, you know, there’s a lot of things you can do when you’re starting a company, and a lot of them are kind of distractions. You know, like, most times, fundraising? Distraction. Most times, like, you know, working with, like, I don’t know, lawyers or sitting at the office or whatever. A lot of these things can be kind of a distraction. Like, you want to make them run, but you want to be spending as much time as possible working with your customer. And so that’s like one of my biggest takeaways is just go, and you can’t spend too much time on that, working with your customer, making them successful, and focusing on moving the metrics that really matter, which is revenue growth, gross margins, a lot of the things that we think a lot about. I think the other big thing is who you work with. And I was incredibly lucky in my last company to have an amazing co-founder. And this time with Pace, I actually started the company as a solo founder, and have this incredible team that we’ve been able to build. And one interesting thing, which is a hot take: there’s, like, a sentiment that people don’t really like solo founders generally speaking as like an investment. And I actually think that makes complete sense when you’re at the very early stages, you know, the sort of, like, existential stages of a company because, you know, it makes a lot of sense to have a co-founder there to, like, help you through, you know, wandering the desert or whatever and making the company successful. And very thankful to my co-founder for that at my last company. But once you have figured out where you’re going, it’s all execution risk. Like, for Pace, everything is execution risk now. Like, it’s so clear what we’re doing. It’s just executing. There are a lot of benefits of starting a company as a solo founder and the team that you can build. So we’ve been super lucky. You know, our first engineer was, like, Retool’s second engineer, this guy Yogi. Second hire was also in the Sequoia portfolio, Luis, who was head of [inaudible] engineering at Loom. And both of them and also our broader team, they take on a lot of the roles that in the sort of capacity that I think traditionally might have been kind of just a conversation with a co-founder where you don’t actually involve the team. So, like, a lot of our team was involved in, you know, shaping our values. A lot of the team is involved in critical go-to market hires. A lot of our team is involved in product decision making that might traditionally have just been made by co-founders. And I think it actually lets you hire a much, much stronger team and build a stronger culture. And the last thing that we definitely kept the same is working with Sequoia and working with Ryan and you, Lauren. It’s been fantastic, and I’m very, very thankful for that. I think one of the amazing things is being able to work with a partner that has known you almost over a decade. You know, I was lucky to meet Bryan when I was still in college, and I think this is kind of a funny story of how we met was Bryan gave this talk, and the talk was basically about mentoring and how to build these great mentor relationships. And I think his advice was basically lead with value and then you’ll figure out kind of like how to go from there, like, kind of giving upfront basically. And I think at the time he dropped this, like, small Easter egg of “Hey, I’m actually going to the Princeton campus to talk with the Princeton president about entrepreneurship on campus and I’d love to know what to say.” And so I kind of was like, “Hmm, interesting. I think I could probably help with that.” So I pulled an all nighter and basically sent him this, like, 20-page report of here’s where I think, you know, Princeton entrepreneurship could use your help. And that became, you know, a lot of what you know, he’s since seen basically every step of my career along the way, you know, from Sequoia to starting my first company to Retool, and going to many board meetings where I learned a ton from him all the way through to starting this company. And to be able to have amazing partners like Bryan, like you Lauren, where we can have a really strong sort of board relationship where it sort of almost feels like that sort of like co-founder relationship where we’re very much, like, in the trenches together, I think is incredibly unique to me and I think makes Pace a much stronger company because of it. Lauren Reeder: Thank you for joining the show. It’s been amazing to have you and hear the full story behind Pace that’s just beginning. Jamie Cuffe: Thank you for having me. This was a blast. <div class="framer-mcvrsd" id="

Jamie Cuffe is solving one of AI's hardest problems: getting conservative, regulated industries to trust autonomous agents with mission-critical work. At Pace, he's building AI that replaces traditional BPOs in insurance, handling everything from email triage to claims processing with 50-75% cost savings. Drawing on his experience at Retool, Jamie emphasizes the importance of "closing the distance" with customers through forward-deployed engineering and being "the rock" that clients can rely on. He shares how focusing on top-tier insurance carriers and maintaining exceptionally high standards is enabling Pace to capture a meaningful share of the $400 billion BPO market while building a durable business model - at AI-native velocity.

Hosted by Lauren Reeder and Pat Grady, Sequoia Capital

本集资源与出处