⚡ Execution stopped being the constraint 1:07
The talk opens with a before-and-after that most people in the room could verify from their own week. Two years ago, "has AI completed an end-to-end task for you?" would have drawn almost no hands. Today it draws all of them.
So the argument is that intelligence and tooling have stopped being the limiting factor. What remains is something less tractable:
The example given is precise: a sales department at a healthcare company operates nothing like a sales department at a SaaS company. The knowledge that distinguishes them lives in people's heads, and it does not survive being pasted into a prompt.
🗺️ What the documentation never says 3:27
The first job of a forward deployed engineer, as described here, is mapping how the work is actually done. Engineers embed with a single department — finance, say — and interview the process leads for AP, AR, card reconciliation, banking, billing and FP&A.
And the emphasis is not on the happy path:
Anyone who has tried to automate a real back-office process will recognise this immediately. The documented workflow is the workflow on a good day; the exceptions are where the labour is.
💀 Why pilots die 4:54
The second job is re-engineering the process around AI rather than bolting AI onto it. The diagnosis offered for the industry's poor hit rate is that "AI is being slapped on top of broken processes".
The most interesting part is the prescription, because it argues against maximum automation:
| Of an eight-step process | Handling |
|---|---|
| Four steps | Fully autonomous |
| Three steps | Human in the loop |
| One step | Human only — risk too high, or too little value in automating |
And the reasoning behind the restraint is about adoption, not capability. Replace an eleven-step workflow with a one-step one and the users may reject it outright — but change too little and there is no return to capture. The design target is the narrow band between those failures.
🏛️ The $5 million constraint 7:16
The third job is deployment, and here the constraint is stated as a direct customer quote: they spent $5 million and five years migrating to NetSuite.
So the architecture is agents deployed on top of existing systems of record — Salesforce, NetSuite, Dynamics, SAP — with governance and evals in the vendor's own platform layer, and no migration asked of the customer.
🧑💼 The hiring problem 8:28
Everyone declares 2026 the year of the forward deployed engineer. The talk's contribution is naming why that is harder than it sounds: the role needs someone in the technical top percentile and capable of sitting with a finance process lead and extracting undocumented knowledge in real time.
The usual paths — train a consultant on the technology, or train an engineer on the soft skills — both produce someone strong on one axis. The stated conclusion is that this combination does not scale by hiring, which is what motivates building an agent to amplify the engineers you already have.
The description of the job itself is vivid and rings true: clients emailing 24/7, hundreds of pages of documentation, and every process lead pulling in a different direction because AP depends on AR depends on reconciliation depends on FP&A, each convinced theirs is the priority.
🔧 Three stages of the FDE agent 12:18
The head of engineering takes over, and his account of the origin is refreshingly unpolished: the platform team was comfortable while the FDE team across the office was visibly exhausted. Asked about their process, the answer was uploading roughly 150 pages of documentation to Claude, waiting two minutes, and receiving analysis that was "verbose and incorrect".
| Stage | What it does | Status |
|---|---|---|
| 1. Engagement agent | Pulls in meeting notes, synthesises documentation, reads slides. Answers "who owns this process?" and "is this Sarah the same Sarah?" | Built |
| 2. Workflow agent | The same agent embedded in the platform, flagging missed edge cases while the engineer builds the workflow | Built |
| 3. Autonomous assistant | Receives client change requests by email, queries the model of the company, ships the workflow change without the engineer | Not yet |
Underneath everything is a single source of truth representing how the company works — implemented as a dependency graph. The observation offered about enterprise workflows is a good one: they are "remarkably linear, they just have a lot of cycles in them", and process owners want dependency ordering so that person C is not handed work before A and B have approved it.
A small moment of candour that says more about the state of the tooling market than the rest of the talk.
🎯 Where frontier models fail 16:06
This is the most valuable section, because a vendor talk had no obligation to include it.
Asked whether Claude produces good output given properly extracted context, the answer is a flat no — described as "kind of surprising". The failure is not reasoning. It is editorial judgement:
Their response is post-training on open models, with Kimi K2.6 named as a favourite — while noting that several would do fine. The goal is the balance between detail and clarity, not raw capability.
🕸️ Traversing the graph 17:16
The second half of the problem is retrieval: a large knowledge graph is only useful if the right context can be found reliably. Their approach is an RL environment with custom graph-traversal tools, including:
- Entity resolution — confirming person A and person B are the same person. "There are a lot of Mikes in every company we work with, and Claude gets very confused by this."
- Structural validation — identifying redundancy cycles and DAG violations in the graph
🧭 Reading this as a buyer 18:37
The closing is explicitly a pitch — the company is hiring, and looking for clients. That does not invalidate the content, but it should calibrate how the numbers are read.
What survives the discount is the diagnosis rather than the results:
- Undocumented exception handling is where process time actually goes
- Systems-of-record gravity is a real architectural constraint, not an excuse
- Partial automation with deliberate human steps is a design choice, not a failure
- Frontier models lack editorial judgement on long analysis — a capability gap, not a prompting problem
- Entity resolution fails silently and needs explicit tooling
Those are testable against your own organisation without buying anything.
🔍 Claims checked
| Claim | Result |
|---|---|
| MIT: 95% of generative AI pilots fail to reach production | Real — MIT NANDA, "The GenAI Divide: State of AI in Business 2025" |
| Kimi K2.6 as a post-training base | moonshotai/Kimi-K2.6 exists on Hugging Face |
| Varick Agents is a real company | varick.ai and varickagents.com both resolve |
| Enterprise workflows are linear with cycles | Consistent with how dependency-driven approval chains work in practice |
| Departmental ROI of 25–75% | No baseline, method, timeframe or client named — unverifiable |
| "Knowledge work is almost entirely solved" | Rhetorical. Contradicted three minutes later by his own engineer saying frontier models produce verbose, incorrect analysis |
Verified 28 July 2026. This is a conference talk by a vendor; treat outcome claims as marketing and operational detail as testimony.
💡 Key takeaways
- When capability becomes abundant, specification becomes scarce. Knowing what should happen — including the exceptions nobody documented — is the input no model can supply, because it is not in the training data.
- The documented process is the process on a good day. The real cycle time hides in undocumented handoffs — Sarah passes it to Chris, and reconciliation takes four days. Automation built from documentation models a workflow that does not exist.
- Deliberate partial automation beats maximum automation. Four steps autonomous, three human-in-the-loop, one human-only. Scoped by what the organisation will adopt, not by what is technically automatable.
- Adoption is the real constraint on process change. Replace an eleven-step workflow with one step and users reject it; change too little and there is no return. The design target is the narrow band between.
- Systems-of-record gravity is an architectural fact. $5 million and five years into NetSuite means migration is off the table. Tools that assume data can move somewhere convenient disqualify themselves before evaluation.
- The FDE role does not scale by hiring. It needs top-percentile technical skill and the ability to extract undocumented knowledge from a finance lead in real time. Consultants trained on tech, or engineers trained on soft skills, each cover one axis.
- Frontier models lack editorial judgement. Not a reasoning failure — a relevance-ranking one. Knowing which true details to discard for this reader is the consulting skill, and models optimised for completeness have the wrong bias.
- That admission is the most credible moment in the talk, because a vendor presentation had no incentive to include it — and it directly contradicts the CEO's claim that knowledge work is solved.
- Entity resolution fails silently. Three Mikes, a Slack handle and an ERP surname may be one person or four. Get it wrong and the process map is plausibly wrong everywhere downstream.
- You can just use Postgres. A dependency graph is the useful representation because enterprise workflows are linear with cycles; the storage engine is not the interesting decision.
- The specificity gap is the tell. $5 million, five years, four days, 150 pages — all concrete. "25%, 50%, 75% ROI" — no baseline, no method, no client. Read the operational detail as testimony and the outcome claims as marketing.
- The 95% statistic deserves its own caveat. Real, from MIT NANDA — but a preliminary, non-peer-reviewed report built on 52 interviews and 153 survey responses. Directional, not a measured failure rate, and it has become a vendor-deck fixture because it is convenient.
🔗 Resources & links
- AI tools for Forward Deployed Engineering — Vasuman Moza, Varick AgentsSource talk — AI Engineer, 20:22
- Varick AgentsThe company presenting
- moonshotai/Kimi-K2.6The open model named as their post-training base
- MIT report: 95% of generative AI pilots are failingThe source of the statistic — read the methodology before citing it