Is the Future of the ServiceNow Consultant the Forward Deployed Engineer?

We have a new buzzphrase: it’s called the Forward Deployed Engineer. So naturally you’re probably asking what one of those is.

Before I answer that, let’s look at the lay of the land. Software development has shifted from writing code to expressing intent. But the problem is, the organisations that need the software rarely understand their own workflows in a form that can be handed cleanly to an engineering team, let alone an AI agent. They understand the pressure, the politics, the exceptions, the legacy systems, the workaround that everyone uses but nobody has documented. They understand the work as lived experience, not as a specification.

That is where forward deployed engineering enters the conversation.

The recent paper The New SDLC with Vibe Coding, by Addy Osmani, Shubham Saboo and Sokratis Kartakis, frames the change in software development as a transition from syntax to intent. Developers are no longer only writing code. Increasingly, they are defining goals, context, constraints, tests, evaluation criteria and feedback loops, then using agents to produce the implementation. The paper's distinction between casual vibe coding and disciplined agentic engineering is useful because it separates the seductive part of AI-assisted development from the part that actually survives contact with production.

Vibe coding is what happens when a person describes roughly what they want, accepts the output, and pastes the error message back into the model when it breaks. Agentic engineering is what happens when the AI is surrounded by a proper harness: clear instructions, tools, sandboxes, tests, evals, memory, observability and guardrails. Same underlying capability, very different operating model.

What the paper is trying to tell us is that the scarce skill is no longer typing the implementation. It is discovering, structuring and verifying intent in the messy environment where the work actually happens.

The Old SDLC Assumed the Specification Could Travel

Traditional software delivery depends on a fairly optimistic idea: that intent can be extracted from the business, written down, passed across organisational boundaries, translated into requirements, turned into designs, implemented by engineers, tested by QA, deployed into production and still resemble the original need by the time users encounter it.

Sometimes that works, and it works best where the domain is stable, the category is understood and the workflows are already well formed: payroll, basic accounting, commodity CRM, standard IT ticketing. In those categories, the distance between the user's need and the software's shape is not trivial, but it is manageable.

The model fails when the work is ambiguous, high stakes, undocumented or politically complicated. Which, unfortunately, is a fairly good description of a lot of enterprise software.

The SDLC paper argues that AI compresses the cycle unevenly. Implementation can move from weeks to hours, while requirements, architecture and verification remain human paced. That asymmetry matters, because if code generation gets dramatically faster but requirements stay vague, the organisation does not get better software, it gets bad software faster.

That is the first practical consequence of the agentic SDLC: the bottleneck moves upstream.

The old bottleneck was often implementation capacity. Could the team build the thing? Could they get through the backlog? Could they deploy before the opportunity passed? The new bottleneck is whether the organisation can define the right thing clearly enough, constrain it properly enough and verify it rigorously enough for agents to execute against it.

This is why the phrase "intent as the new interface" is more demanding than it first sounds. Intent is not a wish, not a prompt, and not a paragraph in a product brief. In production software, intent has to become an executable contract between the business, the system and the people who will live with the consequences.

Most organisations are nowhere near that.

What Palantir Proved

The forward deployed engineer model is typically associated with Palantir, and for good reason. Palantir's own description of the role is still the cleanest: a traditional developer focuses on one capability for many customers; a forward deployed software engineer focuses on many capabilities for one customer. The FDE embeds directly with the customer, configures and extends the platform, collaborates with end users, writes production code and feeds field learning back into the product.

That last part is often missed. A forward deployed engineer is not just a clever implementation consultant with a better title. The role only really makes sense if the learning from the field becomes part of the product system.

Palantir built the model because its early customers, including intelligence and defence organisations, were not operating in environments where conventional product discovery worked. The customer could not always share data freely. The workflows changed as threats changed. Requirements were difficult to state because the work itself was partly tacit. Sitting in headquarters, gathering requirements and returning months later with a generic platform was never going to work.

So Palantir put engineers in the field.

In Palantir's 2020 account of a day in the life of an FDSE, the role is described as embedding directly with customers to configure existing platforms against difficult problems, with a skill set spanning software development, data engineering, customer engagement and creative problem solving. The same article makes a clear distinction between the FDE and the consultant: the FDE is technically creative, works quickly, uses the product as a ready built platform, and actually implements the solution with the users. It also states that FDEs still apply rigorous engineering practices: code review, engineering review, deployability optimisation, maintenance and monitoring of production systems.

That combination is the point.

The FDE is not there to observe the customer and write a report. They are there to collapse the distance between observation and implementation. They watch the work, build against the work, see the result, adjust the system, and carry the pattern back into the platform when it generalises.

In other words, the FDE is an intent translation mechanism.

Not translation in the weak sense of turning business words into technical words. Translation in the stronger sense of converting a messy operational reality into software, tests, data models, interfaces, permissions, workflows and product primitives.

That is much closer to what the new SDLC demands.

Why AI Makes the FDE Model More Relevant, Not Less

It would be easy to assume that better AI agents reduce the need for forward deployed engineers. If agents can read codebases, generate tests, integrate APIs and produce production pull requests, why do you need expensive engineers embedded with customers?

I think the opposite is more likely.

AI reduces the cost of implementation, which increases the value of knowing what to implement. When generation is expensive, organisations ration development effort. When generation becomes cheap, they need stronger judgment about where to point it.

The SDLC paper makes this point through the distinction between vibe coding and agentic engineering. The difference is not whether AI is used. The difference is how much structure, verification and judgment surrounds the AI's output. Tests verify deterministic behaviour. Evals verify less deterministic behaviour, such as the trajectory an agent took, the tools it chose and whether the final result meets a quality bar. Without both, the practice remains closer to vibe coding than production engineering.

The forward deployed engineer sits exactly at that boundary. They are close enough to the customer to understand what matters, and technical enough to turn that understanding into the harness around the agent.

That harness is one of the strongest ideas in the SDLC paper. A raw model is not an agent. It becomes useful when surrounded by instructions, tools, memory, orchestration, sandboxes, hooks and observability. The behaviour users experience is dominated not only by the model, but by the harness wrapped around it.

This matters because most enterprise AI failures are not really model failures. They are context failures, integration failures, evaluation failures, permission failures and workflow failures. The model gets blamed because the model is visible. The missing harness is less visible.

The FDE's job is increasingly to build that missing harness inside the customer's reality.

That means understanding which systems are authoritative. Which workflow exceptions matter. Which approvals are formal and which are cultural. Which dataset looks canonical but is not trusted by the people who actually use it. Which integration has to be real time, and which only needs to be updated by tomorrow morning. Which decision can be automated, and which should only be recommended.

A remote product team can guess at these things. A forward deployed engineer can find out.

Context Engineering Is Field Work

One of the most important sections of the SDLC paper is its treatment of context engineering. The paper argues that the quality of AI-generated code depends less on clever prompting and more on the quality of the context supplied to the agent: instructions, knowledge, memory, examples, tools and guardrails.

That sounds like an internal engineering discipline, and it is. But for enterprise AI, context engineering is also field work.

Anthropic's 2025 essay on context engineering makes the same shift explicit. Prompt engineering is about writing and organising instructions. Context engineering is about curating and maintaining the whole state available to the model: system instructions, tools, external data, message history, MCP connections and anything else that might influence behaviour. Context is finite, and as it grows, attention degrades. The work is to provide the smallest high-signal set of information likely to produce the desired outcome.

That is a technical problem, but it is also an ethnographic one.

You cannot curate high-signal context for a claims workflow, a security operations process, a supply chain exception queue or a financial crime investigation unless you understand the domain. Not abstractly, but specifically. You need to know what the words mean inside that organisation, which cases are routine and which are genuinely risky, and where the historical process diagrams differ from actual behaviour.

This is where the FDE and the agentic SDLC converge.

The forward deployed engineer is not merely integrating software. They are discovering the semantic map the agent will need in order to act. That may become an ontology, an AGENTS.md file, or a set of tools, schemas, evals, prompts, memory policies and guardrails. The format matters less than the function: capture enough of the customer's operational reality that a machine can do useful work without pretending the world is cleaner than it is.

