The Forward Deployed Engineer, Chapter 2: The Last-Mile Problem in Enterprise AI

This is Part 2 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we defined the role. This one is about the problem the role exists to solve — the “last mile” in enterprise AI, where most deployments stall.

The phrase comes from telecommunications. Engineers used it to describe the short, expensive, frustrating stretch between the trunk network and the actual building — the few hundred feet of copper that determined whether the customer ever got service at all. The trunk was elegant and well-funded. The last mile was muddy, idiosyncratic, and always more work than anyone planned for. It is the same shape that recurs in enterprise software, and it is, almost without exception, where the value of an AI deployment is decided. SaaS solved the trunk. AI has to walk the mile.

To see why that’s harder than it sounds, it’s worth being precise about what SaaS actually solved. The SaaS bargain was standardization in exchange for distribution — the vendor would offer a product that did 80% of what any given customer needed, and the customer would reshape their workflows to fit the remaining 20%. That bargain worked for a long time, and it is the reason almost every business application in the enterprise today is a SaaS product. But the bargain breaks the moment the model has to act inside the customer’s operations rather than alongside them. Somebody has to do the reshaping, and the vendor can no longer hand that work off to the buyer.

From Task-Level AI to AI-Native Operations

The first wave of enterprise AI, roughly 2017 through 2022, was task augmentation. A model lived inside an existing tool and made it slightly better. The 2023–2026 wave is something different. AI sits at the center of the workflow, not at the edge, and the operating model itself is what’s being deployed. That is the source of the last-mile problem. When the workflow is the product, the workflow has to be redesigned for each customer — not configured, not parameterized, redesigned — and that is engineering work, not sales work or success work.

Every enterprise AI deployment runs into four kinds of friction at that last mile, and they show up in roughly the same order. There is data friction, because the customer’s inputs don’t look like the training set, and never quite will. There is workflow friction, because the model’s output doesn’t fit the next step in the operator’s day. There is trust friction, because the user doesn’t believe the model yet and won’t until it earns that belief one transaction at a time. And there is governance friction, because the deployment has to be audited, explained, and contained inside the customer’s existing risk regime. Each friction has its own remedies. None of them is solved by a better model.

Workflow Redesign Is the Product

In 2023 I advised a mid-market financial-services firm — a regional asset manager with about three hundred employees — through an LLM deployment that, on paper, should have been straightforward. The model worked. The pilot was clean. And then the engagement spent the next eight months on integration work that nobody had quoted, against systems nobody had documented, with stakeholders nobody had mapped. The deployment eventually succeeded, but almost none of the value was created inside the model. Most of it was created in the workflow redesign that surrounded it — in the new escalation paths, the new approval steps, the new exception handling, the new dashboards that gave the human reviewer enough context to trust what the model had done.

That experience is the case study, but the lesson is broader. The single most important reframe a founder selling enterprise AI can make is that the workflow redesign is the product, and the model is a component. The companies that internalize that frame invest in the operating model that produces the redesign. The ones that don’t keep trying to ship faster models into customers whose problem was never model quality in the first place. Tomorrow, we’ll look at where the function responsible for all of this should live in the org chart.