AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents
频道: AI Engineer
视频: https://www.youtube.com/watch?v=l0FLhNqBOic
原文语言: en
统计: 共 19 轮 · Vasuman Moza 11 · JD 6
[0:01] Vasuman Moza
[music] All right, first and foremost, thanks so much for being here. Um, it's been a great experience. You know, obviously chatting amongst uh other industry giants like Curser and Factory and and Dropm and I'm sure you guys are mostly here for them, but thanks for sticking around for this talk. My name is Voss. I'm the CEO of Veric Agents. We work with some of the largest companies on the planet transforming them from the inside out with uh AI and agents. Um and because of the nature of our work which is highly bespoke, we go very deep into our clients. It requires a lot of forward deployed engineering. And this conversation is around why that's so important, how we approach it at Veric uh and some of the internal tooling that we've created internally to allow us to scale that forward deployed motion without you know increasing headcount exponentially. And it's titled the next bottleneck because I fundamentally believe the next bottleneck is how deep can you go into a customer without scaling headcount uh exponentially. How can AI do that job for you?
[音乐] 好，首先非常感谢大家到场。这一路体验很棒，前面跟 Cursor、Factory、Dropbox 这些行业巨头同台交流，我知道你们多半是冲着他们来的，所以谢谢你们留下来听这场。我叫 Vas，是 Varick Agents 的 CEO。我们跟全球最大的一批公司合作，用 AI 和 agent 把它们从内到外改造一遍。我们的活儿高度定制化，必须扎到客户内部很深的地方，这就需要大量的 forward deployed engineering（前置部署工程）。今天这场就是想讲：为什么这件事这么关键、我们在 Varick 是怎么做的，以及我们内部造了哪些工具，让我们能把这套前置部署的打法规模化，而不用让人头数指数级往上翻。标题叫「下一个瓶颈」，是因为我打心底里认为，下一个瓶颈就是——在不指数级堆人的前提下，你能扎进客户多深？这活儿能不能让 AI 替你干？
[1:07] Vasuman Moza
So as stated previously, AI is solving the execution of work. Um if you were to look back a couple years ago before uh you know thinking agents and reasoning agents were a widespread phenomenon uh and I had asked you how many of you have used AI to solve an endto-end task. the answer would be slim to none. But if I asked that same question to everyone today saying, "Has AI solved an endto-end task for you today?" I'm sure every single one of you would raise your hands. So clearly execution is no longer the core bottleneck. The models are improving to the point where intelligence is no longer the constraint and harnesses are being built in a way that allow us to use whether it's browser use tooling or API tooling uh with very robust MCPs that allow us to execute work uh with near perfection. The difference and the bottleneck that is still here is how much can you understand the business because every business, every consumer is different.
就像前面说的，AI 正在解决「执行」这一环。回头看两三年前，那时候会思考、会推理的 agent 还没普及，如果我当时问在座各位：有多少人用 AI 端到端完成过一整件事？举手的估计寥寥无几。但今天我再问同样的问题——今天有没有 AI 帮你端到端搞定过一项任务？我相信在座每个人都会举手。所以执行显然已经不再是核心瓶颈了。模型好到「智能」不再是约束，harness（外壳/工具层）也搭得越来越好，不管是用浏览器操作还是调 API，配上足够健壮的 MCP，我们几乎可以近乎完美地把活干完。真正的差别、真正还卡在那儿的瓶颈是：你对这门生意能理解多深。因为每家企业、每个客户都不一样。
[2:03] Vasuman Moza
Uh one sales department for a healthcare company for example operates completely differently than the sales department for a SAS company. And this is something that we see with our work today at Veric Agents. And if there are any business operators in the room, you know exactly how hard it is to wrangle uh the latest models to solve for your specific use cases. It's very difficult to extract that context from your you know employees and from your team and it's very difficult to feed that into an API call or a simple model call uh that doesn't break down very quickly. So the bottleneck is how much can you process re-engineer how much can you process understand and that's the job that we do here at Veric. So right now operations are fundamentally centered around the human. uh right now the work that you do today is done by humans whether it's on top of software or completely agnostic to software uh but in the future operations will be centered around AI and this means not only you know providing companies with AI tooling like a cursor cloud codeex like a factory like any of the other brilliant AI tools that you sure you're experiencing here today but also changing the operations and the processes themselves and fundamentally that is the role of a forward deployed engineer it's going into the company, understanding how things run today and reinvisioning what it could look like tomorrow. And we believe that is our job at Veric and why forward deployed engineering is such a core part of what we do.
举个例子，一家医疗公司的销售部门，跟一家 SaaS 公司的销售部门，运作方式完全是两回事。这是我们在 Varick Agents 每天都能看到的。在座如果有做业务运营的，你们最清楚，要把最新的模型驯服到能解决你自己那套具体场景有多难。要把上下文从员工、从团队脑子里掏出来，本身就很难；再把它喂进一次 API 调用或者一个简单的模型调用，而且不会很快就崩掉，更难。所以瓶颈在于：你能把多少流程真正理解透、并重新设计一遍。这正是我们在 Varick 干的事。今天的运营本质上是以人为中心的——今天的活儿是人在干，有的是在软件之上干，有的干脆跟软件无关；但未来的运营会以 AI 为中心。这意味着，我们不光要给企业提供 AI 工具——像 Cursor、Claude Code、Codex，像 Factory，以及今天你们在这儿体验到的其他优秀 AI 工具——还要改变运营方式和流程本身。而这从根本上就是 forward deployed engineer 的角色：走进企业，搞清楚今天是怎么跑的，再重新想象明天可以长成什么样。我们认为这就是 Varick 的职责，也是为什么 forward deployed engineering 是我们工作的核心。
[3:27] Vasuman Moza
So a forward deployed agent, what does that really mean? So why do we need FTEEs? As stated previously, I'm not going to, you know, go into this too much. I'm sure you've been hearing a lot of this today. Uh FTEEs are responsible for a few different things. One is they map the way the humans are doing their work today. So how we do that at Veric is several forward deployed engineers will be embedded directly with a customer. You can imagine it's a enterprise company with thousands of employees but we'll scope it down to a single department. In a finance department for example we'll have them sit down with the process leads for AP AR card reconciliation banking billing FPNA etc. So interviewing every single one of these process leads to understand not only how are things running today but more importantly when things go wrong what happens. You know, a lot of the documentation that you have at companies is about the golden path and maybe an edge case or two, but this is still fundamentally not the reality where when we talk to customers, it's it's a lot of, you know, Sarah in AP handles the workflow today in this way, but when things go wrong, she actually sends it over to Chris, who then takes 4 days of cycle time to handle reconciliations between a purchase order and an invoice. Those are the realities that are one unique to every single company. the way that they handle things is different from one company to the next and two the real bottleneck for why AI can't just run a muck and handle endto-end processes without the handholding that you see today in the enterprise. Um so this is the first
那么「forward deployed agent」到底是什么意思？我们为什么需要 FDE？前面已经说过，我就不展开太多了，今天这个话题你们估计听了不少。FDE 主要负责几件事。第一，把人现在是怎么干活的画出来。我们在 Varick 的做法是：派几名 forward deployed engineer 直接驻场到客户那边。你可以想象那是一家几千人的大企业，但我们会把范围收窄到某一个部门。比如财务部门，我们会让他们坐下来，跟 AP（应付）、AR（应收）、对账、银行、账单、FP&A 等各条线的流程负责人一个个聊。挨个访谈这些流程负责人，不只是搞清楚今天是怎么跑的，更重要的是——出问题的时候会发生什么。企业里大部分文档写的都是「正常路径」，顶多再加一两个边缘情况，但那根本不是现实。我们跟客户聊下来常常是这样：AP 部门的 Sarah 今天是按这套流程处理的，但一出问题，她其实会转给 Chris，而 Chris 处理一笔采购单（PO）和发票（invoice）之间的对账，要花 4 天的周转时间。这些才是现实——第一，它对每家公司都是独一无二的，A 公司的处理方式跟 B 公司完全不同；第二，这才是 AI 为什么不能在企业里撒开手端到端跑完全流程、总得有人盯着的真正瓶颈。这是第一部分。
[4:50] Vasuman Moza
section which is mapping how humans do the work. The second is really re-engineering the process around AI. So what does this mean? You know, there's a lot of talk being given today in terms of slapping AI onto broken processes, and that's fundamentally why you don't see the ROI across the industry today. There's a lot of, you know, semi-outdated but still very relevant statistics like the MIT review saying that 95% of generative AI pilots fail to reach production or the other statistic which was 87% very similar thing that most AI pilots don't produce measurable ROI or they don't ship to production period. And the reason for that is a lot of the time AI is being slapped on top of broken processes in a way that the AI doesn't actually understand how to do things. Um you see that this at the simplest level with coding where as an engineer it's very difficult even with goal loops and the the latest technology there uh to just say go and solve this for me and have it run off and refactor entire code bases without some degree of human input. Now if you extrapolate that to a business context, these are very non-technical operators in finance, sales, marketing, procurement, logistics, uh etc. So giving them this AI tooling will not allow them to receive the same ROI that a software engineer might be able to to uh produce or create. Um so what this means is you need for deployed engineers to help them re-engineer their current process around AI. it needs to be not too different to where they don't understand, you know, how to operate the system. For example, if they're used to an 11step workflow and you come in and change that with a
第一部分是把人怎么干活画出来。第二部分是围绕 AI 重新设计流程。这什么意思？今天大家都在讲一件事：把 AI 硬糊在一个本来就烂的流程上——这就是为什么整个行业今天看不到 ROI。有不少统计数据，虽然稍微有点旧但依然很说明问题，比如 MIT 那份评论说 95% 的生成式 AI 试点走不到生产环境；另一个数字是 87%，说的差不多是一回事，大多数 AI 试点要么产不出可衡量的 ROI，要么压根上不了生产。原因就在于，很多时候 AI 是被硬糊在坏掉的流程上，AI 根本不理解事情该怎么做。最简单的例子就是写代码：作为工程师，哪怕有了 agent 的自动循环和最新的技术，你也很难直接说一句「去帮我把这个搞定」，然后它就自己跑去把整个代码库重构完，中间完全不需要人介入。你把这件事外推到业务场景，那边是财务、销售、市场、采购、物流这些完全不懂技术的人。所以你把 AI 工具丢给他们，他们拿不到软件工程师那种级别的 ROI。这就意味着，你需要 forward deployed engineer 去帮他们围绕 AI 把现有流程重新设计一遍。这套新流程不能跟原来差太远，差太远他们就不会用了——比如他们习惯了一个 11 步的流程，你上来给改成一步……
[6:28] Vasuman Moza
one-step, they might be taking it back, the adoption rates might suffer, etc. As was alluded to in previous presentations. Um, but at the same time, it needs to be different enough to where you're actually capturing the ROI. Meaning, you do say, "All right, four out of these eight steps will be handled completely autonomously. The other three will be handled with some human in the loop intervention and one step of that process will be handled by a human period either because the risk is too high or because you know it's it's not unique enough for an agent to produce measurable value in that specific step of the process. So that's the second major step of a forward deployed engineer. It's why we need them. And third and finally, and this is what I want to uh bring one of my heads of engineering to discuss in just a moment is actually deploying these agents on top of existing systems. So fundamentally at Veric, we believe that the AI wave left a lot of enterprise behind. A lot of enterprises married to their systems of record. Not everybody, but most of them are. Uh they've migrated to Netswuite, they've migrated to Dynamics, they migrated to SAP and Salesforce. And when you pitch them AI solutions that live completely desperate from these systems, uh you're ignoring the reality of enterprise. One of the quotes from our clients said that they spent $5 million and 5 years migrating to uh Netswuite. That's a real quote. So if you're telling them, hey, I have this fancy AI tooling, but by the way, you have to migrate off of Netswuite, they're going to tell you to get out.
……他们可能反而会退回去，采纳率会掉，等等，前面几场也提到过这点。但同时它又必须差得够多，多到你真能抓到 ROI。也就是说，你会明确讲：这八步里有四步完全自动化跑，另外三步做 human in the loop、留人介入，还有一步就是纯人工——要么因为风险太高，要么因为那一步太没有特殊性，agent 在那儿产生不了可衡量的价值。这就是 forward deployed engineer 的第二件大事，也是我们为什么需要他们。第三件，也是最后一件，我一会儿想请我的工程负责人上来讲——就是把这些 agent 部署到既有系统之上。我们 Varick 有个基本判断：这波 AI 浪潮把很多企业甩在了后面。大量企业跟自己的系统 of record（记录系统）绑死了。不是全部，但大多数是。他们迁到了 NetSuite、迁到了 Dynamics、迁到了 SAP 和 Salesforce。你要是拿一套完全独立于这些系统之外的 AI 方案去跟他们讲，那就是在无视企业的现实。我们有个客户原话是：他们花了 500 万美元、5 年时间才迁到 NetSuite。这是真事儿。所以你要跟他说，嘿我这儿有个很酷的 AI 工具，不过顺便说一句，你得先从 NetSuite 上迁出来——他会直接请你出去。
[7:54] Vasuman Moza
They don't have any appetite for that. So what we believe in Veric believe in at Veric is we'll build the agents on top of your systems of record and the way that we do that is quite uh unique. We have our own Veric OS platform that allows us to spin up agents, monitor them uh etc with the full governance and evalu baked in but at the same time it lives on top of your systems of record. So if you are on a Salesforce or a Netswuite or a Dynamics or an SAP, we will not ask you to migrate off of that. And that is where enterprise needs AI the most uh because they're too large to move up. So why build the FD agent in the first place? As mentioned previously, I think everyone is saying that 2026 and onwards is the year of the forward deployed engineer. And to some extent, we believe that's completely correct. There has never been more of a need to go deep into customers and understand their business use cases and help them adopt the latest in AI tooling. But at the same time, we realize that it's actually very difficult to find forward deployed engineers who are both the technical like top 1% who are really able to understand and speak AI uh 10,000 times better than the average, you know, enterprise customer, but also have the communication and human skills needed to be, you know, as alluded to previously, very high IQ, high EQ, extracting the information from the customer and meeting them where they are in real time. You know, typically you'll have consultants that you then train on the technical side or engineers that you then kind of train on the softskll side, but it's very hard to find people who
他们对这事儿一点胃口都没有。所以我们 Varick 信的是：我们把 agent 建在你的 system of record 之上。我们的做法挺特别的——我们有自己的 Varick OS 平台，可以拉起 agent、监控它们等等，治理和 eval 都是内建的；但同时它是跑在你的记录系统之上的。所以你用的是 Salesforce、NetSuite、Dynamics 还是 SAP，我们都不会要求你迁走。而这恰恰是企业最需要 AI 的地方——因为它们体量太大，根本挪不动。那我们为什么要造这个 FD agent？前面提到，现在人人都在说 2026 年以及往后是 forward deployed engineer 的年份。某种程度上我们完全同意。从来没有哪个时候像现在这样，需要扎进客户内部、理解他们的业务场景、帮他们把最新的 AI 工具用起来。但同时我们也意识到，要招到合适的 forward deployed engineer 极其困难：他既要是技术上那 1% 的顶尖，能理解 AI、能把 AI 讲明白的程度是普通企业客户的一万倍；又要具备沟通和与人打交道的能力——像前面几位说的，高 IQ 加高 EQ，能实时从客户嘴里把信息挖出来，还能在客户所处的水位上跟他对话。通常你手上要么是顾问，然后你再给他补技术；要么是工程师，然后你再给他补软技能。但两头都强的人，非常难找。
[9:23] Vasuman Moza
are, you know, the best of both. Um, so the FD agent is our effort to bolster the existing forward deployed engineers that we do have. So for example, allowing one forward deployed engineer or forward deployed strategist to manage and maintain several client communications. I know that most of the folks in the room are technical, but it's very easy to misunderstand how deeply involved you have to be with the client. They're emailing you 24/7. They're sending you hundreds of pages of documentation and every single process lead will pull you in a different direction. AP relies on AR, relies on reconciliation, relies on FPNA, and they each have their own version of what they think is the most important. So being able to manage that context and being able to serve them all equally while also not hiring 50 people to do so is fundamentally very important and it's how we at Veric avoid being you know a traditional consultancy while also offering that handheld handholding and like very human experience human- centered approach of consulting that we think we do think is very valuable. Um so in the past in 2024 and around that time execution work was still the bottleneck. This was before the models gain the intelligence and the harnesses gain the integration abilities that allowed them to move past the execution bottleneck. Um, now the AI models are trained to solve the execution of knowledge work. I will go as so far as to say that knowledge work is almost entirely solved. The difference is and what we're realizing now is that designing how work gets completed around AI is the next bottleneck. It's the
所以 FD agent 就是我们用来给现有 forward deployed engineer 加杠杆的努力。比如让一个 forward deployed engineer 或者 forward deployed strategist 同时管好几个客户的沟通。我知道在座大多是技术出身，很容易低估你得跟客户绑得有多深。他们 24/7 给你发邮件，甩给你几百页文档，每个流程负责人还会把你往不同方向拽。AP 依赖 AR，AR 依赖对账，对账又依赖 FP&A，而他们每个人心里都有一套「什么最重要」的排序。能把这些上下文管住、能一碗水端平地服务所有人，同时又不用为此招 50 个人——这件事至关重要，也正是我们 Varick 既不沦为传统咨询公司、又能提供那种手把手、非常有人味的咨询体验的原因，我们认为这种体验很有价值。回到过去，2024 年前后，执行本身还是瓶颈。那时候模型还没到今天这个智能水平，harness 也还没有今天这样的集成能力，跨不过执行这道坎。而现在，AI 模型已经被训练到可以解决知识工作的执行环节。我甚至敢说，知识工作几乎已经被解决了。区别在于，我们现在意识到：围绕 AI 去设计「活儿该怎么被完成」，才是下一个瓶颈。
[10:56] Vasuman Moza
ability to go deep within the customer, redesign their workflows, deciding what should be automated versus shouldn't, and building this in a robust and scalable way on a platform that moves the needle for our clients. You know, as opposed to doing a point solution which promises to transform just one part of your sales process, for example, uh maybe it's prospecting. Uh that ROI might deliver 5 to 10% ROI for you as a sales function. Same thing on finance. If you're just doing AP and no other part of your department, you might have a 5 10% ROI. But at Veric, we deliver departmentwide transformations, holistically transforming the entire department at a time. And that's how we get the ROI that we see for our clients, which is 25%, 50%, 75%. Truly giving them back, you know, the three things, which is revenue uplift, cost savings, and risk mitigation, as was so eloquently stated previously. and an AI FDE is trained to re-engineer these necessary tasks around AI. So I want to invite my head of engineering uh JD Puit to come up and and share some more of the deep technical stuff on our FD agent uh because I haven't written a line of production code in a while. So here's JD.
也就是能不能扎进客户内部，重新设计他们的工作流，判断什么该自动化、什么不该，然后在一个平台上把这些东西做得健壮、可规模化，真正给客户带来实质变化。这跟点状方案不一样——点状方案承诺改造你销售流程里的某一环，比如获客线索这一段，那对整个销售职能来说可能只有 5% 到 10% 的 ROI。财务也一样，你只做 AP、部门其他环节都不碰，可能也就 5%、10% 的 ROI。但在 Varick，我们交付的是部门级的整体转型，一次改造一整个部门。这就是我们能为客户拿到 25%、50%、75% 这种 ROI 的原因，实打实地还给他们三样东西——收入提升、成本节约、风险规避，前面有位讲者说得非常漂亮。而 AI FDE 就是被训练来围绕 AI 重新设计这些必要任务的。所以我想请我的工程负责人 JD 上来，跟大家多讲讲我们 FD agent 背后更深的技术细节，因为我已经好一阵子没写过一行生产代码了。有请 JD。
[12:06] JD
Okay, thanks.
好，谢谢。
[12:08] Vasuman Moza
And maybe if we can get his mic going.
看看能不能帮他把麦克风打开。
[12:15] JD
Great. Thank you. Um thanks Voss. So, uh, this project to give tools to our FDE, um, basically started with me. I lead the platform team and we're over on one side of the office. We're hanging out. We're chilling. We're having a great time. Uh, Codeex, Claude, we're all hanging out. And then I look over at the FD side of the room. They look stressed. They are sleepd deprived. They're extremely miserable. They've got clients emailing them 24/7. I'm like, "Oh my god, you guys haven't slept at all." So, I go and I start talking to them and I'm like, "Okay, what is your guys process like right now? How are you actually engaging with these clients?" like well we you know upload about 150 pages of documentation to claude and then we prompt claude and then we wait like 2 minutes and then we get analysis and then it's verbose and incorrect and it kind of sucks and I was like all right we got to fix this. So we have been working on an FD agent which is the codeex for our FDS basically and there's three stages of it um the last of which is certainly still in in development.
好，谢谢。谢谢 Vas。给 FDE 做工具这个项目，基本上是从我这儿起的头。我带的是平台团队，我们坐在办公室的一头，天天挺惬意，日子过得很舒服，跟 Codex、Claude 一块儿玩得挺开心。然后我一扭头，看向办公室另一头的 FDE 那边——一个个压力爆表、严重缺觉、惨到不行，客户的邮件 24 小时不停地往他们邮箱里砸。我当时就想：天啊，你们是一点儿觉都没睡吧。于是我过去找他们聊，问：你们现在到底是怎么干活的？跟这些客户具体是怎么打交道的？他们说：就是把大概 150 页的文档一股脑扔给 Claude，然后写个 prompt，等上两分钟，拿回一份分析——又臭又长，还是错的，体验相当糟糕。我一听，行吧，这个必须修。所以我们一直在做一个 FDE agent，本质上就是给我们 FDE 用的 Codex。它分三个阶段，其中最后一个阶段目前肯定还在开发中。
[13:07] JD
The first is what we call the engagement. The the first function is the is the engagement agent. And essentially this is a better version of claude built just for our FDES. It's their assistant. They have it pulls in their granola notes. It synthesizes documentation. It reads PowerPoint slides. It allows them to query and say who's responsible for this process. Uh I got an email that mentioned Sarah spelled you know this way. And I have a you know Slack message with different way. Are these the same people? because these are the questions that our FDES are asking all day every day and they waste a ton of time just waiting on on claw to respond. So the engagement agent is their way of it's their it's their assistant to build um to build the workflow. Then there's the workflow agent and what we did is we took our engagement agent and we embedded it inside of our platform so that when our FTEEs go and they actually build the workflow, the FD agent is right there saying, "Oh, you forgot about this edge case. um you should probably ask me uh you know who owns this process so I make sure the email goes to the right place and it lives it's basically I can talk about more of the details on the next slide but whoops it lives uh it lives inside of our inside of our platform it works next to claude or codeex whatever model you're using um and make sure that the workflow that the FD is constructing is actually uh it correctly shadows the process that we want to engineer. And then there's the final stage which we're not at yet which is a um an autonomous assistant for FTEEs where it's receiving emails from clients who say actually I want to
第一个阶段我们叫 engagement（客户交付项目）。第一项功能就是 engagement agent。说白了，它就是专门为我们 FDE 打造的、更好用的 Claude，是他们的私人助理。它会自动拉取他们的 Granola 会议记录，把文档归纳整合，能读 PowerPoint 幻灯片，还能让他们直接提问，比如「这个流程到底归谁负责」。又比如：我收到一封邮件里提到一个 Sarah，是这么拼的；Slack 里又有一条消息提到 Sarah，拼法不太一样——这俩是同一个人吗？因为这些就是我们 FDE 每天从早问到晚的问题，而他们大量时间就耗在干等 Claude 出结果上。所以 engagement agent 就是他们搭建 workflow 时的那个助手。接下来是 workflow agent。我们的做法是把 engagement agent 直接嵌进我们自己的平台里，这样 FDE 真正动手搭 workflow 的时候，FDE agent 就在旁边提醒：「哎，你漏了这个边缘情况」「你最好问我一下这个流程归谁管，我才能保证邮件发到对的人手上」。细节我下一页再展开——总之它就住在我们平台内部，和 Claude、Codex 或者你在用的任何模型并肩工作，确保 FDE 搭出来的 workflow 真的能准确映射我们想要工程化的那个真实流程。然后是最后一个阶段，我们还没做到——一个给 FDE 用的自主助理：客户直接发邮件过来说，我其实想改一下……
[14:46] JD
change you know where my QC report goes to. I want to you know change it to a different email etc. and our agent is able to process that information, query the understanding of the company that we currently have, ship an autonomous change to the workflow on top of our platform, and then our FTE never has to get involved, saving their time for the much more highv value work of sitting down, interviewing with the clients, really understanding what their process is, um, and not dealing with all of the small little minutia that anyone who has been in FTE can tell you, uh, takes up a lot of their time. So, how do we how do we build this? Um, the first thing is we need some single source of truth, some representation of a company's uh functioning. There's a lot of different ways to do this. If you were at the booths downstairs this morning, there was, you know, five companies trying to sell you a graph DB and you can just use Postgress, whatever it is. Yes, I'm looking at you. Um, [clears throat] doesn't really matter what you use, but the point is we use a dependency graph. Most of these workflows inside of enterprise are remarkably linear. they just have a lot of cycles in them. But at the at the end of the day, the process owners want things to be as dependency driven as possible. They don't want person C in the process to have to deal with something before A and B have approved it. So a dependency graph is a very nice representation of this.
……改一下我的 QC 报告发到哪里，想换成另一个邮箱，诸如此类。我们的 agent 能处理这条信息，去查询我们现有的那份对这家公司的理解，然后在平台上自主地把 workflow 改掉，全程不需要 FDE 插手。省下来的时间就能投到价值高得多的事上：坐下来跟客户访谈，真正把他们的流程搞明白，而不是被那些鸡毛蒜皮的琐事缠住——任何做过 FDE 的人都会告诉你，这些琐事吃掉了他们大量时间。那我们是怎么把它做出来的？第一件事，我们需要一个 single source of truth，一种能表示这家公司如何运转的结构。做法有很多种。你要是今天上午去楼下展区逛过，会发现有五家公司在向你兜售 graph DB，其实你用 Postgres 也行，用什么都行。对，我说的就是你们。用什么其实不重要，重点是我们用的是依赖图（dependency graph）。企业内部这些 workflow 大多数其实相当线性，只是里面回路特别多。但归根到底，流程的 owner 希望一切尽可能由依赖关系驱动。他们不希望流程里的 C 在 A 和 B 还没批完之前就得先动手。所以依赖图是一种非常合适的表示方式。
[16:06] JD
Um then we do our own model training. Um and there's really two parts to this problem that we're trying to solve. The first is given extracted context for the FTE do we get a good highquality output and the answer is with claude honestly no which is kind of surprising but the really and I'm sure you guys have experienced this when you are trying to do a long analysis frontier models are extremely verbose and they lack the um you know I would say the I only started believing in consultants once we started hiring them at Veric. And the reason is they're so good at figuring out what is the part of the detail the client actually cares about and what is the part that can get glossed over. And Frontier models have absolutely no concept of this. So we started post-training our own models on top of on top of open source models. We're a fan of Kimmy K26, but a lot of these would do different a lot of these would do fine to really get that nice balance between detailed and uh clarity that the frontier models often often lack. So that's that's a bit about writing a good normalized process flow from extracted context. But there's the second half of the challenge which is getting good at traversing at extracting the right context. So we might have this huge knowledge graph but it's remarkably difficult to traverse this knowledge graph in a reliable way that finds us the right context. So once we have our post-trained model, we create an RL environment where we have exposed our own custom tools specifically designed to traverse our knowledge graph. These tools are things like make sure person A and person B are actually the same
接下来是我们自己做模型训练。我们要解决的问题其实分两半。第一半是：把抽取好的上下文喂进去，能不能给 FDE 产出一份高质量的结果？说实话，用 Claude 的答案是不能——这还挺出人意料的。但我相信你们肯定也遇到过：做长篇分析的时候，前沿模型（frontier model）啰嗦得不行，而且缺了点东西。我得说，我是在 Varick 开始雇咨询顾问之后，才真正相信咨询顾问这个职业的。原因是他们太擅长判断：哪部分细节是客户真正在意的，哪部分可以一笔带过。而前沿模型对这件事完全没有概念。所以我们开始在开源模型之上做自己的 post-training。我们比较偏爱 Kimi K2，不过换成其他很多开源模型也一样跑得不错——目标就是拿到详实与清晰之间那个漂亮的平衡点，而这恰恰是前沿模型常常缺的。以上是关于「从抽取到的上下文写出一份规范化流程」这一半。挑战的另一半是：把上下文抽对——也就是把图遍历好。我们手里可能有一张巨大的知识图谱，但要稳定可靠地遍历它、找到正确的上下文，难度非常大。所以在拿到 post-train 之后的模型之后，我们又搭了一个 RL 环境，在里面暴露出我们自己写的、专门用来遍历知识图谱的工具。比如其中一个工具是判断 A 和 B 到底是不是同一个人——
[17:47] JD
person because a lot of you know there's a lot of mics in every company we work with and Claude gets very confused by this. Um, a second thing might be something like um uh identifying identifying redundancy cycles or uh like violations of your DAG inside of your knowledge graph. And so in our RL environment, we train really good tools to do a good job of traversing this graph to extract the right context. So that's how we solve the two problems, writing good analysis from the context and extracting the correct context in the first place. And then the third part which we are um still building towards is an agent that operates autonomously um to do the kind of uh workflow management on the small things that the FD doesn't have to waste their time on. I think that's all I've got. I'll hand it back over to Voss. Thanks JD. So where does that leave us? And I want to share a little bit more about Veric.
——因为我们服务的每家公司里都有一堆叫 Mike 的人，Claude 一碰到这种就彻底晕了。第二个工具可能是识别冗余回路，或者找出知识图谱里违反 DAG（有向无环图）约束的地方。就这样，在 RL 环境里我们把这些工具训得很好，让模型能可靠地遍历这张图、抽出正确的上下文。这就是我们解决那两个问题的办法：一是从上下文写出好的分析，二是一开始就把正确的上下文抽出来。至于第三部分，我们还在往那儿做：一个能自主运行的 agent，替 FDE 处理那些琐碎的 workflow 管理，不让他们把时间浪费在上面。我这边就讲这些，交还给 Vas。（Vasuman）谢谢 JD。那么这一切把我们带到哪儿了？我想再多讲一点 Varick 这家公司。
[18:40] Vasuman Moza
Uh because obviously we're not the cursor anthropic or opening eye of the world. Um, when we started this company, we fundamentally believed that the way the puck was moving, you had to get ahead of it and you had to start learning how a business runs and building with that in mind. I think a lot of Silicon Valley starts to go product product, but what we're building for cannot be solved for with just a product. We start off every single engagement with an audit where we actually send our forward to put engineers, strategists into a company to learn how it works from the inside out. That is what I believe is the biggest bottleneck. And after that we go into implementation. We build agents on top of our platform. And yes, you do still need all the bells and whistles and the fancy technology that allows us to, you know, really automate work uh in the future. But again, the bottleneck is the forward deployed motion, which is why we are so bullish here at Veric on our AI FDE. Um, and if you're interested in learning more about it or if you're interested in joining, uh, one of the fastest growing startups in Silicon Valley, working with some of the largest clients on the planet, uh, come find us after and we'll have a chat because we are aggressively hiring. Um, and if you are a company looking to understand how AI can really move the needle for you internally instead of just slapping a frontier model on top of everything and watching it break in production, come find me after as well. Thank you all so much for the time. I really appreciate it and uh, cheers.
显然我们不是 Cursor、Anthropic 或者 OpenAI 那种量级的公司。我们创立这家公司的时候有一个根本判断：要滑到冰球即将去的地方，你得提前卡位，得先去搞懂一门生意究竟是怎么运转的，然后带着这个认知去做东西。我觉得硅谷很多人张口闭口都是产品、产品，但我们要解决的问题，光靠一个产品是解不掉的。所以我们每一个项目都以一次「审计」开场：真的把 forward deployed engineer 和策略顾问派进客户公司，从内部把它到底怎么运转摸清楚。我认为这才是最大的瓶颈所在。摸清之后才进入实施阶段，在我们的平台上搭 agent。当然，那些花哨的技术细节你还是全都需要——正是它们让我们将来真的能把工作自动化掉。但我要再说一遍，瓶颈在于 forward deployed 这套打法本身，这也是为什么我们 Varick 特别看好自家的 AI FDE。如果你想多了解一些，或者有兴趣加入硅谷增长最快的创业公司之一、和全球最大的一批客户打交道，散场后来找我们聊聊，我们正在疯狂招人。如果你是一家公司，想搞清楚 AI 到底怎样才能真正给内部业务带来实质改变，而不是把一个前沿模型往所有东西上一糊、然后眼睁睁看着它在生产环境里崩掉，也欢迎散场后来找我。非常感谢大家的时间，真心感谢，干杯。
[20:03]
[applause]
（掌声）
[20:20]
[music]
（音乐）