That is probably why ontology engineering is reappearing in AI discussions. Agents need maps, because a language model can read text, but it does not automatically know what a "customer", "case", "incident", "asset", "claim" or "approval" means in a particular business. It certainly does not know which system owns the truth, which fields are advisory, which status values are obsolete and which exception path everyone uses on Fridays because the formal one is broken.

Humans carry that in their heads; agents need it externalised.

The FDE is one of the few roles positioned to do that externalisation properly, because they can sit with the people doing the work and turn tacit knowledge into operational context.

The MIT NANDA Findings Are Really About Learning

The most cited enterprise AI statistic of the past year is probably the MIT NANDA finding that 95 percent of organisations saw no measurable return from generative AI initiatives. The number gets repeated as "95 percent of AI pilots fail", which is a little too blunt. The underlying report, The GenAI Divide: State of AI in Business 2025, is more useful than the headline.

The report reviewed more than 300 public AI initiatives, interviewed representatives from 52 organisations and surveyed 153 senior leaders. Its central claim was that despite $30 to $40 billion of enterprise GenAI investment, only 5 percent of integrated AI pilots were extracting millions in value, while the vast majority had no measurable P&L impact. The report explicitly says the divide does not appear to be driven mainly by model quality or regulation. It is driven by approach instead.

The most interesting line is not the 95 percent figure. It is this: "The core barrier to scaling is not infrastructure, regulation, or talent. It is learning." The report argues that most GenAI systems do not retain feedback, adapt to context or improve over time. Custom enterprise systems stall because of brittle workflows, lack of contextual learning and misalignment with day-to-day operations.

That is almost a job description for forward deployed engineering.

The organisations on the wrong side of the divide are not necessarily buying bad models. They are failing to build systems that learn the workflow, remember the context, adapt to the operation and prove value against business outcomes. They are treating AI as a capability to be installed rather than a system to be embedded.

External partnerships did better in the MIT analysis. Buyers who succeeded demanded process-specific customisation and evaluated tools against business outcomes rather than software benchmarks. Again, the pattern is hard to miss. The closer the AI system gets to the real workflow, and the more deliberately it is adapted to that workflow, the more likely it is to matter.

That does not mean every organisation needs Palantir-style FDEs. It does mean that AI adoption is much less self-service than the early narratives suggested.

The enterprise does not need another impressive demo. It needs someone to sit inside the work long enough to build the learning loop.

Forward Deployed Engineering Is Not Just Services

The usual criticism of the FDE model is that it looks like services. In some implementations, that criticism is fair. If an FDE function becomes a team of expensive engineers doing bespoke customer work that never feeds back into the product, then it is services with better branding.

That can be commercially useful, but it is not a scalable product strategy.

The stronger model has a different loop. Field work produces customer-specific solutions, those solutions reveal recurring patterns, and the recurring patterns become product primitives, reusable skills, shared evals, connectors, ontologies, reference architectures and deployment playbooks. The next engagement starts from a higher baseline.

That loop is what separates forward deployed engineering from traditional consulting.

A consultant can solve the client problem and leave. A systems integrator can wire the system together and move on. A genuine FDE function should improve the core product by doing the work. The field is not downstream of product. It is part of product discovery and product hardening.

First Round's 2025 analysis of the FDE hiring wave makes this point well. Shilpa Balaji, formerly of Palantir, argues that deeply understanding the customer and executing through implementation is important, but not sufficient. The FDE model requires creativity and innovation. It is about discovering new things in a customer context and decentralising product development. Jake Stauch of Serval makes a similar point: the FDE should be an actual member of the software engineering team, not forced into implementation only, because FDEs talking to customers all day can make the product better while reducing implementation friction.

That distinction is going to matter more as the title spreads.

The Pragmatic Engineer has already noted that some newer FDE roles are starting to look much closer to consultants or solution architects, particularly where AI labs create separate deployment companies or FDE-heavy partner structures outside the core product organisation. That may still produce useful outcomes for customers. But it weakens the product feedback loop.

For me, the test is simple: does the field work change the product?

If it does, the organisation is building a learning system. If it does not, it is selling custom labour.

The New SDLC Creates a New Division of Labour

The SDLC paper describes two developer modes: conductor and orchestrator. In conductor mode, the developer works hands on with the AI in real time, guiding, correcting and reviewing as code appears. In orchestrator mode, the developer defines goals, delegates to agents, reviews outputs and manages multiple streams of work asynchronously. The second mode requires specification, decomposition, evaluation and system design more than syntax fluency.

That framing is useful, but I would add a third role for enterprise contexts: the translator. The translator is not junior to the conductor or orchestrator. In many cases, they are the most important person in the system. They are the one who can stand between the customer, the business process, the data estate, the product platform and the AI agents, then construct a shared representation that the system can execute against.

That is the forward deployed engineer at their best.

They are not merely conducting an agent; they are discovering the score. They are not merely orchestrating background tasks; they are defining which tasks exist, which constraints matter and what correctness means in the customer's world.

The AI-native SDLC makes this role more central because implementation work is no longer the scarcest resource. A developer with a good agent can generate a feature quickly. A team of agents can generate many features in parallel. But if the organisation cannot specify the right work, decompose it cleanly, provide relevant context and evaluate the result, the output becomes noise.

The future software team may therefore look less like a group of people arranged around a backlog and more like a small operating system for translating intent into verified change. Some people will specialise in architecture, some in agent harnesses, some in evals and quality, some in platform primitives, some in customer field work. The FDE is the boundary-spanning role that keeps the whole system attached to reality.

The Economics Shift From Build Cost to Verification Cost

One of the better sections in the SDLC paper is its economic framing. Vibe coding appears cheap because the upfront cost is low: a subscription, a prompt, a prototype. But it pushes cost into operations: token burn from repeated prompting loops, maintenance tax from inconsistent code, and security remediation when unverified output reaches production. Agentic engineering has higher upfront cost. It requires schemas, tests, evals, context design, guardrails and harness components before the system is allowed to produce production code. But the marginal cost of safe change falls over time because the factory improves.

That economic frame applies directly to FDE work.

An embedded engineer looks expensive compared with a self-service SaaS rollout or a lightweight integration partner. But the comparison is often misleading. The real alternative is not "cheap software that works". It is usually "cheap software plus months of internal confusion, partial adoption, shadow workflows, manual reconciliation and a failed pilot that nobody wants to discuss".

The cost exists either way. The question is where it sits.

Forward deployed engineering moves cost to the front of the engagement, where it can be used to learn the workflow, build the harness, define evals, integrate properly and create a product feedback loop. Traditional delivery often moves cost to the back, where it appears as support tickets, rework, user resistance, brittle automations and quiet non-adoption.

The MIT NANDA report's finding that external partnerships outperformed internal builds should not be read as a blanket argument for outsourcing AI. It is more specific than that. Experienced external teams may carry deployment patterns, integration knowledge and workflow translation skills that internal teams have not yet developed. They have seen enough failures to know which parts of the harness matter.

Over time, the healthiest customers will internalise some of that capability. They will not rely indefinitely on vendor FDEs to understand their own operations. But in the early phase of AI adoption, the forward deployed model can act as a transfer mechanism: it gets the system working while teaching the organisation what production AI actually requires. That teaching function is underrated.

The 80 Percent Problem and the Last Mile

The SDLC paper describes an 80 percent problem: AI agents can rapidly generate roughly 80 percent of a feature, but the remaining 20 percent, the edge cases, integration points, error handling and subtle correctness requirements, still demands deep contextual knowledge.

This is not only a coding problem; it is a delivery problem.

Enterprise AI is full of 80 percent solutions. The demo works. The prototype answers the right questions. The agent can handle the happy path. The dashboard looks convincing. The executive sponsor is briefly excited.

Then the system meets production, and the data is not clean, the workflow has exceptions, and the user does not trust the recommendation. The compliance team asks what happens when the model sees restricted data. The integration assumes a status field that is used inconsistently across regions. The agent performs well on the benchmark but fails on the customer-specific cases that actually matter. The prototype solved the visible problem but missed the operating context.

The last 20 percent is where the value is.

