Forward Deployed Engineering Is Evolving: The Engineer Alone Is No Longer Enough

Why an AI Engineer Alone Is Not Enough

Consider a common enterprise conversation. A business leader says:

Technically, there are several ways to build it. We can connect an LLM to enterprise data, introduce RAG, give an agent access to APIs, automate workflows and place guardrails around its behavior. But the implementation options are not necessarily the hardest part. The more important questions are usually:

• What should the agent actually do, and which decisions can it make independently?
• Where must a human remain involved?
• What happens when there is an exception or the agent gets something wrong?
• Which business rules cannot be violated?
• What information can the agent access?
• How will employees work differently once the agent is introduced?

And there is an even more fundamental question:

That is where AI initiatives move beyond engineering. Technology expertise remains essential, but the team also needs people who understand the business process, industry context, organizational constraints and the employees who will eventually use the system.

What the FDE POD Looks Like

Four roles become particularly important when an enterprise moves from an isolated AI pilot to an operating model that can scale.

1. The AI Architect

The AI Architect looks beyond the immediate use case. The first solution must work, but someone also needs to consider what happens when the organization moves from three AI use cases to thirty, or eventually three hundred.

The architect determines how AI fits into the existing enterprise architecture: which models and platforms make sense, where agents are appropriate, where deterministic systems should remain, how enterprise data and metadata are exposed, and how identity, access, security, monitoring and governance should work.

Above all, the architect asks the question many pilots overlook: what happens when this must scale across the enterprise? A proof of concept can be built relatively quickly; an AI foundation that can survive enterprise scale is a different challenge.

2. The AI Engineer

The Forward Deployed Engineer remains central to the model because this is the person building the intelligence layer close to the customer and the operating problem. That work may include agents, retrieval systems, knowledge graphs, integrations, orchestration, evaluation frameworks, guardrails, APIs, monitoring and workflow automation.

The real advantage of the Forward Deployed model, however, is not simply technical capability. It is proximity. In too many large technology programs, requirements travel through several layers before reaching engineering:

1. The business explains the problem to product.
2. Product passes it to a Business Analyst.
3. The Business Analyst documents it.
4. Architecture interprets it.
5. Engineering builds it.
6. The business finally sees the result.

By that stage, everyone may have done their job correctly and the solution can still miss the original intent. Forward Deployed Engineering shortens that distance and creates a much simpler loop:

That sounds obvious, but in a large organization it can be transformational. The closer engineering gets to the problem, the shorter the distance between experimentation and ROI.

3. The Domain Expert

The Domain Expert is the role many AI programs underestimate. A general model may understand an industry, but it does not automatically understand how a specific enterprise operates:

• An LLM may understand insurance, but not how your company underwrites a particular insurance product.
• It may understand manufacturing, but not which exception rules matter inside your plant.
• It may explain retail pricing strategies, but not the commercial realities behind your organization’s pricing decisions.

An enormous amount of business knowledge does not sit neatly in databases. Some of it lives in documentation, while much of it lives in people’s heads. The Domain Expert brings that context into the implementation.

They help the team determine where automation makes sense, where judgment is required, which exceptions matter, which rules cannot be violated and what a genuinely useful outcome looks like. This becomes especially important as AI systems move from providing information to recommending or taking actions.

You need both. The most dangerous AI system is not one that cannot answer. It is one that confidently misunderstands the business.

4. The Business Analyst

The Business Analyst does more than document requirements. In an AI transformation, this role helps rethink the process itself. Imagine a workflow with fifteen steps. The obvious question is, “Which of these steps can AI automate?” That is useful, but it is probably not the best question.

The better question is:

Often, the answer is no. The redesigned process may look very different:

• Some steps disappear or combine.
• Some decisions become automated.
• Humans move from processing every case to managing exceptions.

The Business Analyst connects the current process, the business problem, the AI intervention, the future process and the measurable business outcome. That is very different from simply adding AI to an existing workflow.

Why the POD Model Creates Better ROI

The biggest advantage of the POD is not simply having four different skill sets. It is having those skills work together against the same business outcome:

• The AI Architect understands what can scale.
• The AI Engineer understands what can be built.
• The Domain Expert understands what will work in reality.
• The Business Analyst understands what should change.

Together, they reduce one of the biggest hidden costs in enterprise transformation:

Every time context moves from one team to another, requirements can be simplified, exceptions can disappear, intent can be interpreted differently and decision making can slow down. The FDE POD compresses that distance. Enterprise AI moves at the speed of context, not just compute.

This Is Really a Change Management Problem

Another part of the AI conversation deserves far more attention: adoption. An AI system can be technically excellent and still create very little business value. You can build an accurate agent, integrate it with the right systems and create an excellent user experience, but if employees continue using the spreadsheet they have trusted for eight years, the transformation has failed.

Enterprise AI therefore cannot be treated purely as a technology rollout. It changes:

• How people work and which tasks they perform.
• Who makes decisions and where approvals happen.
• How responsibilities and, in some cases, entire job descriptions are defined.

That makes change management a core part of AI transformation, not an activity that begins two weeks before launch.

Technology can be deployed. Adoption has to be earned.

We Have Seen Something Like This Before

There is an interesting parallel with the early days of ERP. Organizations did not simply install SAP and continue working exactly as before. ERP programs forced companies to confront years of accumulated processes: business units performing the same activity in different ways, countries following different workflows, and critical operations depending on spreadsheets, email or knowledge held by a few experienced employees.

Implementing ERP meant asking difficult questions:

• What is the standard process, and who owns it?
• Which variations are genuinely necessary?
• Which legacy practices should disappear?
• What should be standardized, and who owns the data?

