AI Engineer World's Fair 2026
AI tools for Forward Deployed Engineering
Read the talk
The next bottleneck in enterprise AI is understanding the work
Varick’s FDE agent turns client context into workflow assistance, combining a dependency graph, process-analysis training, and tools for retrieving the right business knowledge.
From a talk by Vasuman Moza
Before you start: Basic familiarity with AI agents, enterprise workflows, and SQL will help with the architecture and dependency example.
How deep can you go into a customer?
How can an engineering team understand each customer deeply enough to transform its operations without growing headcount at the same rate? That is the scaling problem behind Varick Agents, where Vasuman Moza describes highly bespoke enterprise deployments that require engineers to work inside the customer’s business. The scarce resource is not simply the ability to build another agent. It is the attention needed to understand what that agent should do.
Moza’s starting premise is that reasoning models and execution harnesses have shifted the constraint. Browser-use tools, APIs, and Model Context Protocol integrations give agents ways to perform work across software systems. He characterizes that execution as approaching perfection—a strong assessment of the technology, rather than a measured result presented here.
Business context remains stubbornly local. A healthcare sales department and a SaaS sales department may share a name while operating very differently. Their employees know the exceptions, dependencies, and informal decisions that make work happen, but extracting that knowledge is difficult. Packing it into a simple API or model call does not automatically produce a durable understanding of the business. The deployment problem is increasingly about specifying the work, not just executing it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Map the exceptions before redesigning the process
Moving from human-centered operations to AI-centered operations requires more than distributing Cursor, Claude Code, Codex, or Factory. The operating process itself has to change. A forward-deployed engineer, or FDE, first learns how the company runs, then works out how it could run differently with AI.
At Varick, several FDEs embed with a customer, but they narrow an enterprise with thousands of employees down to a department. In finance, that means interviewing the process leads for accounts payable (AP), accounts receivable (AR), card reconciliation, banking, billing, and financial planning and analysis (FP&A). The critical question is not only how the process normally works. It is what happens when it fails.
In Moza’s example, Sarah in AP hands a purchase-order/invoice reconciliation problem to Chris, adding four days of cycle time. A document describing the golden path and a couple of edge cases may never capture that handoff. Yet the handoff is part of the actual process an agent must handle. These company-specific exception paths explain why enterprise automation still needs so much human guidance: the missing information is often how people recover when the documented process stops working.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Redesign enough to create value, but preserve adoption
After mapping the work, the second responsibility is to re-engineer it. Adding AI to a broken process can preserve the original bottlenecks while introducing new failure modes. Moza invokes a 95% pilot-failure figure and a separate, unspecified 87% figure to describe disappointing enterprise outcomes. Those numbers should not be treated as interchangeable measures of production adoption or ROI: the likely MIT-related source, The GenAI Divide: State of AI in Business 2025, distinguishes reported returns from production adoption, and the second statistic’s source is not established.
The difficulty is visible even in coding. Asking an agent to refactor an entire codebase still calls for human input; handing comparable tools to nontechnical operators in finance, sales, marketing, procurement, or logistics does not give them an engineer’s ability to steer the system. The FDE has to redesign the process around both the agent’s capabilities and the operator’s ability to use it.
Too much change at once can undermine adoption. An operator accustomed to an eleven-step workflow may struggle when it becomes one step. But preserving every step also leaves value unrealized. In a separate eight-step example, Moza distributes responsibility this way:
| Responsibility | Steps | Role |
|---|---|---|
| Autonomous agent | 4 | Complete the work without intervention |
| Agent with human involvement | 3 | Keep a person in the loop |
| Human only | 1 | Retain work where risk is high or agent value is low |
The design decision is made at the level of individual steps. Automation is an allocation of responsibility, not a requirement to remove people from the whole process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Deploy on the systems the enterprise already uses
The third FDE responsibility is deployment on existing systems. Enterprises have invested heavily in NetSuite, Dynamics, SAP, and Salesforce. A separate AI product that requires abandoning those systems ignores the cost and organizational effort already committed to them. Moza reports that one client spent $5 million and five years migrating to NetSuite. Asking that customer to migrate again is unlikely to be a viable starting point.
Varick’s approach is to place agents above those systems of record. Its Varick OS platform provides agent creation, monitoring, and governance while retaining the customer’s existing enterprise software. The three responsibilities therefore form a sequence: map how people actually work, redesign the process around AI, and deploy the resulting agents where the business already operates.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Scale the context work around scarce FDEs
That combination of responsibilities makes FDEs difficult to hire. Moza describes 2026 onward as a period of growing demand for people who combine exceptional technical ability with communication skills and sensitivity to the customer. His top-percentile and orders-of-magnitude comparisons express the size of that ambition, not measured hiring criteria. In practice, a company often trains consultants in engineering or trains engineers in client communication; finding people already strong at both is harder.
The FDE agent is intended to extend the capacity of those people. One engineer or forward-deployed strategist should be able to maintain several client relationships while retaining the human support customers need. The workload includes continuous email, hundreds of pages of documentation, and process leads with conflicting priorities. AP depends on AR, reconciliation, and FP&A, but each lead has a different view of what matters most. Managing that shared context is what lets a small team provide intensive support without becoming a consultancy that scales only by adding people.
Moza contrasts the execution constraints of roughly 2024 with his current view that knowledge work is almost entirely solved. From that perspective, the remaining challenge is designing how work gets completed: understanding the customer, choosing what to automate, and implementing workflows robustly enough to change departmental performance. The broad claim about solved knowledge work is his premise for investing in FDE tooling.
Moza estimates 5–10% ROI for isolated prospecting or AP solutions and reports 25%, 50%, or 75% ROI for Varick’s department-wide transformations. He does not supply client-level results, measurement periods, or an ROI definition for those figures. The strategic distinction is scope: redesigning an entire department can address dependencies that a single-function product leaves untouched. He groups the intended benefits into revenue uplift, cost savings, and risk mitigation, then hands the technical walkthrough to head of engineering JD.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From document analysis to workflow assistance
The internal tooling project began with a contrast across the office. JD’s platform team was working comfortably with coding assistants, while the FDEs were exhausted by client communication. When he asked about their process, the answer was a repetitive document-analysis loop. JD describes FDEs uploading about 150 pages to Claude, waiting roughly two minutes, and receiving analysis they found verbose and incorrect. That account is an operating anecdote, not a controlled latency or accuracy test. The proposed remedy was an FDE-specific assistant, developed in three stages.
The first stage, the engagement agent, helps an FDE prepare and understand the work. It pulls in Granola notes, synthesizes documentation, and reads PowerPoint slides. Its questions are practical: who owns this process, or whether Sarah in an email and a differently spelled name in Slack refer to the same person. Answering those questions repeatedly is part of workflow construction, and waiting for a general-purpose assistant each time slows the engineer down.
The second stage, the workflow agent, embeds that engagement context in Varick’s platform. As the FDE constructs a workflow, the agent can flag a forgotten exception or suggest checking process ownership before choosing an email recipient. It works alongside Claude or Codex to check that the workflow being built reflects the intended business process. The context assistant is now present at the point where its answers affect implementation.
The third stage is autonomous maintenance, and JD explicitly says the team has not reached it yet. His example is a client asking by email to change the destination of a QC report. The intended sequence is:
- Receive the client’s change request.
- Query the stored understanding of the company.
- Change the workflow on Varick’s platform without involving the FDE.
The slide labels the third pillar Development Agent. The proposed autonomy would handle small maintenance requests while preserving FDE time for interviews and deeper process understanding; it is not a demonstrated live change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Represent the company as dependencies
All three stages need a shared representation of how the company functions. JD treats the storage engine as secondary: a graph database or Postgres can hold the information. Varick uses a dependency graph because process owners care about prerequisites. Person C should not have to deal with a task before A and B have approved it.
A small SQL example makes that prerequisite rule concrete. Here A has approved, B is still pending, and C therefore cannot proceed. The query tests for the absence of an unmet prerequisite rather than treating one approval as sufficient:
sql
WITH dependencies(task, prerequisite) AS (
VALUES ('C', 'A'), ('C', 'B')
), approvals(person, approved) AS (
VALUES ('A', true), ('B', false)
)
SELECT NOT EXISTS (
SELECT 1
FROM dependencies AS d
LEFT JOIN approvals AS a
ON a.person = d.prerequisite
WHERE d.task = 'C'
AND a.approved IS DISTINCT FROM true
) AS c_can_proceed;
The table names and approval states illustrate JD’s A-and-B-before-C rule; they are not Varick’s disclosed schema. JD also describes real enterprise workflows as largely linear but containing many cycles, so this local prerequisite check does not define the semantics of the entire company graph.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Train for the details the client actually needs
With a representation in place, the first model-training problem is output quality: given the right extracted context, can the model write a useful analysis? JD reports that Claude’s long analyses were too verbose for this work. The missing skill was the judgment he saw in consultants—recognizing which details the client cares about and which can be compressed or omitted.
Varick therefore post-trains models on open-source foundations to balance detail with clarity. JD names a Kimi model consistent with Kimi K2.6, while saying other models could also work. The target is a normalized process flow produced from extracted context. The training objective is not simply a shorter answer: it is an answer that retains the operationally significant details without burying them in unnecessary analysis.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Train the model to find the right context
Good writing from supplied context solves only half the problem. The company’s knowledge graph can be large, and reliably finding the relevant context is itself difficult. After post-training the model, Varick places it in a reinforcement-learning environment with custom tools for traversing that graph. The model must learn to obtain the information its analysis needs.
JD gives two examples of the tool-supported tasks:
- Resolve people. Determine whether two references identify the same individual. A company may contain many employees named Mike; matching names alone can select the wrong person and attach the wrong ownership context.
- Inspect dependencies. Identify redundant cycles or violations of a directed acyclic graph (DAG) constraint. This checks graph structure as well as retrieving records.
The earlier description allows operational cycles, while this part discusses DAG violations. The talk does not specify which relationships must be acyclic or how legitimate workflow loops are represented. That distinction would be necessary to implement the validator correctly.
The architecture separates two failure modes: retrieving the wrong context and producing poor analysis from the right context. Post-training addresses the usefulness of the normalized process flow; the RL environment addresses tool use and traversal. The architecture slide also names retrieval evaluations alongside reinforcement learning targeting traversal failures, but JD provides no reward specification or evaluation results. Autonomous management of small workflow changes remains the next stage under development.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The engagement still starts inside the business
The tooling does not remove the initial work of learning the customer. Returning to the engagement model, Moza describes a deliberate sequence: first send FDEs and strategists into the company for an audit, then implement agents on Varick’s platform. Product capabilities alone cannot reveal how a business actually runs; the audit supplies the understanding those capabilities need.
Technical infrastructure still matters, but the constraint motivating the FDE agent is the human effort around deployment. Moza closes by inviting engineers to join the team and enterprises to discuss internal transformation. The intended outcome is a company whose processes have been understood and redesigned before automation reaches production, with FDE assistance making that depth of engagement possible across more customers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Company overview of workflow audits, process redesign and agent deployment over existing enterprise systems.
July 2025 preliminary report on enterprise GenAI adoption, production deployment and financial impact, available through a mirrored PDF.
Moonshot AI's multimodal agentic model, with downloadable weights, deployment instructions and benchmark methodology.
Meeting assistant that transcribes conversations and turns meeting context into notes and follow-ups.
Read the complete timestamped transcript
- 0:00
[upbeat music] 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, and I'm sure you guys are mostly here for them, but [laughs] thanks for
- 0:25
sticking around for this talk. Uh, my name is Vas. 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.
- 0:34
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 [REDACTED:username], uh, and some of the internal tooling that we've created internally to allow us to scale that
- 0:51
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?
- 1:04
How can AI do that job for you?
- 1:07
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?"
- 1:24
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.
- 1:33
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.
- 1:52
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 [REDACTED:username] Agents.
- 2:11
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.
- 2:20
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.
- 2:32
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 [REDACTED:username]. So right now, operations are fundamentally centered around the human.
- 2:45
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.
- 2:53
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-- I'm sure you're experiencing here today, but also changing the operations and the processes themselves.
- 3:10
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 [REDACTED:username] and why forward deployed engineering is such a core part of what we do.
- 3:27
So a forward-deployed agent, what does that really mean? So why do we need FDEs? As stated previously, I'm not gonna, you know, go into this too much. I'm sure you've been hearing a lot of this today.
- 3:36
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 [REDACTED:username] is several forward deployed engineers will be embedded directly with a customer.
- 3:45
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, et cetera.
- 4:01
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.
- 4:18
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.
- 4:34
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 handholding that you see today in the enterprise.
- 4:49
Uh, 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.
- 5:07
There's a lot of, you know, semi-outdated but still very relevant statistics like the MIT review saying that ninety-five percent of generative AI pilots fail to reach production, or the other statistic which was eighty-seven percent, very similar thing, that most AI pilots don't produce measurable ROI or they don't ship to production, period.
- 5:27
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.
- 5:37
Um, you see th-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.
- 5:55
Now, if you extrapolate that to a business context, these are very non-technical operators in finance, sales, marketing, procurement, logistics, uh, et cetera. 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.
- 6:13
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.
- 6:24
For example, if they're used to an eleven-step workflow and you come in and change that with a one-step, they might be taken aback, the adoption rates might suffer, et cetera, as was alluded to in previous presentations.
- 6:34
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.
- 6:45
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.
- 7:02
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.
- 7:15
So fundamentally [REDACTED:username], we believe that the AI wave left a lot of enterprise behind. A lot of enterprise is married to their systems of record. Not everybody, but most of them are.
- 7:26
Uh, they've migrated to NetSuite, they've migrated to Dynamics, uh, they've 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.
- 7:39
One of the quotes from our clients said that they spent five million dollars and five 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 gonna tell you to get out.
- 7:54
They don't have any appetite for that. So what we believe in [REDACTED:username]-- believe in [REDACTED:username] is we'll build the agents on top of your systems of record, and the way that we do that is quite, uh, unique.
- 8:04
We have our own Varick OS platform that allows us to spin up agents, monitor them, uh, et cetera, with the full governance and ESL suite baked in. But at the same time, it lives on top of your systems of record.
- 8:14
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.
- 8:28
So why build the FDE agent in the first place? As mentioned previously, I think everyone is saying that twenty twenty-six and onwards is the year of the forward-deployed engineer, and to some extent, we believe that's completely correct.
- 8:40
There has never been more of a need to go deep into customers and understand their business c- 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 one percent, who are really able to understand
- 8:57
and speak AI, uh, ten thousand 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.
- 9:15
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.
- 9:26
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.
- 9:41
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 twenty-four/seven.
- 9:51
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 FP&A, and they each have their own version of what they think is the most important.
- 10:05
So being able to manage that context and being able to serve them all equally while also not hiring fifty people to do so is fundamentally very important. It's how we [REDACTED:username] 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 thi- we do
- 10:24
think is very valuable. Um, so in the past, in twenty twenty-four 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.
- 10:39
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.
- 10:48
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 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.
- 11:08
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 five to ten percent ROI for you as a sales function.
- 11:20
Same thing on finance. If you're just doing AP and no other part of your department, you might have a five, ten percent ROI. But [REDACTED:username], 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 twenty-five percent, fifty percent, seventy-five percent,
- 11:40
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.
- 11:53
So I want to invite my head of engineering, uh, JD Pruitt, to come up and, and share some more of the deep technical stuff on our FDE agent, uh, because I haven't written a line of production code in a while.
- 12:05
So here's JD.
- 12:06
Okay. Thanks, Paul.
- 12:09
And maybe if we can get his mic going.
- 12:15
Great. Thank you. Um, thanks, Vas. So, uh, this project to give tools to our FDEs, um, basically started with me. I lead the platform team, and we're over on one side of the office.
- 12:25
We're hanging out, we're chilling, we're having a great time. Uh, 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.
- 12:35
They've got clients emailing them twenty-four/seven. 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?
- 12:42
How are you actually engaging with these clients?" And like, "Well, we, you know, upload about a hundred and fifty pages of documentation to Claude, and then we prompt Claude, and then we wait, like, two minutes, and then we get analysis, and then it's verbose and incorrect, and it kind of sucks."
- 12:54
And I was like, "All right. We gotta fix this." So we have been working on an FDE agent, which is the Codex for our FDEs, basically. And there's three stages of it, um, the last of which is certainly still in, in development.
- 13:07
The first is what we call the engagement-- It, it-- The f- first function is the eng- is the engagement agent. And essentially, this is a better version of Claude built just for our FDEs.
- 13:18
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?
- 13:27
Uh, 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?"
- 13:35
'Cause 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.
- 13:47
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.
- 14:02
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...
- 14:17
Whoops. It lives, uh, it lives onside of our-- inside of our platform. It works next to Claude or Codex, whatever model you're using, um, and makes sure that the workflow that the FDE is constructing is actually, uh-- it correctly shadows the process that we want to engineer.
- 14:35
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 wanna change, you know, where my QC report goes to.
- 14:49
I wanna, you know, change it to a different email," et cetera. 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
- 15:07
work of sitting down, interviewing with the clients, really understanding what their process is, um, and not dealing with all of the small, little minutiae that anyone who has been an FDE can tell you, uh, takes up a lot of their time.
- 15:22
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.
- 15:32
If you were at the booths downstairs this morning, there was, you know, five companies trying to sell you a GraphDB, and you can just use Postgres, whatever it is.
- 15:40
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. Uh, most of these workflows inside of enterprise are remarkably linear.
- 15:49
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.
- 16:02
So a dependency graph is a very nice representation of this.
- 16:06
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 FDE, do we get a good, high-quality output?
- 16:20
And the answer is, with Claude, honestly, no, which is kind of surprising. But the really, um-- 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,
- 16:35
you know, I would say the, um... I only started believing in consultants once we started hiring them [REDACTED:username], and the reason is, they are 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.
- 16:50
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 Kimi K two six, but a lot of these would do diff-- a lot of these would do fine to really get that nice balance between details and, uh, clarity that
- 17:07
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
- 17:20
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.
- 17:33
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
- 17:50
with, and Claude gets very confused by this. Um, a second thing might be something like, um,
- 17:58
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.
- 18:11
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 FDE doesn't have to
- 18:31
waste their time on. I think that's all I've got. I'll hand it back over to Vas.
- 18:35
Thanks, JD. So where does that leave us? And I want to share a little more about Varick, uh, because obviously we're not the Cursor, Anthropic, or OpenAI of the world.
- 18:44
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.
- 18:57
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.
- 19:13
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.
- 19:27
But again, the bottleneck is the forward deployed motion, which is why we are so bullish here [REDACTED:username] 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
- 19:45
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.
- 20:00
Thank you all so much for the time. I really appreciate it and, uh, cheers. [audience applauding] [upbeat music]