The labs now ship enterprise agents with engineers attached, and the job those engineers do is the job I already do on my own estate.
The labs building enterprise agent products have started attaching engineers to the sale. Not support staff who answer tickets after the contract is signed — engineers who sit inside the deployment, wire the agent to the customer's actual systems, and stay there while it breaks in ways the demo never showed. The title varies, but the shape is the same everywhere it appears: forward deployed engineer. I run the same loop on my own estate, alone, every day, and I think the role description is more honest about what agent work actually is than most of what gets written about "AI engineering."
The demo is the easy ten percent. An agent that reads a repo, writes a patch, and opens a pull request looks finished the moment it works once. What it does not show is the part that consumes almost all of the real time: deciding what the agent is allowed to touch, what it must never touch, what counts as done, and what happens when it is confidently wrong. None of that is a model capability. It is operations — the same category of work as running a service, except the thing you are operating occasionally invents facts and needs someone watching for it.
Gating is the piece nobody puts in the pitch deck. Every agent I run sits behind something that stops it before it ships: a review it cannot pass itself, a test it cannot fake, a human who has to say yes on the actions that are hard to undo. Build that gate wrong — too loose, and a confident wrong answer goes out as if it were checked; too tight, and the agent produces nothing because everything queues for a human anyway — and the agent is worse than not having one, because it now looks trustworthy while being unreliable. Getting the gate right is not a feature you add once. It is the ongoing work, and it is exactly what a forward deployed engineer is there to do: not write the agent, but decide where its blast radius stops.
The other half of the job is transport and routing, and it sounds boring until it fails at the worst moment. Which account, which model, which session picks up a task, and what happens when that account runs out of capacity mid-task — those are infrastructure questions with the same weight as choosing a database, except almost nobody treats them that way. I have lost work to a session that silently died and a worker that kept going against a model that had already stopped being served. The fix in both cases was not a smarter prompt. It was building the boring layer — routing, capacity checks, resumption from a live transcript instead of a cold restart — that keeps the agent's mistakes from compounding into your mistakes.
What makes this a distinct role rather than "AI engineer with extra steps" is where the judgment sits. A model provider optimises for the model. A forward deployed engineer optimises for the one specific deployment in front of them — this customer's data, this customer's risk tolerance, this customer's definition of an acceptable failure. That is a different skill from training or fine-tuning, and it does not scale the way a product feature scales; it scales the way an operations team scales, by adding people who each own a smaller number of deployments well rather than one person owning all of them badly.
I think the reason the labs are hiring for this now, rather than assuming the product alone will carry enterprise deployment, is that they have already run into what I run into on a smaller estate: an agent with no one minding the gate is a liability wearing the shape of a feature. The interesting engineering problem in production agent work was never getting the model to produce a plausible answer. It is building the scaffolding that catches the answer when it is wrong, routes around the account that just died, and keeps a record of what actually happened — the unglamorous majority of the work, done by someone whose title says "deployed" because that is literally where they are.