Those conversations were often harder than the technology implementation itself. Successful transformations also required leadership sponsorship because enterprise processes could not be standardized one department at a time without difficult decisions from the top. AI is approaching a similar moment.

Individual teams can experiment from the bottom up, but enterprise transformation requires leadership to decide how the organization itself should operate differently.

AI Should Not Become Another Tool

Most employees already have enough tools: ERP systems, CRM platforms, dashboards, ticketing systems, spreadsheets, email, collaboration tools, document repositories and specialized applications. The last thing they need is another tab called “AI” that they must remember to use.

If that is how AI is implemented, we will have missed much of the opportunity. AI needs to become a foundational hygiene layer inside business processes. It should:

• Provide information and retrieve organizational knowledge when needed.
• Validate decisions and identify unusual activity.
• Automate repetitive work and surface exceptions.
• Increasingly coordinate actions across systems.

Employees should not constantly have to decide whether they should “use AI.”

We do not ask whether a modern application should use data, security, APIs or cloud infrastructure; those capabilities are simply expected to exist. Over time, intelligence will probably become the same. If AI is just another tool, we have already underused it.

Efficiency Matters, but So Does Error Reduction

There is a lot of discussion around AI productivity, and rightly so. If someone can complete a thirty minute task in five minutes, the economics become interesting very quickly. But there is another category of ROI that is equally important:

Enterprises deal with thousands of small operational mistakes every day:

• A field is entered incorrectly or an important document is overlooked.
• A policy is interpreted inconsistently.
• A duplicate transaction is processed.
• An approval is delayed or an exception is missed.

Individually, these mistakes can look insignificant. At enterprise scale, they can become extremely expensive. AI can act as a continuous validation and intelligence layer across these processes, not simply making people faster but helping them make fewer mistakes.

The ROI equation should therefore include more than hours saved:

Sometimes preventing one serious error is worth far more than saving five minutes across thousands of tasks.

AI Governance Is the Elephant in the Room

Governance remains one of the biggest unresolved questions in enterprise AI. The desire to move quickly is understandable: technology is advancing, competitors are experimenting and leadership teams want results.

But governance cannot be introduced only after a pilot succeeds. By then, important architectural and operational decisions may already have been made. Governance needs to be part of the design from Day 1.

The moment an AI system interacts with enterprise data or starts influencing decisions, we need to know:

• What information can it access, and who granted that permission?
• Which model produced the output, and what enterprise context was used?
• Which actions can the system take automatically, and where is human approval mandatory?
• How are failures detected and model behavior evaluated over time?
• How are prompts, policies and models versioned?
• Can we audit what happened later, and who is ultimately accountable?

These are not compliance questions to ask at the end. They are product, architecture and business questions from the beginning.

Governance Becomes Even More Important With Agents

This becomes particularly important as enterprises move from copilots to autonomous and semi autonomous agents. There is a meaningful difference between an AI system suggesting an answer and an AI system taking an action.

If a chatbot gives an employee an incorrect summary, that creates one level of risk. If an agent approves something, modifies an order, initiates a refund, updates an account or triggers an operational workflow, the consequences can be very different. As AI autonomy increases, governance has to mature with it.

The answer is not to slow innovation. The better approach is to create clear boundaries within which teams can move quickly.

That is more sustainable than trying to retrofit trust later. The more autonomy we give AI, the more intentional its governance must become.

Start With the Outcome, Not the AI

There is a practical implication for how FDE teams should engage with enterprises. Instead of beginning with, “What AI use case can we build?”, start with a measurable outcome:

• Reduce underwriting turnaround time.
• Lower customer support cost per interaction.
• Reduce manufacturing quality exceptions.
• Improve order accuracy or first contact resolution.
• Cut manual reconciliation effort.

Then work backwards:

1. Understand why the process performs the way it does today.
2. Identify the real bottleneck and bring in the domain expert.
3. Map the data and redesign the process.
4. Determine where AI actually belongs.
5. Build and govern the solution.
6. Put it in the hands of users and measure whether anything changed.

That is where the FDE POD starts to look less like a delivery team and more like a small transformation unit.

The FDE POD as a Transformation Unit

The four roles complement one another naturally:

• The AI Architect ensures the team is building on a foundation that can scale.
• The AI Engineer turns ideas into working systems.
• The Domain Expert makes sure those systems reflect how the business actually operates.
• The Business Analyst redesigns the workflow around the new capability.

Those four roles do not operate in isolation. They need a broader transformation model around them:

• Change Management: because people have to work differently.
• AI Governance: because intelligence and autonomy need boundaries.
• Executive Sponsorship: because significant process redesign rarely happens through bottom up experimentation alone.

That combination is what makes the model interesting. AI transformation is too strategic to be left purely to engineering, but too technical to be driven by business teams without deep engineering involvement.

The Hard Part of Enterprise AI May Not Be the AI

Over the next few years, models will improve, inference will become cheaper, infrastructure will mature and agent frameworks will become more standardized. Many of today’s difficult technical problems will become easier.

Organizations will still need to answer much harder questions:

• Which processes should we redesign, and which tasks should disappear completely?
• Where should humans remain in control?
• Which decisions can AI make?
• How do we preserve accountability and earn employee trust?
• How do we govern systems that increasingly act rather than simply advise?

Those are not model questions. They are organizational questions.

That is why Forward Deployed Engineering will continue to evolve. The future of FDE is not simply about placing better engineers closer to customers. It is about putting a compact team of technology, business and domain expertise directly against an important business problem, then giving that team enough proximity to understand it, enough capability to solve it and enough governance to scale it safely.

• Technology enables the change.
• Process redesign unlocks the value.
• Governance makes it sustainable.
• Adoption determines the ROI.

And perhaps the most important point is this: