AI Engineer World's Fair 2026
AI tools for Forward Deployed Engineering
Vasuman Moza20:23
Read the talk
AI tools for Forward Deployed Engineering
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.
Transcript & slides
Loading transcript and slides…