Forward deployed engineers are effective because they live in that last 20 percent. They do not merely know how the system should work. They see how it fails, where users hesitate, which edge cases recur, and which constraints were missing from the original design. They can convert those observations into tests, evals, tool changes, data contracts, permission models and product requests.

In agentic systems, that last 20 percent becomes even more important because the system is not just producing information. It may be taking action.

A bad chatbot answer is annoying. A bad agent action can be expensive. It can send the wrong message, update the wrong record, trigger the wrong workflow, expose the wrong data or create a compliance problem. The more autonomy we give the system, the more valuable it becomes to have someone close to the customer who understands the operational blast radius.

This is why I am wary of any AI deployment strategy that treats forward deployed work as a temporary inconvenience before everything becomes self-service. Self-service will happen for stable patterns. But the frontier of enterprise AI will keep moving into messier, more contextual, more agentic work.

That is precisely where self-service breaks.

What This Means for Engineering Leaders

The practical implication for engineering leaders is not simply "hire FDEs". That would be too easy, and probably wrong for many companies.

The first question is whether your product actually needs the model. If the problem is standardised, the workflow is well understood and the value can be reached through configuration, a conventional product-led or implementation-led motion may be better. Forward deployed engineering is powerful, but it is not cheap and it is not automatically scalable.

The second question is whether your organisation has a product feedback loop strong enough to justify it. If field engineers discover the same customer problem ten times and nothing changes in the core platform, the model will degrade into services. That may still generate revenue, but it will not compound.

The third question is whether you know what kind of FDE you need. The job market is already using the title for several different roles: builder FDEs who write production code with customers, sales-engineer-plus roles that support proof of concept work, and internal tooling roles that probably should not be called FDEs at all. The title matters less than the operating model.

A serious FDE function needs at least four things.

It needs engineers with real production judgment, because customer proximity does not excuse weak engineering. It needs access to users and systems, because the model fails if the engineer is kept at arm's length. It needs a mechanism for turning field patterns into product work. And it needs a clear boundary between exploration and production, because shipping prototypes by accident is one of the easiest ways to create AI debt.

For teams adopting AI internally, the same principles apply even without the title. Someone has to do the FDE work. Someone has to sit with the operator, understand the workflow, map the data, define correctness, build the evals and close the loop between what the agent does and what the business needs.

If nobody owns that, the organisation is vibe coding at enterprise scale.

What This Means for Consultants and Systems Integrators

There is also an uncomfortable implication for consulting firms and systems integrators. A lot of traditional delivery work is built around handoffs: discovery to design, design to build, build to test, test to support. That model already struggled with complex software. It struggles even more with agentic systems because the learning loop is tighter. The system has to be observed, evaluated and adjusted continuously against live behaviour.

The forward deployed model compresses those handoffs. The person discovering the workflow is closer to the person building the system. The person seeing the failure is closer to the person changing the harness. The person hearing the user's objection is closer to the person adjusting the eval.

Consultancies can absolutely build this capability, but not by renaming solution architects as FDEs. The role requires stronger engineering depth, more ownership of production outcomes and a much tighter connection to reusable product assets than classic project delivery often allows.

The interesting opportunity is a hybrid one: domain-heavy forward deployed context engineering. Healthcare, insurance, financial services, manufacturing, government operations, legal and regulated service management all have deep domain semantics that generic AI systems will not infer from first principles. Firms that can combine domain knowledge, agentic engineering and field deployment may become much more valuable than firms that merely provide implementation capacity.

But again, the work has to compound. If every engagement starts from a blank page, the economics will break. The reusable assets might be ontologies, eval libraries, process maps, agent skills, integration patterns, governance templates or workflow-specific harnesses. The exact artefacts will vary by domain. The principle is the same: field learning has to become infrastructure.

The FDE as the Human Part of the Harness

The SDLC paper's factory model argues that the developer's primary output is no longer code, but the system that produces code. Specifications, agents, tests, quality gates, feedback loops and guardrails become the factory. The developer designs the assembly line and ensures the output meets the standard.

I like that model, but in enterprise AI there is a missing human layer.

