The main limit on enterprise AI is understanding how a specific business actually works, including undocumented handoffs and failure paths.
2
Forward deployed engineers map and redesign department workflows, then deploy agents on top of existing systems such as SAP, Salesforce, NetSuite, and Dynamics.
3
Varick's FDE agent turns engagement notes and company knowledge into workflow support, with autonomous workflow changes as the longer-term goal.
Summary
Vasuman Moza argues that AI has moved past the execution bottleneck. Models can now perform many knowledge-work tasks, but they still struggle to understand how an individual company operates. Varick Agents addresses this with forward deployed engineers who embed with one department, document real workflows, find what happens when processes fail, and redesign the work around AI. The agents run on top of systems the customer already uses, since enterprises often have little appetite for another migration. JD Pruitt then describes Varick's internal tooling for making those engineers more productive. An engagement agent reads notes and documents, a workflow agent checks the process being built, and a future autonomous assistant will handle small workflow changes from client emails. The system uses a company knowledge graph, model post-training, and custom tools for resolving entities and extracting relevant context. The talk is honest that autonomous workflow management is still under development.
Enterprise AI is limited by business context rather than task execution
Moza says models and tool harnesses have improved enough that AI can now solve many end-to-end tasks. The harder question is whether a system understands the business it is working inside. A healthcare sales department may operate very differently from a SaaS sales department. Employees often hold the needed context, but that context is difficult to extract and pass into a model call without the result breaking down. Varick's work therefore focuses on understanding and re-engineering how each customer operates, rather than treating a generic model as the whole solution.
Forward deployed engineers map the real workflow, including failure paths
Varick embeds forward deployed engineers with a customer and scopes the work to one department. In finance, they speak with process leads for accounts payable, accounts receivable, card reconciliation, banking, billing, and FP&A. They ask how work runs and what happens when it goes wrong. The documented golden path often misses the actual handoffs. Moza gives the example of Sarah in AP sending a problem to Chris, who then takes four days to reconcile a purchase order and an invoice. Those undocumented paths are specific to each company and often contain the real bottleneck.
Processes have to be redesigned around AI before automation can produce value
Moza says many AI pilots fail because companies put AI on top of broken processes. A forward deployed engineer changes the workflow enough to capture value while keeping it understandable to the people who use it. In his example, four of eight steps might run autonomously, three might require a person in the loop, and one might remain fully human because of risk or limited agent value. The engineer also has to consider adoption. Replacing a familiar 11-step process with a single step can make the system harder for operators to accept.
Varick deploys agents on existing enterprise systems instead of requiring migration
Varick builds agents on top of systems of record such as Salesforce, NetSuite, Dynamics, and SAP. Moza describes a customer that spent five million dollars and five years migrating to NetSuite, then says that customer would reject any proposal requiring another migration. Varick OS provides agent deployment, monitoring, governance, and evaluation while remaining above the customer's existing software. This approach fits enterprises that are deeply committed to their current systems and cannot easily replace them.
The FDE agent extends scarce people who combine technical and communication skills
Moza describes forward deployed engineers as people who need strong technical ability, AI fluency, communication skills, and the ability to draw information out of customers. That combination is difficult to hire. Varick's FDE agent is intended to help one engineer manage several client relationships instead of adding staff for every process. FDEs receive constant email and documentation, while different parts of a department pull them toward competing priorities. The internal agent handles some of that context management so the engineer can spend more time interviewing customers and understanding their processes.
The internal platform has engagement, workflow, and autonomous stages
JD Pruitt says FDEs were uploading about 150 pages of documentation to Claude and waiting for verbose, incorrect analysis. Varick responded with an FDE agent modeled as a specialized assistant. The engagement agent reads Granola notes, documentation, and slides, then answers questions about people and processes. The workflow agent sits inside Varick's platform beside Claude or Codex and points out missing edge cases or unclear process ownership. The planned autonomous assistant would read a client's request, update the workflow on the platform, and leave the FDE out of small changes.
A dependency graph gives the workflow agent a company-wide source of truth
Pruitt says Varick needs a representation of how a company functions. The implementation uses a dependency graph, although he says the underlying storage could be a graph database or Postgres. Enterprise workflows are often mostly linear but contain many cycles, and process owners want dependencies respected before later steps begin. The graph gives the agent a place to represent ownership, approvals, and relationships between processes. It also lets the workflow agent check whether the process being built matches the process the FDE intended to model.
Model training focuses on selecting context as well as writing the answer
Pruitt separates the problem into two parts. The model must produce a clear process flow from extracted context, and it must extract the right context from a large knowledge graph in the first place. Varick post-trains models on open-source models because frontier models can be too verbose and do not reliably distinguish important details from material that can be skipped. It also creates an RL environment with custom graph-traversal tools. These tools can check whether two names refer to the same person and find redundancy cycles or violations in the dependency structure.
"The bottleneck is how much can you process, re-engineer, how much can you process, understand?"02:27
Who should watch
You are building enterprise AI and need to work with existing systems rather than ask customers to migrate.
Your AI pilots work on isolated tasks, but the surrounding department process still depends on undocumented handoffs and manual recovery.
You are designing internal tools for consultants or forward deployed engineers who spend much of their time collecting, checking, and maintaining customer context.
