Build the third layer before anyone hires you for it.
The forward-deployed engineer title is in demand because one layer of the job is scarce, and that layer is not the one a course teaches. Here is what the layer is, why it is only learnable against a live operation, and three projects that prove it without an employer.
The demand is real, and it is for one specific layer
The numbers behind the title are public. Indeed data shared with Business Insider put postings for forward-deployed engineers in April 2026 at 5,230 percent above their January 2025 level, roughly a 729 percent rise year over year, with advertised pay from about $170,000 to over $200,000. OpenAI has organized the work as a dedicated deployment company. Amazon has described a billion-dollar forward-deployed engineering unit. Salesforce tripled its own team in six months, and reports that close to half of that growth came from engineers, services staff, and customer-success people moving over from inside the company.
Ed Donner's explainer on the role, which prompted a lot of the questions we have been asked this month, describes the job as five hats: software engineer, AI engineer, AI solutions architect, domain expert, and solutions consultant. We read them as layers, because you stack them in order and each one rests on the one below. The narrow job at a lab asks for all five. The broad job, where most of the openings are, asks for the first three.
Notice where the scarcity lives. The first two layers can be learned at a desk, and the market has plenty of people who hold them. The third layer, the one that turns an AI engineer into a forward-deployed one, is learned in front of an operator whose queue you are about to change. That is the layer the postings are paying for, and it is the layer this platform is organized around.
Layers one and two get you the interview. Layer three is what the compensation band is actually pricing.
Two of the layers are learnable at a desk
Software engineering is the floor and it never comes off. You ship production code inside a real organization, you work with coding agents without shipping what they emit unread, and you stay accountable for every change that carries your name. Nobody skips this layer, which is exactly why it cannot be faked.
AI engineering is the second layer: choosing a model and knowing why, calling the model APIs, wiring an agent to tools and retrieval, engineering its context, giving it memory and state, and evaluating its behavior before anyone depends on it. The newer discipline of harness engineering belongs here too, the scaffolding of permissions, checkpoints, and tool contracts that turns a model into a governed worker. The Foundations layer of this curriculum and the agent-systems modules cover this ground, and the standard we hold is that you can show the work as a running system rather than describe it.
- Software engineering: production code, agent-assisted, fully owned
- AI engineering: model choice, agents, retrieval, tools, context, evaluation, harness
- Both are visible in a portfolio; neither requires a customer to acquire
The third layer is learned against a live operation
The third layer is what Donner calls the AI solutions architect hat, and it is really a set of obligations that only exist when a real operation is on the other side of the work. Discovery, because the workflow is never what the org chart says. Evaluation design, because correct has to be defined from the operation's own cases before the system is trusted. Data curation, because the proprietary data the client has and the data it needs are rarely the same set. Deployment under real controls, because the prototype credentials will not be there in production. Observability, because an agent that crosses three systems has to be reconstructable afterwards. Adoption, because a system nobody uses did not ship. And responsible AI, because safety and security are requirements you satisfy in architecture rather than a slide at the end.
Every one of those obligations maps onto the six-stage field loop this curriculum is built around. Discover and Frame are discovery and evaluation design. Build carries the data and integration work. Deploy is the governed release. Recover is observability turned into a controlled diagnosis. Handoff is adoption made concrete, with a named owner who can operate the system without you. The loop is not a metaphor for the third layer. It is the third layer, written down in the order it happens.
This is also why the platform does not certify reading. Comprehension was never the scarce thing. The scarce thing is the ability to take an ambiguous, consequential workflow and carry it to a system that runs under someone else's constraints, and to prove it did.
THIRD-LAYER OBLIGATION FIELD LOOP STAGE WHAT THE EVIDENCE LOOKS LIKE---------------------------- ----------------- -------------------------------------Discovery Discover an operating map of the real workflowEvaluation design Frame an evaluation set drawn from real casesData curation Build data contracts and the gaps they exposeDeployment under controls Deploy a release under production-shaped identityObservability Recover a trace that reconstructs one bad runAdoption and transfer Handoff a named owner who operated it without youResponsible AI every stage the control boundary designed in, not onNone of these rows is a reading assignment. Each one is an artifact a reviewer can argue with, which is the only kind of evidence that survives a hiring conversation.
Three projects that prove the third layer without an employer
If you can already wear the first two layers, the fastest route into the third is a seat in front of a customer, and Salesforce's internal-transfer numbers show how often that seat opens from inside a company. While you are waiting for it, build. The best thing to build is a solution to a pain you actually have, fixed with models and agents, then shown wherever you show work. The subject matters less than the discipline you bring to it.
Here is the discipline. A project that runs on your own broad credentials, reading data you copied into a notebook, proves that the idea works. A project that runs under a least-privilege identity, against data it had to be granted, with an evaluation set that says what correct means and a runbook someone else could follow, proves that you understand the third layer. Same idea, different object, and anyone who has deployed inside an enterprise can tell them apart in one conversation.
- The pain-point build: pick something that frustrates you at work, map the real workflow before writing code, and ship it under a production-shaped identity rather than your own login
- The evaluation set: collect twenty to fifty real or realistic cases, including the exceptions and the ones the system should refuse, write down what correct means, and make the suite the gate for every change
- The transfer: write the runbook and the rollback, then hand the system to someone else and watch them operate a normal case, diagnose a failed one, and roll it back while you stay silent
A personal project that produces an operating map, an evaluation set, a control boundary, and a transfer record is a stronger signal than most resumes we read.
How this maps to the training, and to the rest of the family
Every conversation about this role at LockedIn Labs opens the same way: show me your portfolio. Enterprise engineers usually cannot show the code, and that was never the ask. You can name the production systems you worked on and what your hands did there. If the honest answer today is nothing in production yet, that changes what the conversation is about rather than ending it, and it is why the missions here are production-shaped work under review rather than a course with a test at the end.
The three properties in this family say the same thing from three directions. The firm's field guide on lockedinlabs.ai lays out the layers and the path in for the engineer deciding whether to pursue the role. This platform is where the first two layers get built and the third gets rehearsed, against the published FDE Field Standard. The FDE Benchmark publishes the evidence states, from a claimed skill through observed, demonstrated, and production proven, that a credible record of this work should be built on, and it is deliberately separate from the training so completing a module never masquerades as proof.
The titles will keep multiplying and the models will keep getting stronger. The obligation the third layer carries, that a real operation is better off and someone else can run the system after you leave, is the part that does not go out of date.