Someone Has to Decide Where Intelligence Belongs

Not which model to buy. Where intelligence goes in the workflow—and where it must not. Then someone owns the software when it runs.

Scott Farrell · LeverageAI · ~12 min read

Every serious company can buy the same class of model. That is not a slogan. Talk to fifty enterprises and you will hear the same stack names. Intelligence on tap is no longer a moat.

So where does advantage go?

Into deployment. The edge is no longer who has intelligence. It is where, how, and why a specific company uses it—against workflows that are messy, political, full of exceptions, and only half-written down.

That requires a person who can do something models will not do for free: decide where intelligence belongs, decide where it does not, and then build software that puts it there and carries the load when production misbehaves.

Someone has to decide where intelligence belongs. That person is what the market is trying to name when it says forward-deployed engineer.

The title is everywhere. Shared understanding is not. This piece is a role explainer with a hard boundary: if you cannot produce the map, the evidence, and the ownership, you do not yet have the job—you have a costume.

What the job actually is

Strip the recruiting gloss. The useful definition is operational.

A forward-deployed engineer sits close enough to the work to learn how it is performed, not only how it is described. They exercise commercial and technical judgment in one head: which steps need model judgment, which should stay deterministic software, which must stay human. Then they ship something that runs inside the systems the business already owns—and when it breaks, it is their problem.

That span is the point. Most organisations split it. Discovery lives in one function. Architecture in another. Build in a third. Change management arrives late with a deck. Each handoff loses exceptions. The FDE is the attempt to keep one continuous line of responsibility from swamp to production.

Palantir is the public origin case most people reach for: product engineers optimise for one capability across many customers; forward-deployed engineers (their Deltas) optimise for one customer across many capabilities, embedded to achieve technical outcomes in that environment.^1,2 The term was popularised there; the market is now generalising the motion.

Look at how serious labs write the role when they are not selling theatre. OpenAI’s live FDE posting is blunt: own discovery, technical scoping, system design, build, and production rollout; measure success through production adoption, measurable workflow impact, and eval-driven feedback.³ Anthropic’s careers board runs a full Applied AI track—architects and engineers whose work runs from customer discovery through evaluation and deployment—and their hiring language treats forward-deployed engineering as a recognised peer profile for that work.^4,5 Applied AI Engineers, in their own description, sit with customers, learn the workflow in depth, and build the integrations and agents that make the model do real work—not a chatbot bolted on at the edge.⁵

None of that proves any particular hire is good. It does show the job the market is actually trying to buy: discovery to production, with evals in the middle, ownership at the end.

What it is not

Title inflation is faster than definition. Draw the boundary before the method.

Earlier LeverageAI writing on the AI Bridge owns bidirectional translation: business goals into measurable pilots, AI constraints back to executives, plus governance and measurement.⁶ Keep that. An FDE may need every bit of it. Translation alone is still not the full role. The hard boundary is build-and-own. When the system is live in their tools, your name is on the behaviour.

The swamp behind “an email arrives”

Most failed pilots begin with a clean sentence that is not true.

“An email arrives.”

On a process map that looks like a trigger. In the building it is a swamp. Forty-plus senders. No two formats alike. Payload in the body, a PDF, a screenshot, a spreadsheet, or a forward six replies deep. Half of it is exception language: same as last time, ignore the second attachment, Sarah already signed off. Routing logic lives in one person’s head because there is no subject line you can trust and no SOP that matches Friday afternoon.

If you only interview for an hour, you will build for the sentence. If you sit beside the person who actually clears the queue, you learn the thirty unwritten rules that make the job possible. That discovery is the job. The documented process is rarely the performed process.

This is why remote slideware fails so often. Not because information cannot travel. Because exceptions do not volunteer themselves in a scheduled workshop.

The judgment models cannot buy for you

After reality is mapped, do the thing demos skip: decide, step by step, what kind of cognition each step needs.

A ten-step workflow might put an LLM on three judgment steps, deterministic software on six, and a human on the one consequential decision that carries ambiguity, accountability, or irreversible consequences. That split is the product.

There was a brief fashion for token-maxing: give everything to the model and let it figure it out. It still feels modern. It is also how you burn inference budget without moving a business metric. Placement judgment is the scarce skill—knowing where intelligence belongs, and having the spine to keep it out of places where it only produces elegant failure.

The operating map is the primary artefact

If you need one object that separates real FDE work from costume work, demand an operating map.

Not a brainstorm wall. The audit’s output. A single inspectable object that usually includes:

• Current-state workflow — how the work actually happens today, tools, handoffs, exceptions
• Future-state workflow — the same work rebuilt with intelligence in the right places
• Selected use case — one workflow chosen for value, not twenty parallel pilots
• Boundaries — what the system may and may not do
• Human approvals — which actions always require a person
• Quantified value — hours, cost, error rates, cycle time—stated as claims you can later measure

Without that map, teams skip to agents and discover late that they automated the wrong steps, ignored the exceptions, or built a parallel system nobody will adopt. With it, every later argument—models, budgets, risk, rollout—has shared ground truth.

It is also the opposite of PowerPoint’s old promise: soft documents pretending to be structured thinking. The map is thinking you can hold still long enough to disagree with.

The loop: Audit → Evals → Deploy

The method is the role made observable. Three stages. Each earns the next.

1. Audit — find the workflow worth rebuilding

Collect context from the systems and people who live the work: emails, spreadsheets, SOPs, approvals, exception paths, tribal rules. Trace bottlenecks, repetitive work, judgment points, required systems, failure modes, automation that is actually worth doing. Produce the operating map. Decide what should be automated and what should not.

