Vasuman Moza of Varick Agents discusses AI tooling for forward deployed engineering: deploying agents on top of an enterprise's existing systems rather than requiring migration. Topics include mapping and automating a department's real workflows end to end, building a workflow spec from engagement notes and Slack threads with a single source of truth (e.g., Postgres), and post-training models to extract enterprise context and resolve entity redundancy before agents run autonomously. Includes a demo of tools for forward deployed engineers. # Channel Identity Observations — Varick Agents Talk ## Explicit Self-Description (Creator Claims) - **Role and company**: Speaker introduces himself as "Varick… CEO of Varick Agents" (transcript naming is inconsistent — also rendered "Verkada," "Verek," "Verica," likely transcription errors). - **Claimed scope**: > "We work with some of the largest companies on the planet transforming them from the inside out with AI and agents." - **Business model claim**: "Highly bespoke" client work requiring forward-deployed engineering (FDE); they deliver "department-wide transformations, holistically transforming the entire department at a time," claiming client ROI of "25% 50% 75%." - **Platform claim**: Proprietary "Varick OS platform that allows us to spin up agents, monitor them… with the full governance and eval suite baked in," built **on top of** existing systems of record (NetSuite, SAP, Salesforce, Dynamics) without requiring migration. - **Internal tooling claim**: A three-stage "FD agent" (engagement agent, workflow agent, planned autonomous assistant), including post-training open-source models ("Kimiko 26" per transcript) and an RL environment with custom knowledge-graph traversal tools. - **Self-positioning vs. competitors**: Contrasts with "Cursor and Factory and Anthropic" and "product product product" Silicon Valley companies; claims "we're not the Cursor and… OpenAI of the world." - **Growth/hiring claims**: > "One of the fastest-growing startups in Silicon Valley… we are aggressively hiring." - **Named personnel**: CEO Varick/Vass; "JD Pruitt" (transcript also renders "Petey"), head of engineering / platform team lead. ## Observable Presentation Evidence - **Talk format**: Conference-style presentation with slides, two speakers, an audience assumed to be technical (> "I know that most of the folks in the room are technical"), closing with applause and a hiring/sales call-to-action. - **Intended audience (dual)**: - **Business operators / enterprises**: > "If you are a company looking to understand how AI can really move the needle for you internally… come find me after." - **Engineering talent**: hiring pitch to FDE-type candidates (technical + high EQ). - **Demonstrated content scope**: AI agent tooling, forward-deployed engineering methodology, enterprise workflow re-engineering, knowledge-graph architecture, model post-training. - **Tone and style**: Casual, sales-forward, anecdote-driven (e.g., "Sarah in AP… sends it over to Chris"; client quote: "they spent $5,000,000 and 5 years migrating to NetSuite"); second speaker uses informal office anecdote about the platform team observing stressed FDEs. - **Cited external evidence**: References MIT review statistic ("95% of generative AI pilots fail to reach production") and a similar 87% figure — cited from memory, not sourced precisely. ## Claims vs. Demonstration Notes - ROI figures (25–75%), "largest companies on the planet," and "fastest-growing startups" are **creator claims** with no supporting evidence in the material. - The FDE agent architecture (dependency graph, post-training, RL tools) is **described**, not demonstrated; one stage is explicitly incomplete: > "the final stage, which we're not at yet." - Acknowledged limitation: CEO states > "I haven't written a line of production code in a while." ## Metadata Context - No curated metadata provided; identity context limited to title (positioning alongside AI tooling companies) and transcript. # Delivery Observation: "AI tools for Forward Deployed Engineering" ## Overview The talk is delivered by two speakers — the CEO ("Voss"/Vasuman) for the bulk of the talk, and a head of engineering ("JD"/"Petey") for a mid-talk technical segment. Delivery styles differ noticeably between the two. --- ## Speaker 1: CEO (Vasuman Moza) ### Tone - **Polished, promotional, conference-keynote register**: openings and closings are audience-facing and courteous. > "All right, first and foremost, thanks so much for being here." > "Thank you all so much for the time. I really appreciate it. And cheers." - **Self-deprecating handoff humor** before yielding the stage: > "I haven't written a line of production code in a while." ### Vocabulary & Recurring Phrases - **"Bottleneck" is the anchoring keyword**, used repeatedly to frame the talk: > "And it's titled the next bottleneck because I fundamentally believe the next bottleneck is how deep can you go into a customer..." > "clearly execution is no longer the core bottleneck" > "designing how work gets completed around AI is the next bottleneck" - **"Fundamentally" as a verbal habit** (high frequency): > "I fundamentally believe..." > "that's fundamentally not the reality" > "fundamentally at Verity, we believe that the AI wave left a lot of enterprise behind" > "fundamentally very important" - **"Slapping AI on top of" as a recurring pejorative formula**: > "slapping AI onto broken processes" > "slapping a frontier model on top of everything and watching it break in production" ### Teaching Habits & Rhetorical Devices - **Hypothetical show-of-hands questions to the audience**: > "How many of you have used AI to solve an end-to-end task?" - **Concrete anecdote/illustration with named personas** ("Sarah in AP," "Chris") to make abstract process points vivid. - **Numbered, signposted structure**: "The first is... The second is... And third and finally..." - **Quantified claims** used persuasively: "95% of generative AI pilots fail," "87%," "$5,000,000 and 5 years," "25% 50% 75%," ROI figures. - **Explicit calls to action at close** (recruiting and sales): > "come find us after and we'll have a chat because we are aggressively hiring." ### Verbal Fillers - Frequent **"um," "uh," "you know"** throughout — consistent with spontaneous conference delivery rather than scripted reading. ### Naming Inconsistency (observable, not inferred) The speaker says the company name in several variant forms: "Varick Agents," "Verkada agents," "Verity," "Verek," "Varick," "Verica." This is a repeated delivery-level inconsistency across the transcript. --- ## Speaker 2: Head of Engineering (JD/Petey) ### Tone - **Casual, narrative, anecdote-driven** — a marked contrast to the CEO: > "We're hanging out, we're chilling, having a great time. Codex, Claude, we're all hanging out. And then I look over at the FDE side of the room. They look stressed." - Includes a **direct playful address to the audience**: > "you can just use Postgres, whatever it is. Yes, I'm looking at you." ### Teaching Habits - **Explains via concrete mini-scenarios** rather than framework language: > "I got an email that mentioned Sarah spelled, you know, this way and I have a Slack message with a different way. Are these the same people?" - **Candid assessments of tools/models**, including frank criticism: > "the answer is, with Claude, honestly, no, which is kind of surprising." > "Claude gets very confused by this." - **Self-corrections and mid-sentence restarts**, consistent with unscripted technical explanation: > "It's their It's their assistant to build um to build the workflow." > "It lives uh it lives on side of our inside of our platform." ### Vocabulary - Uses informal technical slang ("verbose and incorrect and it kind of sucks," "Mikes in every company"), contrasting with the CEO's polished consulting vocabulary. --- ## Stable Patterns vs. Isolated Moments **Stable (repeatedly observable):** - CEO's use of "bottleneck," "fundamentally," and "you know" fillers - Two-speaker handoff structure with a closing return to Speaker 1 - Persuasive use of statistics and named-persona examples by the CEO - Speaker 2's anecdotal, informal technical register throughout his segment **Isolated / low-repetition (uncertain as patterns):** - The audience-directed joke ("Yes, I'm looking at you") — single occurrence - The self-deprecating handoff line — single occurrence - Speaker 2's admission of a live slide mishap ("Whoops.") — single occurrence, cannot establish a pattern **Uncertainty note:** This is a single talk; frequency claims (e.g., "fundamentally," "bottleneck") are based on this transcript alone and may not generalize to the speakers' other deliveries. No timestamps were available beyond transcript line markers, so none are cited. # Position Record: AI Tools for Forward Deployed Engineering ## Video - **Title:** AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents - **Speakers:** Varick/Vasuman Moza (CEO, Varick Agents; introduced as "Varick"/"Voss"/"Vass" in transcript) and JD Pruitt (head of engineering/platform team lead; also called "Petey" in transcript) --- ## Part 1: CEO's Framing (Vasuman Moza / "Voss") ### Core Thesis: "The Next Bottleneck" - **Claim:** AI has largely solved the *execution* of work; the remaining bottleneck is **how deeply you can understand a customer's business without scaling headcount exponentially**. - **Supporting reasoning:** A few years ago, few people had AI complete an end-to-end task; today nearly everyone has. Models and harnesses (browser tooling, APIs, "robust MCPs") enable execution "with near perfection." - **Counterpoint acknowledged:** Every business/consumer is different — e.g., a healthcare sales department operates completely differently from a SaaS sales department. ### Role of Forward Deployed Engineers (FDEs) Three responsibilities stated: 1. **Map how humans work today** - FDEs embed with a single department (e.g., finance), interviewing process leads across AP, AR, card reconciliation, banking, billing, FP&A. - Emphasis on **failure paths**, not just documented golden paths: e.g., "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 four days of cycle time." 2. **Re-engineer processes around AI** - **Claim:** "Slapping AI onto broken processes" is why industry-wide ROI is poor. - Cited statistics (characterized as "semi-outdated, but still very relevant"): MIT review — **95% of generative AI pilots fail to reach production**; a second statistic of **87%** of pilots producing no measurable ROI. - **Design constraint:** Changes must be not too different (adoption risk) but different enough to capture ROI. Example allocation: 4 of 8 steps fully autonomous, 3 human-in-the-loop, 1 fully human (risk too high or insufficiently unique for agent value). 3. **Deploy agents on top of existing systems** - **Claim:** "The AI wave left a lot of enterprise behind"; enterprises are "married to their systems of record" (NetSuite, Dynamics, SAP, Salesforce). - **Client quote:** A client said they "spent $5,000,000 and 5 years migrating to NetSuite" — so asking them to migrate off is a non-starter. - Varick's approach: build agents on the **Varick OS platform** with governance/eval baked in, living atop existing systems, requiring no migration. ### Why Build the AI FDE Agent - **Claim:** 2026+ is "the year of the forward deployed engineer" — agreed "to some extent." - **Tension acknowledged:** Top-tier FDEs need both top-1% technical skill and high EQ/communication — hard to find; typically you train consultants technically or engineers on soft skills. - **Purpose:** Let one FDE/strategist manage several client communications; clients email 24/7, send hundreds of pages of docs, and each sub-process (AP, AR, reconciliation, FP&A) "pulls you in a different direction." - Positions this as avoiding being a "traditional consultancy" while keeping its hand-held, human-centered approach. ### ROI Claims (stated as Varick results) - Point solutions deliver **5–10% ROI** (e.g., sales prospecting only; AP only). - Varick claims department-wide transformations yielding **25%, 50%, 75% ROI** across revenue uplift, cost savings, and risk mitigation. - Strong claim, tentatively hedged earlier in same talk: "I will go so far as to say that **knowledge work is almost entirely solved**." --- ## Part 2: Technical Deep Dive (JD Pruitt) ### Origin Story of the FD Agent - Anecdotal motivation: platform team observed FDEs "stressed," "sleep deprived," with clients emailing 24/7. - Prior workflow described by FDEs: upload ~150 pages of docs to Claude, prompt, wait ~2 minutes, receive analysis that is "verbose and incorrect." ### Three Stages of the FD Agent 1. **Engagement agent** — "a better version of Claude" for FDEs; ingests Granola notes, synthesizes docs, reads slides; answers entity-resolution questions (e.g., is "Sarah" in an email the same person as in Slack?). 2. **Workflow agent** — embedded inside Varick's platform; sits alongside the workflow builder, flagging missed edge cases and ownership questions; works next to Claude/Codex. 3. **Autonomous assistant (in development, explicitly not complete)** — would handle inbound client change requests (e.g., rerouting a QC report email), ship autonomous workflow changes, freeing FDEs for high-value interviews. ### Technical Approach - **Single source of truth:** a **dependency graph** representing company functioning (tooling choice flexible — graph DB or "just Postgres"). - Reasoning: enterprise workflows are "remarkably linear" with cycles; process owners want dependency-driven ordering. - **Two-part model training problem:** - **Output quality:** Claim — frontier models (Claude) produce verbose output lacking judgment about what detail matters; consultants are good at this, models are not. Solution: post-training on open-source models (named fan of "Kimi K2"; transcript renders as "Kimiko 26") for a balance of detail and clarity. - **Context extraction:** Traversal of the knowledge graph is "remarkably difficult" to do reliably. Solution: an **RL environment** with custom tools (e.g., person-A/person-B entity resolution — "there's a lot of Mikes in every company"; detecting redundancy cycles or DAG violations) to train graph traversal. - **Third component:** autonomous workflow-management agent — still being built toward. --- ## Part 3: Closing (Vasuman Moza) - **Position:** Silicon Valley defaults to "product product product," but what Varick builds "cannot be solved for with just a product." - Every engagement starts with an **audit** (FDEs learning the company inside-out), then implementation on the Varick platform. - Restates the bottleneck as the forward-deployed motion; pitches hiring and client outreach. --- ## Preserved Qualifications & Tensions - The **autonomous agent stage is explicitly incomplete** ("certainly still in development"; "we're not at yet"). - Speaker self-deprecates credibility on technical detail: "I haven't written a line of production code in a while." - The 95%/87% pilot-failure statistics are flagged as "semi-outdated, but still very relevant" — cited, not independently verified. - The "knowledge work is almost entirely solved" claim is stated as personal conviction ("I will go so far as to say"), a stronger claim than the surrounding argument strictly supports. - Speaker name inconsistencies in transcript (Varick/Verkada/Verica/Verek; Voss/Vass; JD/Petey) appear to be transcription artifacts of the same two speakers. # Speaker & Role Attribution — Video 01a15ca8-3516-770f-a0f4-94d190d3bc52 ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Varick ("Voss"/"Vass", spelled variously in transcript)** | **Creator / primary presenter** — CEO of Varick Agents | "my name is Varick. I'm the CEO of Varick Agents" (transcript spells the company inconsistently: Varick, Verkada, Verity, Verek, Verica — name spellings unverified) | | **JD Pruitt ("Petey")** | **Guest speaker** — Head of Engineering / platform team lead, introduced by the creator | "I want to invite my head of engineering JD Pruitt to come up" | | **Audience** | Unidentified attendees; no speaking lines (one throat-clear noted) | | No narrator or third-party interviewee present. No timestamps available in transcript. ## Referenced Third-Party Sources & Claims - **MIT Review** statistic: "95% of generative AI pilots fail to reach production" — attributed by creator, described as "semi-outdated, but still very relevant." - A second statistic, **"87%"** of AI pilots not producing measurable ROI — source not named. - **Client quote (unverified third party):** spent "$5,000,000 and 5 years migrating to NetSuite." - Named third-party AI tools/companies mentioned as context: **Cursor, Factory, Anthropic, Claude, Codex, Kimiko 26** (open-source base model), plus enterprise systems **NetSuite, Dynamics, SAP, Salesforce**. ## Promotional Segments (flagged) - Opening and closing remarks promote **Varick Agents** services, ROI claims (25–75%), and the **"Varick OS" platform**. - **Explicit hiring pitch:** "we are aggressively hiring… come find us after." - **Explicit sales pitch:** companies interested in AI transformation invited to speak with the presenter afterward. ## Availability & Limitations - No curated metadata supplied; no comment availability info. - Speaker name spellings inconsistent in transcript (Varick/Voss/Vass; JD Pruitt/Petey) — identities as stated only. - No timestamps in source; all quotes provenance-anchored to speaker turns only. \>\> All right, first and foremost, thanks so much for being here. Um it's uh been a great experience, you know, obviously chatting amongst uh other industry giants like Cursor and Factory and Anthropic. I'm sure you guys are mostly here for them, but thanks for sticking around for this talk. Uh my name is Varick. I'm the CEO of Varick 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 Varick, 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 head count 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 head count uh exponentially? How can AI do that job for you? So, as stated previously, AI is solving the execution of work. Um if you were to look back a couple of 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 end-to-end task?" The answer would be slim to none. But if I ask that same question to everyone today saying, "Has AI solved an end-to-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. Uh one sales department for a healthcare company, for example, operates completely differently than the sales department for a SaaS company. And this is something that we see with our work today at Verkada 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 Verkada. 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, Claude Code, Codex, like a factory, like any of the other brilliant AI tools that you for your 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 re-envisioning what it could look like tomorrow. And we believe that is our job at Verkada and why forward deployed engineering is such a core part of what we do. So, a forward deployed agent, what does that really mean? So, why do we need FDEs? As I 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 FDEs are responsible for a few different things. One is they map the way that humans are doing their work today. So, how we do that at Verkada is several forward deployed engineers will be embedded directly with the 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, FP&A, 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 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 four 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 amok and handle end-to-end processes without the hand-holding that you see today in the enterprise. Um so, this is the first 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 is 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 gold 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 forward-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 11-step workflow and you come in and change that with a one-step, they might be taken aback, 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. That'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 Verity, we believe that the AI wave left a lot of enterprise behind. A lot of enterprises are married to their systems of record. Not everybody, but most of them are. Uh they've migrated to NetSuite, they've migrated to Dynamics, uh they migrated to SAP and Salesforce. And when you pitch them AI solutions that live completely disparate from these systems, uh you're ignoring the reality of enterprise. One of the quotes from our clients said that they spent $5,000,000 and 5 years migrating to uh NetSuite. 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 NetSuite," they're going to tell you to get out. They don't have any appetite for that. So, what we believe in Varick believe in at Varick 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 Varick OS platform that allows us to spin up agents, monitor them, uh etc. with the full governance and eval suite 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 NetSuite 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 FDE 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's 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 soft skill side, but it's very hard to find people who are, you know, the best of both. Um so, the FDE 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 they will pull you in a different direction. AP relies on AR relies on reconciliation, relies on FP&A, 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 Verek avoid being, you know, a traditional consultancy while also offering that handheld hand-holding 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 gained the intelligence and the harnesses gained 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 ability to go deep with the customer, redesign the 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 Verek we deliver department-wide 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 JD Pruitt to come up and and share some more of the deep technical stuff on our FD agent because I haven't written a line of production code in a while. So here's JD. \>\> Okay. Thanks Voss. \>\> And maybe we can get his mic going. \>\> All right, thank you. Thanks Voss. So this project to give tools to our FDEs 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, having a great time. Codex, Claude, we're all hanging out. And then I look over at the FDE side of the room. They look stressed. They are sleep 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?" They're 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 Codex for our FDEs basically. And there is three stages of it. The last of which is certainly still in in development. The first is what we call the engagement. 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 is responsible for this process? I got an email that mentioned Sarah spelled, you know, this way and I have a, you know, a Slack message with a different way. Are these the same people? Cuz these are the questions that our FDEs are asking all day, every day, and they waste a ton of time just waiting on on Claude 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 FDEs go and they actually build the workflow, the FDE 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 a I can talk a little more of the details on the next slide, but Whoops. It lives uh it lives on side of our inside of our platform. It works next to Claude or Codex, whatever model you're using, um and make sure that the workflow that the FDE 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 FDEs where it's receiving emails from clients who say, "Actually, I want to 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 FDE never has to get involved, saving their time for the much more high-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 an FDE 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 Postgres, 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. Um 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. 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 high-quality output? And the answer is, with Claude, honestly, no, which is kind of surprising. But the really um and 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 um I only started believing in consultants once we started hiring them at Verek. 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 Kimiko 26, but a lot of these would do 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 a 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 person because a lot of you know, there's a lot of Mikes 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 to do the kind of uh workflow management on the small things that the FDA doesn't have to waste their time on. I think that's all I've got. I'll hand it back over to Vass. \>\> Thanks, Petey. So, where does that leave us? And I want to share a little bit more about Verica uh because obviously we're not the cursor and throttle of the open 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 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 deployed 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 in the future. But, again, the bottleneck is the forward deployed motion, which is why we are so bullish here at Verica on our AIFDE. And if you're interested in learning more about it, or if you're interested in joining one of the fastest-growing startups in Silicon Valley working with some of the largest clients on the planet, come find us after and we'll have a chat because we are aggressively hiring. 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 cheers. \>\> \[applause\]