A mid-sized logistics firm buys twenty Claude seats in March. By the second weekend their most curious operations analyst has built something that reads an incoming rate request, pulls the relevant contract terms and drafts a quote. It works. People gather round the screen.

It is August. The quotes are still written by hand.

I have watched a version of this play out enough times now to stop calling it bad luck. The demo was real. The analyst was good. Nothing broke. The thing simply never crossed the distance between working on a laptop and running in the business.

MIT’s State of AI in Business 2025 put a shape on that distance. Among firms that evaluated enterprise-grade AI systems, 60 percent looked, 20 percent reached a pilot, and 5 percent went live. The study’s own diagnosis is worth repeating because it names the failure exactly: the tools were generic, impressive in a demo, brittle in a workflow.

Getting through it takes three jobs that nobody in a 200-person company has been assigned. Someone has to decide which problem deserves the intelligence. Someone has to build it into the systems where the work actually happens. And someone has to own what happens when it gets something wrong.

The industry has already named the person who solves the second of those. The Forward Deployed Engineer sits inside the client’s business and builds the production system, hands on, until it works and keeps working. It is a good idea, and the market agrees: FDE job postings ran roughly 729 percent higher in April 2026 than a year earlier on Indeed’s index.

Then read the offers. Median base pay sits near $200,000. Mid-level total compensation runs around $385,000, and principal FDEs at the frontier labs clear seven figures. The firms deploying them describe small elite pods embedded against Fortune 100 problems for quarters at a time.

That model is sound, and it is not available to you. A 300-person manufacturer does not have a Fortune 100 problem, a Fortune 100 budget, or eighteen months to wait.

That is why we are putting three roles into the field: an AI Product Manager, an AI Forward Deployed Engineer and an AI Technology Leader. Not nine. Not one expensive hero. Three, sized to a mid-market problem and a mid-market clock.

Their job is mostly subtraction.

Walk into any company that has just discovered what Claude can do and you will find a list of thirty ideas. Perhaps three are worth building. The AI Product Manager’s first few weeks go into killing the other twenty-seven before anyone spends money on them.

The test they apply is narrower than most people expect. Is this a workflow where volume keeps rising and the cost of handling it rises in step? Is the decision repeatable while the inputs arrive messy? Is there a person today whose week is consumed by assembling information rather than judging it? Where all three are true, agents pay for themselves. Where they are not, you get a clever demo and a flat P&L.

They also own the number. What the workflow costs today, measured before anything is built, and what it costs after. This sounds administrative until the first budget review, when someone asks what the investment returned and the honest answer turns out to be that nobody wrote down the starting point.

Without this role: you build the wrong thing well, and you cannot prove it either way.

The difference between a demo and a production system is almost entirely a question of where the data comes from. A demo reads what you paste into it. Production reads what your systems already hold.

So the FDE’s work is unglamorous and decisive. Connectors into the ERP, the CRM, the document store, so the agent operates on live records rather than a copied-out sample. Skills that encode how your team handles an exception, not how a generic assistant would. Evaluations that tell you the accuracy on your own historical cases before the thing is allowed near a customer. And a harness around all of it: review gates, pre-commit checks, a human checkpoint wherever the cost of being wrong is higher than the cost of a pause.

Forward deployed, in our case, means deployed into the workflow, not into your building. Our people work from our offices; yours stay where they are. What we embed into is your ticket queue, your exception log and your channels, looking at real cases every day while we build. The proximity that counts is to the work. The postcode matters less than people assume, because the twentieth exception case surfaces in a queue somebody is watching, never in a corridor conversation nobody wrote down.

The time difference turns out to help. Agents run overnight, unconstrained by anyone’s working week. A team reviewing what they produced while your people slept fits this work better than a co-located squad keeping the same hours as the agents.

Without this role: the pilot works on last month’s spreadsheet and fails on this morning’s live queue.

This is the one most companies leave out, and it is the one that decides whether anything reaches production.

Somebody has to say what the agent may do on its own and what routes to a named person. What the audit trail records, and whether it would survive a customer dispute or a regulator’s question. Which model runs the workload, where it runs, and what it costs per transaction rather than per month. Whether the whole thing still behaves when the model underneath it is upgraded.

In practice the blocker is rarely technical. Your operation reaches the point where it could let an agent approve something, and then discovers that no one is willing to put their name against that approval. The capability arrives before the accountability does.

Without this role: the system works, and it still doesn’t ship.

This is how OptiSol builds now.

Our own engineering agents, an Analyst Agent, a Developer Agent and a QA Agent, run inside our Build and Modernize teams under exactly this structure. In one large modernization engagement, a single business analyst produced requirements documentation for around 100 legacy forms in a week by directing the Analyst Agent rather than writing each document by hand. On a separate reverse-engineering programme we are on track for 1,100 forms in ten weeks with a deliberately thin squad. My CTO has written about that transformation from the inside, and about the part that was genuinely hard, which was never the technology.

One of our customers measures brand coverage for media clients. Their team had used Claude to validate that coverage across multiple channels, and the idea was a good one. It had been a good one for four quarters. It was still not in production.

Our three worked it in that order. The product manager traced why it kept stalling, which had very little to do with the model. The forward deployed engineer built the pipelines the agent had been missing, so it ran against live channel feeds instead of a pulled sample. The technology leader settled the question everyone had been walking around: the associates running the engagement own the coverage agent’s output. Not the vendor, not the model, not a platform team somewhere. Named people, on the record.

It reached production in a single quarter. Coverage scaled from two brands to fifty, holding 95 percent accuracy.

Read those two numbers next to each other. Four quarters of a good idea going nowhere, then one quarter to production. The idea did not change. Neither did the model.

The failure mode we see most often in mid-sized companies isn’t caution. It’s breadth. Six use cases started, none finished, everyone busy.

One workflow. Baselined before anything is built, so the comparison is honest. In production inside ninety days, with a named human owner and a documented gate. Measured against the baseline in the open, including the parts that came in below expectation.

That is a small enough commitment that it does not need board approval, and a real enough one that it settles the argument. It also produces the thing that makes the second workflow easy: proof, in your own numbers, from your own operation.

The interesting constraint on AI in a mid-sized enterprise was never the model. Claude is as good in your hands as it is in a Fortune 100’s. What differs is everything around it, and that gap used to require nine roles you were never going to hire.

It now requires three.

So the question is not whether your team can build something impressive. They almost certainly can, and they may already have. The question is the one that decides whether it ever runs the business.

If you can answer that, you are ready to build. If you cannot, that is the first thing to fix, and it is the reason we send three people rather than one.