Or: why the most consequential job in AI right now isn't building the models — it's deploying them.
For two decades, "deploying enterprise software" has meant a specific dance. A vendor ships a versioned product. The customer's IT team installs it, configures it, integrates it with three other systems, and rolls it out behind a slide deck full of phrases like change management and user adoption. The work was tedious but legible. Most of it lived inside a SOW. Most of it could be templated.
Agents break the template.
When an enterprise buys an AI agent today — to triage tickets, write proposals, route insurance claims, run procurement, draft engineering specs, manage commercial leases, fill out RFP responses — they are not buying versioned software. They are buying output. They are buying the equivalent of a knowledge worker who shows up on Monday and is expected to be productive by Friday. And what they want from the vendor is not "installation support." It is the entire arc of a professional services engagement: understand my business, calibrate to my data, evaluate against my edge cases, get to a working end state, and keep tuning until I trust the work.
The job that closes the gap between the model and the messy enterprise is the Forward Deployed Engineer. And it is about to become one of the most valuable seats in tech.
The shift, stated plainly
Traditional software is a substrate. It runs underneath the work. The customer's people do the work; the software just supports it — accounting software, the CRM, the ticketing system. Updates are easy because the substrate is conceptually similar to last year's substrate. Same shape. Better version.
Agents are not a substrate. They are the work itself. When an agent processes 80% of inbound RFPs, the agent is no longer "software the team uses." It is a teammate the team depends on. And teammates can't be deployed by updating a config file.
This single distinction reshapes everything around the sale: the buyer's expectation of vendor involvement, the velocity of value, the locus of risk, even the meaning of "go-live." The traditional enterprise IT model — buy, install, train, support — collapses into something far closer to professional services. The vendor's job is no longer to deliver an artifact. It is to deliver a working business outcome.
That is a different commitment. And it requires a different person to hold it.
Why most teams underestimate this
There is a persistent fantasy in agent-land that an excellent base model plus a well-designed product surface is enough. Just give the customer the keys. The model is smart; the workflow will figure itself out.
That fantasy survives a demo. It does not survive a deployment.
The customer's tax processing happens in a particular sequence with particular exception cases that are documented nowhere except in the head of a person who has been doing the job for nine years. The procurement workflow runs through three systems and two spreadsheets, and three of the categories are mislabelled. The data is gated behind a permission model designed in 2014 for a use case that no longer exists. The domain experts are skeptical of AI, and they have organizational power to slow the rollout to a crawl if they aren't brought into the loop early.
None of this shows up in the product spec. All of it shows up in the deployment.
The companies winning right now are the ones that have internalised this: software deployment was a logistics problem; agent deployment is a business problem that happens to involve code.
The six disciplines collapsed into one role
A working agent deployment is the intersection of six disciplines, each of which used to be a distinct role in enterprise IT and is now smashed together into a single seat.
1. Model selection and routing. Which model — or set of models — actually performs on this workflow? Frontier vs cheaper variants. Reasoning vs latency tradeoffs. When does Sonnet matter and when can Haiku ship the call? The FDE runs the bake-offs. They know the cost-to-quality curve cold and can defend the choice in a CFO meeting.
2. Eval design. Off-the-shelf benchmarks are decorative. What the customer actually needs is a custom eval set built from their real edge cases — the gnarly invoices, the ambiguous emails, the clauses where humans themselves disagree. Building that eval set is a craft, and it is the single most valuable artifact the FDE leaves behind, because it is the only thing that lets the customer ship changes safely after the vendor walks away.
3. Data engineering. The agent needs context, and context lives in places the customer probably hasn't catalogued. PDFs scanned in 2009. Salesforce custom fields. SharePoint trees three layers deep. A Notion. A Slack. An ERP last touched by a contractor in 2018. The FDE gets the data into a place the agent can use, with permissions and provenance intact.
4. Workflow redesign. A workflow built for humans is almost never the right workflow for a hybrid agent-plus-human system. Where does the human stay in the loop? Where does the agent escalate? What is the new exception path? This is industrial engineering, applied to knowledge work. The FDE redraws the process map — and the org chart sometimes follows.
5. Change management. The skeptical domain expert is the most important person in the building. The FDE earns their trust — by listening, by showing edge cases the agent gets right, by giving them the controls they need to feel safe. Most agent rollouts die in change management, not in engineering. The vendors who pretend otherwise are setting their own pilots on fire.
6. Continuous tuning. Agents are not "set and forget." Prompts drift, models update, data shifts, customer needs evolve. The FDE builds the feedback loop: capture failures, route them back into the eval set, ship improvements, repeat. They are the operating system of the deployment, not the installer.
No single role in the traditional enterprise has ever had to combine these. Application engineers don't do change management. ML engineers don't do workflow design. Management consultants don't write production code. The FDE collapses the entire stack into one person — or, more realistically, one small team with one terrifyingly broad mandate.
Why this is the most technical job AI is creating
There is a lazy view that "FDE" is just a rebranded solutions consultant in a fleece. That view will get you outcompeted.
A real FDE writes production code. They understand the model's failure modes at a mechanistic level — not "the LLM hallucinates" but "this model degrades on structured extraction past 32k tokens; here is the retrieval strategy I'll use to avoid it." They can read the customer's database schema and decide what to denormalize. They can sit in a workshop with the procurement lead and translate a complaint into an eval case before the meeting ends.
This is the rare combination that used to define the best partner at a top consulting firm and a strong staff engineer at an infrastructure company and a product manager who has shipped real software. AI has welded those three job descriptions together. The market is going to pay — significantly — for the people who can hold all three.
Anyone telling you AI is hollowing out technical work hasn't tried to actually ship an agent into a real enterprise. The opposite is happening: every serious deployment is creating demand for deeply technical, deeply embedded engineers who can do the work, design the work, and teach the customer to run the work. The labor market for that profile is going to look a lot like the labor market for great surgeons — scarce, expensive, and decisive to the outcome.
What this means if you are buying
The honest version: if you are buying an AI agent and your vendor is not putting technically deep, business-savvy people into your workflow during the rollout, assume the deployment will fail. Not because the model is bad. Because the gap between "the model can do this in a demo" and "this is reliably running in our environment" is a chasm that gets crossed by people, not by docs.
A few questions worth asking any agent vendor before signing:
- Who specifically will be in our environment during weeks 1–12, and what is their engineering background?
- What does the eval set look like at handover, and who maintains it after?
- How is the workflow re-mapped before the agent ships, and who signs off?
- What is the monthly tuning cadence after go-live?
- What stays in our four walls when the engagement ends?
What this means if you are running the rollout
The corollary, equally honest: the vendor's FDE will leave eventually. The eval set, the workflow map, the tuning loop — those have to be owned inside your four walls. AI deployment is not an IT project. It is a hybrid product-and-process redesign with code in the middle. The leaders who set up the right operating model around it will compound advantages quickly. The ones who treat it as software procurement will spend three quarters wondering why the pilot never made it to production.
The right internal posture is closer to "we are building a small applied-AI function that owns models the way we own data" than "we are evaluating a vendor."
The shape of the work, going forward
The job title may end up being "Forward Deployed Engineer," "Applied AI Engineer," "Solutions Architect," or something we haven't named yet. The shape of the work is the same. It sits at the seam between the model and the business. And the firms that build a bench of these people — whether in-house or through a trusted partner — will be the ones whose AI bets actually pay back.
Most enterprises will not hire this profile in volume. The role is too cross-functional, too new, and the talent pool is too thin. The realistic operating model for the next 24 months is hybrid: a small internal applied-AI team paired with an outside partner who has done this enough times to bring patterns, not just hands. That is the shape of every serious AI rollout I am seeing right now.
At Kompella Technologies we sit on this seam every day. We work with founders and CXOs as fractional CTOs and CPOs, and ship custom software end-to-end — increasingly, the work looks less like building products and more like deploying intelligence into existing businesses. Which is, precisely, the FDE problem. If you're navigating an AI rollout that's stuck somewhere between "the demo worked" and "the agent is in production," I'd love to compare notes.
— Ganesh Kompella