Audit is not bureaucracy. It is anti-fiction. It stops you building against a process that only exists in a policy PDF.

2. Evals — turn non-determinism into evidence

Once models enter, “it looked good in the demo” is not a control system. Evals create an evidence surface: graded cases, pass rates, failure categories, operating rules.

Cover more than the happy path:

• the normal case
• the edge case
• incomplete information
• an ambiguous request
• a high-risk action

For each: right data? required steps? match to expert judgment? safe enough to act?

Then write a report a sceptical operator can read. Example shape: 41 of 50 graded runs passed. Of the nine failures, five missing data, four wrong record. Operating rules follow the evidence: below a confidence threshold, escalate; high-risk actions always reach a person; pilot mode keeps human review on every action until failure modes shrink.

That is production-ready thinking applied to non-determinism: evaluation as infrastructure, not a late QA checkbox.⁷ OpenAI’s FDE success metrics explicitly include eval-driven feedback that can change product and model roadmaps—field evidence feeding the platform, not only the other way around.³ Anthropic’s Applied AI language likewise puts evaluation frameworks next to architecture and deployment, not after the applause.⁴

Validate the system against its own receipts. Pretty outputs without failure categories are still theatre.

3. Deploy — make it work inside the business

Deployment is where software begins carrying operational responsibility. Three principles keep showing up when the work is real:

1. Integrate with what already exists. Build over the ERP, CRM, identity, and data the company already paid for. Forcing a rip-and-replace so your agent is happy is usually a sales motion dressed as architecture.
2. Test in a controlled environment. Sandbox first. Inspect failures where blast radius is small.
3. Increase autonomy gradually. Shadow, assist, limited writes, then broader authority—only after the eval surface and live review go quiet on the failure classes that matter.

Adoption is not a training deck at the end. It is part of the engineering job. People trust systems that are integrated, observable, and reversible more than systems that are merely impressive.

One end-to-end picture

Return to the email swamp. The operating map picks invoice intake as the first use case.

Audit shows forty senders, inconsistent formats, exception phrases, and a human who already knows which messages are duplicates. Value is cycle time and error rate on ERP posts—not “AI adoption.”

Placement judgment puts deterministic checks on required fields and duplicates, an agent on extraction and draft PO matching, and a human on final approval before anything posts.

Evals grade normal invoices, truncated PDFs, ambiguous vendor names, and high-value payments. The first report is imperfect on purpose. It shows where the system fails and which failures must escalate.

Deploy wires into the existing ERP and identity stack, starts with human approval on every post, then relaxes autonomy only for failure classes that have gone quiet.

That is the engagement in miniature. Notice what is missing at the start: a debate about which frontier model is “best” in the abstract. Model choice matters later, as a measured trade-off on the eval surface. It is not the opening move.

Context, not the spine: why deployment keeps failing

If you need external context for why this role is being capitalised, keep the claims tight to what each study actually measured.

MIT Project NANDA’s July 2025 report The GenAI Divide: State of AI in Business 2025 (multi-method: 300+ publicly disclosed initiatives, interviews with 52 organisations, survey of 153 senior leaders) finds that despite large enterprise GenAI investment, 95% of organisations in their analysis are getting zero return, with only about 5% of integrated AI pilots extracting millions in value and the rest stuck with no measurable P&L impact. They attribute the divide more to approach and learning than to model quality or regulation; separately, they report only about 5% of evaluated custom/vendor enterprise tools reaching production.⁸

S&P Global Market Intelligence’s own research summary states that 46% of projects are scrapped between proof of concept and broad adoption.⁹

RAND’s official report on AI project failure, based on interviews with 65 experienced practitioners, notes that by some estimates more than 80% of AI projects fail—twice the failure rate of IT projects that do not involve AI—and traces leading causes to misframed problems, data foundations, tech-chasing, infrastructure, and applying AI where it still cannot work. Scope note: the authors exclude pure prompt-engineering-over-pretrained-LLMs from their primary ML project framing.¹⁰

Read those carefully. They are not proof that “AI doesn’t work.” They are evidence that integration, problem framing, and production ownership are where value dies. That is exactly the layer the FDE is supposed to own.

How to recognise the real thing

If you are hiring, buying, or partnering, you do not need folklore. You need artefacts and behaviour.

If you are a practitioner, use the same list as a self-audit. If your work stops at recommendations, you are consulting. If it stops at demos, you are pre-sales. If it includes discovery depth, placement judgment, evidence, and production ownership, you are doing the job the title is supposed to mean.

What this is not asking you to believe

Not that every company needs a lab-sized FDE army. The function can be one person or a small pod. The job-to-be-done stays the same.

Not that consultants are useless or platform engineers secondary. One capability for many customers is still how great products scale. The FDE is the complementary motion: many capabilities for one customer’s ground truth.¹

Not a thirty-day tutorial for building agents. Tools change monthly. The scarce layer changes more slowly: judgment about where intelligence belongs, and the willingness to own the system after the applause.

The point

Intelligence is becoming abundant. Trustworthy placement of that intelligence is not.

The forward-deployed engineer exists because organisations need someone who can walk into a swamp called “an email arrives,” decide which steps deserve a model, which deserve if/else, and which deserve a human—then prove behaviour with evals and carry operational responsibility inside the systems the business already runs.

It is not the quickness. It is the accuracy of the map, the honesty of the failure report, and the ownership when production is real.

Audit. Evals. Deploy. Each stage earns the next.

If your “FDE” cannot produce the map, the evidence, and the ownership, you do not have a forward-deployed engineer. You have a new label on an old gap.