FDE Is Not an Engineer. It Is the Organization Interface.
This is Part 7 of the Human in the Loop series.
The judgment premium needs an organizational vehicle
By the end of Part 6, only one hard question was left.
The cheaper AI gets, the cheaper actions get. The cheaper actions get, the more expensive judgment becomes.
Fine. But once judgment is expensive, where does judgment actually live?
Most CEOs answer reflexively: with me. I call the strategic direction. I set the business boundaries. I carry the final accountability. That sentence used to work in traditional organizations, because actions were slow, feedback was slow, and errors surfaced slowly. The CEO's judgment had time to travel down through weekly meetings, approvals, postmortems, budgets, and org appointments.
Once AI walks in, that transmission chain starts breaking.
Actions suddenly move too fast. One agent can rewrite hundreds of product entries overnight, work through thousands of customer leads, generate a product prototype, or reach straight into a production system. If the CEO's judgment still lives in his head, in the meeting room, or on a slide deck, it can no longer keep up with the action. He thinks his hands are still on the wheel. The wheel has already been disassembled into prompts, permissions, logs, approval flows, rollback mechanisms, and exception escalation rules.
So Part 7 is not asking whether the FDE title is trendy.
This is not a hiring-trend essay.
The real question is: how does the judgment premium turn into organizational capability.
My answer is that FDE is an organizational vehicle.
Not engineer-plus-sales. Not a customer-savvy programmer. Not a consultant wearing technical clothing. The key to FDE is not the title. The key is that it binds three things together that used to live apart: the real problem at the customer site, the engineering capability inside the vendor, and the accountability chain inside the organization.
In the old model, sales heard the problem from the customer, product managers wrote the spec, engineers waited for the spec doc, and customer success cleaned up after launch. Every link had a person. Every link could defend its own professionalism. But in the AI era, the most dangerous things sit between the links. The problem the customer cannot articulate needs someone to disassemble it on site. The flow that gets disassembled needs someone to write it into the system right away. The exception that surfaces after the system runs needs someone to carry "this is not a bug, this is an undefined organizational boundary" back to the product team and the CEO's desk.
That is the FDE's position.
It is not an enhanced version of one function. It is the interface that judgment uses when it moves between organizations.
If the keywords of Part 6 were judgment, accountability, and the final veto, the keyword of Part 7 is: who carries those three rights to the customer site. Without that vehicle, no matter how often a CEO says "AI must serve the business," it ends up as one of two ugly outcomes. Either the tech team builds tools behind closed doors while the business team holds tools they cannot use. Or the business head bypasses the org and hand-cranks AI directly, and only after something breaks does anyone realize there is no system, no customer, and no consequence owner ready to catch it.
The value of an FDE is not writing a few more lines of code for you.
The value of an FDE is making judgment runnable between the customer site, the production system, and the accountability chain.
Three companies admit the deployment bottleneck at the same time
In May 2026, several signals landed together. It is hard to call this a coincidence.
On May 4, FIS published an official announcement saying it is working with Anthropic to bring agentic AI into banking. The first stop is a Financial Crimes AI Agent. Two details in that announcement matter most. First, Anthropic's Applied AI team and forward-deployed engineers embed inside FIS to co-design this agent. Second, the agent is meant to compress anti-money-laundering alert and case investigation from days and hours down to minutes, while the investigator keeps the final decision.
The same announcement spells out the governance layer. Customer data stays inside FIS-controlled infrastructure. Every agent decision must be traceable and auditable. Notice what is not being claimed. It is not "the model got smarter, so banks can use it now." It is data, governance, audit, investigator control, knowledge transfer.
On May 11, OpenAI announced its Deployment Company. The official post says OpenAI agreed to acquire Tomoro, which gives the Deployment Company roughly 150 Forward Deployed Engineers and Deployment Specialists on day one. It launches with more than $4B in initial investment. OpenAI describes the FDE work directly: these people work alongside business leaders, operators, and frontline teams to identify where AI creates value, reshape organizational infrastructure and critical workflows, and turn the gains into durable systems. The post uses the phrase "production systems."
Translated into CEO language: the model is not the finish line. Deployment is the survival line.
Now Google Cloud. I will treat this only as a social and media signal, not as an official hard anchor. Public reporting and Thomas Kurian's LinkedIn posts indicate that Google Cloud is expanding its AI-focused go-to-market organization and continuing to invest in forward-deployed engineers, in order to pull customers closer to the product, the agent platform, the engineering team, and the research team.
Three signals, one conclusion.
The leading AI companies are not betting the next phase on "the model gets a little stronger."
They are betting on deployment.
Why. Because inside enterprises, the bottleneck has never been "can the model produce an answer." The bottleneck is whether that answer can enter a real workflow, connect to customer data, pass approvals, be audited, get rolled back on failure, and feed what was learned on site back into the product.
In the last year, too many CEOs were fooled by the demo. In the meeting room, an agent writes a plan, builds a table, generates a webpage, replies to a customer automatically. It looks like a small team. Then it touches production and the problem switches languages. Who grants its permissions. Who defines output quality. Who takes the customer complaint. Who approves cross-domain data. If it changes the wrong price, who can stop it. If it treats an experienced employee's judgment-call exception as a routine flow, who is accountable.
That is not a model-parameters problem.
That is a deployment problem. And it is an organization problem.
What OpenAI, Anthropic plus FIS, and Google Cloud are really admitting is this: once AI enters the deep end of the enterprise, selling models is not enough, and selling SaaS is not enough. Something in the middle has to exist — a person and a mechanism that turns capability into organizational results.
That is why FDE is being seen again.
What FDE is and what it is not
The three letters FDE are easy to misuse.
The moment a company hears FDE, it starts renaming sales engineers, solutions architects, and customer-success engineers. The business cards change. The work does not. Pre-sales still does demos. Architects still do PoCs. CS still picks up post-launch incidents. The CEO thinks he has caught up with the AI era. In reality, he has just slapped new labels on old roles.
To see a real FDE, go back to the Palantir prototype.
Palantir's own documentation says the platform and products are continuously developed through the Forward Deployed Engineering method. The core of that method is that the engineering team gets as close to the problem as possible, stays in lockstep with the core engineering team, synthesizes field feedback back into the platform, and continuously ships new capability. That implies at least three things.
First, the FDE has to be close to the problem.
Not close to the customer relationship. Not close to the procurement process. Close to the problem itself. Real problems inside enterprises rarely arrive as clean specs. They hide inside an experienced employee's judgment, inside a manual Excel file, inside a system interface no one has dared touch in years, inside an exception that says "this customer cannot be handled through the normal flow." An FDE who only listens to requirements in the conference room is indistinguishable from a regular consultant.
Second, the FDE has to write the problem into the system.
Writing a report is not enough. Drawing a blueprint is not enough. Doing a demo is not enough. Deployment in the AI era is not "tell the customer how to change." It is wiring the model, the data, the permissions, the workflow, the audit, and the rollback into a system that runs every day. OpenAI's Deployment Company announcement used the phrase "production systems" for a reason. The engineering substance of an FDE is not measured in lines of code. It is measured in whether judgment can be turned into something that runs, is observable, and can be held accountable.
Third, the FDE has to feed the field back into the product.
This is the largest gap between FDE and traditional consulting. Consulting can understand business. Sometimes consulting understands it deeply. But when the consulting project ends, the experience mostly stays inside the report and the consultant's head. If FDE is done right, the holes stepped on at the customer site turn into platform capability. The exception handling, permission boundary, and evaluation method that one customer pushed today becomes a default capability, a template, or a built-in defense line in the product tomorrow.
So I give FDE a deliberately narrow definition.
An FDE is the person who, on the customer site, writes business judgment into production systems, and feeds field knowledge back into the platform.
Drop any one of those clauses and it collapses.
On the customer site but not writing the production system: that is a consultant. Writing the production system but not feeding the platform: that is a contract engineer. Feeding the platform but never on the customer site: that is a product engineer. The hard part of FDE is that it stands between the customer and the vendor at the same time, speaks both business language and engineering language at the same time, and carries both delivery outcomes and product learning at the same time.
That is why it is not a role you can copy-paste.
The hard problem is not finding a few strong engineers willing to sit at the customer site. The hard problem is whether the company is willing to let that field experience change its own product, its workflows, and its organizational boundaries.
The physical embodiment of the organization protocol layer
An FDE sits in a strange place on the org chart.
The salary usually comes from the vendor, but every day they handle the customer's problem. Their output goes into the customer's workflow, but they are not the customer's employee. The customer's business owner watches their delivery without having formal management authority. The vendor's product team needs to ingest their feedback without being able to follow every single-customer request.
A traditional org chart cannot draw this line.
A traditional org chart only knows two relationships: solid lines and dotted lines. Solid lines mean employment and reporting. Dotted lines mean collaboration and support. FDE fits cleanly into neither. It is not a customer employee, so no solid line. It is not an ordinary collaborator either, because it touches systems, data, and critical workflows, and it changes business outcomes.
I prefer to call this place the organization protocol layer.
The organization protocol layer is not a legal contract. It is not a project charter. It is the set of operating protocols a company must define before allowing AI into production systems: which data can come in, which actions can be performed, which nodes require human confirmation, which exceptions must be escalated, which role is accountable for the outcome, which field findings must be fed back into the product, and which capabilities must remain on the customer side.
FDE is the physical embodiment of that protocol layer.
That sounds abstract until it lands on real ground.
OpenAI's announcement says FDEs work with business leaders, operators, and frontline teams to connect customer data, tools, controls, and business workflows. Every one of those words is more than engineering delivery. Data means boundaries. Tools mean embedding. Controls mean permissions. Business workflows mean accountability. The moment AI actually enters those places, it stops being a purely technical question.
If a company has no organization protocol layer, AI deployment swings to one of two extremes.
The first extreme is IT-custody mode. Everything queues up inside the tech department. The business only files requests. AI becomes another internal system. Safe, but slow. And it tends to flatten business judgment into bullet-point requirements.
The second extreme is business cowboy mode. The CEO or a business head grabs AI directly and bypasses the system, the permissions, and the quality boundaries. Short term, it feels great. Long term, it is dangerous. A working webpage does not mean a production system can carry it. A running agent does not mean someone catches the exceptions. Workflow automation does not mean customer trust will survive one bad mistake.
What FDE solves is not the tired "tech and business cannot communicate" problem.
What FDE solves is this. Once AI enters the organization, who translates business judgment into engineering constraints, translates engineering constraints into organizational accountability, and feeds field changes back into platform capability.
So FDE is not a dotted line.
FDE is a new interface layer.
If the CEO cannot see this interface, they will manage FDE the way they managed old roles. Park it under sales, and it becomes a senior pre-sales engineer. Park it under delivery, and it becomes an implementation engineer. Park it under product, and it becomes a requirements collector. Park it under engineering, and it becomes an on-site developer. Each parking decision sounds reasonable. Each one shaves off part of what FDE is supposed to do.
The cleaner way to manage FDE is to put it against a business problem, not inside a function.
It should be accountable for a specific scenario: is this workflow actually running, has business judgment been written into the system, are exceptions being caught, has the customer side gained capability they can inherit, has the vendor side received feedback it can reuse. The moment the evaluation language drifts back to "how many features shipped, how many customers visited, how many tickets closed," FDE gets dragged back into the old role.
So the organization protocol layer is not a nice phrase.
It is the management boundary that decides whether FDE is even possible.
The knowledge transfer clause is the watershed
In the FIS announcement, the line a CEO should stare at is not "investigations compressed from days to minutes."
That number is attractive. But what really decides whether this turns into enablement or into lock-in is a different sentence: Anthropic's team and forward-deployed engineers embed inside FIS, co-design the agent, and transfer knowledge so FIS can build and scale additional agents independently over time.
Read that quote once, then stop.
It says: knowledge has to be transferred. FIS has to be able to build and scale more agents on its own in the future.
If that sentence does not land in execution, FDE becomes a very gentle form of lock-in.
Why gentle. Because at first it looks like nothing but upside. The vendor sends strong engineers in. They map your flows. They wire into your systems. They run your data. They write your agent. Go-live is fast. Results are visible. The business team is happy. The CEO feels he bought the right thing.
A few months later, you notice the people who actually understand this stack are not inside your company. How to change the prompts, how to build the eval set, how to slice the permissions, how to handle exceptions, how to audit logs, how to extend to a new business scenario — every answer still has to wait for the vendor. You thought you bought AI capability. What you actually rented is a piece of external judgment chain.
This is where FDE gets most delicate.
It can be enablement. It can also be dependency.
The watershed is not the slogan. The watershed is engineering and contract aligning at the same time.
The contract has to spell out: which knowledge gets transferred, which configuration the customer can change, which runtime logs the customer can read, which evaluation method the customer can inherit, which new agents the customer can extend independently. Engineering has to back it up. If the critical logic all lives inside the vendor's private black box and the customer is only handed API access, then "knowledge transfer" is a pretty phrase.
The other detail in the FIS announcement matters too. Customer data stays inside FIS-controlled infrastructure, every agent decision is traceable and auditable. Data, traceable, auditable — those words together say this is not "plug Claude into a bank." It is the construction of an organization protocol a regulated industry can actually carry.
When a CEO looks at an FDE project, the three old questions are not enough: how much, how long, how many people saved.
Three new questions have to enter the room.
First. When the project ends, which capabilities stay inside our organization?
Second. Can we independently modify, extend, deprecate, and audit?
Third. After the vendor walks away, can the business still run and can the exceptions still be caught?
If the answers are vague, no matter how shiny the FDE project, all you did was outsource your organization's judgment.
The same skeleton, on a smaller scale
Before this section, I have to set a boundary.
I am not saying we built an OpenAI Deployment Company. I am not saying our internal growth system equals Palantir. Scale, customer type, capital structure, platform thickness — none of those are on the same order of magnitude. Forcing the comparison would just look hollow.
What I can say is this. At a smaller scale, we have already walked the same skeleton.
What is that skeleton.
There is a real business problem at the customer site, and the problem does not arrive as a clean spec. It is tangled with legacy systems, manual experience, business rhythm, customer relationships, ad-hoc exceptions, and accountability boundaries. You cannot write a deck from the outside and wait for the customer to digest it. You have to step into the flow, run with it, and learn which steps look primitive but cannot be removed, which actions look repetitive but carry judgment underneath, which people are not "inefficient labor" but risk buffers.
That is exactly what Part 5 said: AI replaces actions, not the organization.
Inside our internal growth system, the valuable thing is not "what some agent can do." The valuable thing is that we broke actions into the flow, kept human gates at critical nodes, and put the unsexy parts — logs, approvals, pauses, rollback, exception escalation — into the system.
A non-operator CEO looking at AI loves to look at generated output.
Someone who has actually run production checks five things first. When it breaks, who finds out. Who can stop it. Who can change it. Who is accountable. And whether the experience can stay.
Those five questions are where the internal growth system shares a skeleton with FDE.
A piece of customer-site business judgment cannot be reduced to just a prompt. Prompts are too light. They change fast and they drift fast. The judgment has to become configuration, rules, approval points, log fields, and review material. Only then will today's judgment not live inside one operator's head and not snap when the next person rotates in.
An agent workflow cannot be just "auto-complete." It needs explicit human gates: when does it run automatically, when does it enter the human queue, when does it pause, when does it escalate. Without those gates, the faster AI runs, the more the organization tightens up.
That is the real feel I have for FDE.
FDE is not about going to the customer site to show off. It is about turning field judgment into reusable organizational capability for the next round.
If every delivery depends on one strong person firefighting on site, FDE is just expensive labor. If every pit stepped on becomes a rule, a template, a component, a default defense line, and a handover document, FDE starts to become a platform flywheel.
For the person at the top, the difference is brutal.
Are you buying a person who can write code, or an interface that makes the organization smarter.
The first version dissolves when the project ends. The second makes the next deployment faster, steadier, and more like your own capability.
There is one very practical test. Can the customer side pick up the baton.
If every adjustment after launch has to go through the external team, that is not organizational capability. It is external service. If the customer's business owner can read the key rules, the operator can change configuration inside the safe range, the engineer can read logs and roll back, and the CEO can see in the dashboard which judgments AI amplified and which judgments still must be caught by humans, then this thing has started to become the customer's own capability.
This is also a reverse lesson the internal growth system gave me. You cannot treat "we are strong" as the outcome. The real outcome is: the stronger we get, the less the customer is tied to us.
The final form of FDE is not embedding deeper into the customer. It is training the customer's organization to catch more judgment on its own.
The three failure modes of FDE
Once the term FDE goes viral, failure goes viral with it.
Not because FDE is wrong. Because most companies will compress it into something narrower than it is.
Failure mode one: turning into consulting.
The team walks in, runs interviews, draws workflows, delivers a diagnosis, hands over a polished plan, and ships a few demos. The customer is excited. The CEO feels the direction is right. Then it touches the system — and you are back to the same IT queue, the same data silos, the same permission approvals, the same business exceptions. If FDE cannot write into the production system, it is just consulting delivery with an engineering vocabulary on top.
This failure is the most insidious, because the process looks deeply professional.
Every step has a document. Every conclusion sounds correct. But when the project ends, the customer organization has not gained a new runnable capability. It has gained a stack of "how we should AI-ize" material.
Failure mode two: turning into lock-in.
This kind of project often performs well in the short term. The vendor controls the model, the toolchain, the eval method, the runtime environment, and the core configuration. The customer only sees results. Go-live is fast. The dashboards look great. The business genuinely accelerates. But every critical judgment lives inside an external system. The customer wants to change a rule — go to the vendor. Extend a scenario — go to the vendor. Audit the details — go to the vendor.
That is not enablement. That is outsourced judgment.
CEOs misread this most often. Because what they see is "we finally have AI capability." But internally, no matching capability has grown. The dependency on long-tenured employees has simply been swapped for dependency on an external team. You used to fear the senior employee leaving. Now you fear the external team walking out.
Failure mode three: being absorbed by the product as low-level implementation.
The vendor says it values the field. But once the project pipeline grows and the platform is under load, the vendor turns FDE into template implementers. If the customer's problem happens to match the platform, things go well. If it does not match, the answer becomes "the customer's flow is immature, the data is non-standard, the requirements are unclear." Sharp field feedback never reaches the core product. It dies in a ticket queue.
At that point the FDE flywheel is broken.
Palantir's own FDE methodology insists on two things: stay close to the problem, and ship new capability in lockstep with the core engineering team. If the field cannot change the platform, only the first half of FDE survives. The body is still on the customer site, but the connection back to product learning has been cut.
Looked at together, all three failures are the same thing underneath.
FDE got stripped of its organization-interface property.
Becoming consulting: no engineering interface. Becoming lock-in: no knowledge-transfer interface. Becoming low-level implementation: no product-feedback interface.
So the CEO cannot only ask "do we have an FDE."
The right question is: which three ends does this FDE connect? Customer site, production system, platform feedback. Which one is missing.
Miss one, and FDE degrades from organizational prototype back into an old role with a new name.
A checklist for the person at the top
This essay closes not with a hiring suggestion but with a pre-meeting checklist for the person at the top.
If you are running an AI deployment meeting next week, do not start with "should we hire FDEs." That question is too narrow, and it is too easy for a vendor to steer.
Start with this. Which real production scenario are we letting AI enter.
Not "customer support productivity" or "sales productivity" or "R&D productivity." Those are decorative phrases. Get specific to a flow: which customer segment, which link, which input, which output, which class of exception, which business metric. If you cannot articulate the scenario, FDE will only be able to demo with you.
Second question. In this scenario, which judgments currently live inside individual people.
Not which actions can be automated. Which judgments cannot be lost. Why does that long-tenured employee know this customer needs special handling. Why does the operator pull back at a particular moment. Why does the salesperson stop chasing a lead the moment they see a certain signal. If those judgments are never disassembled, AI will only replace actions and never catch the business.
Third question. Which judgments must be written into the system, and which must stay with humans.
This is the three rights from Part 6 returning to the field. Where does the right to judge live. Where does the right to be accountable live. Where does the final veto live. The job of FDE is not to cancel those rights on your behalf. The job is to rewire them.
Fourth question. After the project ends, where does the capability stay.
Inside the vendor's head. Inside the customer's system. Inside the rule book. Inside the logs and the eval set. Or inside a pile of unmaintained demo code. The answer to that question decides whether you bought a one-time delivery or a stretch of organizational evolution.
Fifth question. Does the field feed back into the platform.
If every pit at the customer site becomes a one-off patch, FDE never forms a flywheel. Real deployment lets the next scenario start where the previous one finished sedimenting.
Walk through these five questions and FDE stops being a hiring problem.
It becomes an organization-design problem.
The CEO should not be led by "we need a few FDEs." What you actually need is an interface layer that can translate real customer-site judgment into an engineering system, translate the constraints of that engineering system into an accountability chain, and carry the new knowledge the chain produces back into the platform.
Some companies call that layer FDE. Some call it Deployment Engineering. Some companies do not need the title at all.
The name does not matter.
What matters is whether your judgment premium has a vehicle.
Without a vehicle, judgment stops at the CEO's mouth. Actions get amplified by AI. So do the consequences.
Part 8 keeps walking down this road. FDE is the vehicle. But how does a company decide where to cut first. That is where A/O/G — three cuts into one — comes in. AI does not start by changing roles, and it does not start by buying tools. It starts by judging: which actions should be automated, which organizational boundaries should be rewritten, and which governance rights must be reconfigured.
Read on
- Previous: The Judgment Premium
- Series hub: Human in the Loop
- Next: A/O/G: Three Cuts Into One