The factory has to be built somewhere. It has to be built around a customer's actual workflows, data, constraints, risks and language. It has to absorb the facts that do not appear in the documentation. It has to discover which parts of the process are real and which are ceremonial. It has to distinguish between what the executive sponsor says the organisation does and what the operators actually do to keep the business running.

That is the forward deployed engineer's terrain.

The FDE is not outside the harness. They are part of how the harness comes into being. They create the context, define the tools, sharpen the constraints, observe the failures and carry the learning back into the product. They are the human sensing layer for agentic software development.

This is also why the role is difficult to hire for. It asks for a strange combination of traits: engineering depth, domain curiosity, customer credibility, ambiguity tolerance, product judgment and enough humility to sit next to an operator and admit that the documented process is not the real process. Many engineers do not want that job. Many consultants cannot do the engineering part. Many product managers can understand the customer but cannot build the system.

The people who can do all three will be unusually valuable.

The Risk: Romanticising the Role

There is a danger in over-romanticising forward deployed engineering. The current hype around the role can make it sound like every AI company simply needs a small group of engineer-diplomats and the deployment problem disappears.

That is not really true. The model can fail in several predictable ways. It can become bespoke consulting that gives the product nothing back. It can burn out engineers who are asked to be developer, product manager, account lead, support engineer and change manager at once. It can create unclear accountability between sales, product and engineering. It can produce heroic one-off deployments that nobody else can maintain. It can encourage customers to outsource too much of their own operational understanding.

It can also become a way for immature products to hide behind labour.

If every customer needs months of embedded engineering before the product produces value, that may mean the market is genuinely complex. Or it may mean the product is not yet coherent enough. The FDE model should not become an excuse for never making the product simpler, more repeatable or more self-service where self-service is possible.

The best version of the model contains its own discipline. FDEs should not only solve, they should abstract. They should not only customise, but identify which parts of the custom work deserve to become platform. They should not only delight the current customer, they should reduce the effort required for the next one.

Otherwise the organisation has not escaped the services trap. It has just hired more technical people into it.

The Direction of Travel

The new agentic SDLC changes the shape of software work in a way that makes forward deployed engineering feel less like an odd Palantir artefact and more like an early version of a broader operating model.

If AI agents can generate implementation, the premium shifts to intent, context, verification and judgment. If context engineering determines output quality, someone has to discover and maintain context. If evals are the contract with the agent, someone has to define what good looks like in the customer's world. If the harness determines behaviour, someone has to build the harness around real operational constraints.

That someone will often look a lot like a forward deployed engineer.

Not always by title, though: in some organisations it will be an applied AI engineer. In others, an agent engineer, platform engineer, technical product lead, solution architect with production authority, or domain engineer embedded with the business. The label matters less than the function.

The function is to close the distance between messy human intent and verified machine execution.

That is why the FDE model is so relevant to the new SDLC. It is not simply a go-to-market tactic for AI startups. It is a response to the same underlying shift: software is becoming easier to generate and harder to specify safely. The valuable work moves toward the boundary between the system and the world.

For a long time, software engineering rewarded the person who could translate a clear requirement into code. The next phase will reward the person who can stand inside an unclear environment, discover the real requirement, encode it as context, constrain the agents, verify the output and turn the learning into something the next team can reuse. That is forward deployed engineering in its most useful form.

References

• Addy Osmani, Shubham Saboo and Sokratis Kartakis, The New SDLC with Vibe Coding: From ad-hoc prompting to Agentic Engineering, May 2026.

• Palantir Blog, "A Day in the Life of a Palantir Forward Deployed Software Engineer", 2020.

• Anthropic Engineering, "Effective context engineering for AI agents", 2025.

• MIT Project NANDA, Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, July 2025.

• First Round Review, "So You Want to Hire a Forward Deployed Engineer", 2025.

• The Pragmatic Engineer, "What are Forward Deployed Engineers, and why are they so in demand?", 2025; "The Pulse: Forward deployed engineering heats up again", 2026.

• OpenAI Careers, "Forward Deployed Software Engineer", 2026.

• Palantir Careers, "Forward Deployed AI Engineer", 2026.