When Your People Who Understand the Business Can Also Build the AI Solution
The emergence of the Forward-Deployed Engineer has been one of the more interesting, expensive and absurd developments in enterprise AI. If it sounds like consulting, smells like consulting, it is consulting. They have their own exotic terminology like harness, prompt (passe), evals, ….
Our experience with “AI Engineer(s)” has been instructive. They extremely well versed with the language of AI and some of the tools. But tend to have little knowledge.. So they come spend months to learn the business and business.
And the lost in translation effect has led to suboptimal results. So much so that our own business teams used Claude Code to build the AI solution themselves. We will go
But before we could do that
The model is understandable because even the most capable frontier model arrives at an enterprise knowing almost nothing about how that particular company actually operates.
A model may understand supply chain management, procurement, manufacturing, engineering, finance and other business domains remarkably well, but it does not know which system contains the authoritative supplier record, how a product relates to a manufacturer part, which engineering changes require approval, how inventory should be evaluated when a supplier misses a commitment, or who is accountable when an exception cannot be resolved automatically. That knowledge is specific to the enterprise, distributed across systems and people, and often accumulated over decades.
Someone therefore has to translate the business into an environment in which AI can operate. Forward-Deployed Engineers increasingly perform that role by working with business and IT teams to understand the problem, model the relevant business concepts and relationships, connect enterprise systems, implement rules and workflows, configure agents, test the resulting application against real data, and continue modifying it until it works reliably.
There is nothing inherently wrong with this approach. In fact, for the first generation of enterprise AI applications, it may have been the most practical way to close the considerable gap between the general intelligence of a frontier model and the highly specific knowledge required to operate inside an enterprise.
The more important question is whether it should remain the dominant model for deploying enterprise AI.
The Scalability Problem Hidden Inside the FDE Model
Enterprise environments are complicated for reasons that have little to do with AI. Data is fragmented across ERP, PLM, CRM, planning, manufacturing, supplier and custom systems. Business processes contain exceptions that may never have been formally documented. Important operating knowledge resides with experienced employees. Systems implemented at different times use different representations of the same business concepts, and even companies running nominally identical enterprise software can operate in substantially different ways.
Putting capable engineers close to these problems is an effective way to make progress. The difficulty appears when forward-deployed engineering becomes the primary mechanism through which AI applications are created and expanded across the enterprise.
A successful initial application rarely remains isolated. One supply chain use case becomes several; several applications expand across additional business processes; and each new application introduces another collection of business objects, relationships, integrations, permissions, rules, workflows and exceptions. Requirements continue to change after deployment, enterprise systems change underneath the application, and new use cases require additional parts of the business to be understood and translated into software.
The implementation organization can therefore grow along with the ambition of the AI program. What appears to be a highly scalable software model can gradually acquire the economics of a professional-services model, in which additional business value requires additional engineering capacity.
This is particularly significant because the engineers performing the implementation are often not the people who possess the deepest knowledge of the underlying problem. The supply chain organization understands how supplier exceptions should be handled. Component engineers understand whether two manufacturer parts are genuinely interchangeable. Product teams understand the company’s new-product-introduction process. Master-data specialists understand the classification and governance rules. Internal IT understands the systems landscape, security architecture and enterprise integration standards.
Historically, there was a straightforward reason these people could not simply build the applications themselves: understanding the business and implementing enterprise software were different skills. The business expert could describe what needed to happen, but specialized engineers were required to translate that knowledge into data models, integrations, code, workflows and applications.
Frontier models are beginning to change that division of labor.
What Has Changed
The significance of modern frontier models is not simply that they can answer questions about enterprise domains. They can increasingly participate in software implementation itself. A capable model can interpret a business requirement, design data structures, generate application logic, work with APIs, analyze logs, diagnose failures and modify an implementation based on what it observes.
This does not mean that a supply chain analyst, procurement specialist or component engineer suddenly needs to become a software developer. It means that the distance between understanding a business problem and implementing a working solution can become substantially shorter.
Consider a supply chain analyst describing the following requirement:
If a strategic supplier pushes a delivery out by more than seven days, determine which customer commitments are affected. If sufficient inventory or another approved source is available, identify the alternatives. Otherwise, escalate the exception to the responsible buyer and planner.
The difficult part of this requirement is not writing the code that compares two dates. The difficult part is understanding what constitutes a strategic supplier, where customer commitments are represented, how sufficient inventory should be calculated, what qualifies as an approved alternative source, and which people should become responsible when the exception cannot be resolved automatically.
The supply chain organization may already possess all of that knowledge. If a frontier model can supply much of the implementation capability, the traditional translation from business expert to engineer begins to look less necessary.
There is, however, an important architectural requirement before this operating model becomes practical: the model needs an application environment in which it can actually work.
The Missing Layer: An Application Platform Designed for AI Implementation
Giving an LLM access to enterprise APIs does not make it a Forward-Deployed Engineer. An FDE does considerably more than generate code or invoke services. The engineer needs to understand the business model, create and modify application structures, implement workflows and rules, connect enterprise systems, configure user interactions, execute the application against real data, observe the resulting behavior and make corrections.
The distinction is important because enterprise software development is inherently iterative. An implementation team builds something, runs it, observes what happened, identifies what is wrong, modifies the implementation and runs it again. A model that can generate a specification or piece of code but cannot change the running application remains an assistant to the implementation team rather than an implementation capability in its own right.
For an LLM to perform more of the FDE function, the underlying application platform must expose the major elements of enterprise application development in a form the model can understand, manipulate and observe. This has several architectural implications.
A Machine-Readable Business and Semantic Model
The first requirement is that the structure of the business application must be visible to the model. Business objects, attributes, relationships, processes, activities, roles, permissions and integrations cannot exist exclusively inside compiled application code or undocumented configuration.
They need to be represented in machine-readable metadata that allows the model to understand the semantic structure of the application: what a Material is, how it relates to a Manufacturer Part, which processes operate on it, which systems provide or consume its information, who can modify it, and what should happen when its state changes.
This semantic model provides the model with something analogous to the understanding an experienced implementation engineer gradually develops while working with the customer.
The Ability to Modify the Running Application
Understanding the application is only the first step. The model must also be capable of changing it through governed tools.
It should be possible for the model to create or modify business objects, add attributes and relationships, construct workflow activities, implement deterministic rules, configure agents, change user interactions and modify integrations. Ideally, these changes should not require a conventional compile-build-deploy cycle for every iteration.
This changes the role of AI from generating instructions for an engineer to participating directly in implementation. The model can make a change, execute the resulting application, inspect what happened and refine the implementation.
Integration as a Native Platform Capability
Enterprise AI applications rarely operate on isolated information. They depend on ERP, PLM, CRM, planning, manufacturing and supplier systems as well as databases, documents and external services.
If each connection requires a separate integration project, much of the implementation burden simply moves from application development into integration engineering. Connections, mappings, transformations and service invocations therefore need to be part of the same environment available to the model.
This does not eliminate the need for enterprise integration architecture. It allows established integrations and integration patterns to become reusable building blocks rather than bespoke engineering projects for every new AI application.
A Unified Model for Software, Agents and Human Work
Enterprise processes should not be treated as collections of AI agents simply because AI is available. Much of enterprise work remains deterministic and is better implemented using conventional software.
When a fixed rule completely determines the outcome—copying records, calculating a value, retrieving approved documents or updating data—ordinary application logic is generally more predictable, economical and auditable.
AI becomes valuable when the activity requires interpretation or judgment: understanding an unstructured supplier notice, deciding whether imperfect manufacturer records represent the same product, identifying the correct technical document, or extracting attributes that can legitimately be supported by source material.
Human participation remains important where business accountability, consequential approval or unresolved ambiguity is involved.
The application platform therefore needs to orchestrate deterministic software, AI agents and people as parts of the same business process rather than forcing every activity through an LLM.
Security and Governance Below the Model
An AI capable of modifying enterprise applications and acting on enterprise data requires controls stronger than instructions contained in a prompt.
Permissions, approvals, segregation of duties and auditability need to be enforced by the underlying platform. If an agent may update certain technical attributes but cannot change pricing, that restriction should exist in the application security model. If an agent cannot approve its own work, the platform should make that action unavailable regardless of what the model attempts to do.
This separation between AI reasoning and platform-enforced authority is what makes it possible to give models meaningful capabilities without giving them unrestricted control.
From Forward-Deployed Engineers to Forward-Deployed Business Expertise
When these architectural elements are combined, a different implementation model becomes possible.
Instead of requiring an external or specialized engineering team to repeatedly translate business knowledge into software, the people who already possess that knowledge can work directly with the model inside a governed application platform. A component engineer can explain how manufacturer parts should be matched, and the model can construct and refine the matching process. A procurement specialist can describe how supplier exceptions should be handled, and the model can modify the workflow. A master-data specialist can explain classification requirements, and the model can implement the corresponding rules and agent behavior.
Internal IT continues to play a critical role by defining architecture, security, integration standards, production controls and governance. What changes is the amount of implementation work that must pass through a specialized engineering organization.
The frontier model supplies much of the implementation capacity. The application platform supplies the structure, runtime, integrations and guardrails. The business and IT teams supply the enterprise knowledge.
In effect, the people who understand the business become the Forward-Deployed Engineers without needing to become conventional software engineers.
A Practical Division of Work
This model also suggests a relatively simple framework for deciding how work should be implemented inside an enterprise AI application.
If an activity is completely determined by a rule, it should generally be implemented using conventional software. If the activity requires interpretation, judgment or reasoning over ambiguous information, it may be appropriate for an AI agent. If the activity carries material business accountability or requires consequential approval, an appropriate person should remain involved.
The resulting applications are therefore neither traditional workflow applications nor collections of autonomous agents. They are coordinated systems in which deterministic software, AI and people perform the types of work for which each is best suited.
Testing the Model on Real Enterprise Workflows
We have been testing this approach against real enterprise workflows to determine whether a model can move beyond assisting developers and participate meaningfully in building, running and correcting applications.
One example involves new-product creation from supplier information. A supplier quote containing new parts enters the process, an agent converts the unstructured information into structured line items, and a person reviews the result. Another agent classifies the parts using the company’s classification structure, after which software creates the appropriate technical-parameter template. An agent identifies relevant manufacturer documentation, a person confirms the appropriate source documents, software retrieves them, and another agent populates technical attributes that can be supported by the approved source material.
The more significant aspect of the test was not that AI could read the documents. The model also created agent definitions, scripts and supporting data structures, executed the process, inspected failures and modified the implementation when its initial assumptions proved incorrect.
In one instance, updates to a field were disappearing because the field had inadvertently been configured as calculated rather than stored. The model traced the observed behavior to the field definition and corrected the configuration. In another test involving an actual rack PDU, the workflow correctly extracted net and shipping weights together with their units while declining to populate a warranty value because the source represented the warranty in months and the application expected days.
That behavior illustrates an important characteristic of reliable enterprise AI. The objective is not to create a model that always produces an answer. The objective is to create an environment in which the model can implement useful business processes while recognizing when the available information is insufficient to proceed safely.
A Second Test: Product Change Notifications
The same approach was applied to Product Change Notifications, where supplier notices identify manufacturer parts that are changing or approaching end of life.
The process first converts the supplier notice into structured records. Conventional software identifies possible matches in the Approved Manufacturer List, an agent evaluates ambiguous candidates, and a person reviews the proposed matches. Once matches are confirmed, software promotes them and performs a where-used analysis to identify affected assemblies.
During testing, the agent accepted a legitimate manufacturer-part match despite a difference in corporate naming, rejected an Intel memory part whose number differed by only one character, and rejected another superficially similar component because a material technical specification was different.
The model also discovered that two later activities in the existing workflow referenced integrations that had never been configured, which meant those parts of the process had been quietly failing.
Again, the important result was not simply that an LLM could interpret a Product Change Notification. Models have been capable of reading and extracting information from documents for some time. The more consequential result was that the model could participate in building, executing, observing and correcting the enterprise application surrounding the document.
That is much closer to the work traditionally performed by a Forward-Deployed Engineer.
The Economic Implication May Be Larger Than the Technical One
Forward-Deployed Engineers are unlikely to disappear, nor should that be the objective. Complex architectures, unusual integrations, major transformations and genuinely new platform capabilities will continue to benefit from highly skilled engineers working closely with customers.
The more important question is whether forward-deployed engineering should remain the basic unit of implementation for every additional enterprise AI use case.
If every new application requires another group of engineers to rediscover the relevant business knowledge, translate it into technical specifications and implement another collection of data models, integrations, rules and workflows, enterprise AI risks reproducing a familiar problem from previous generations of enterprise software: implementation cost and complexity eventually become the constraint on adoption.
Frontier models create the possibility of a different economic model.
Business knowledge can be represented in a machine-readable application and semantic model. AI can be given controlled tools for modifying that model and constructing workflows, integrations, deterministic rules and agents. The model can execute what it builds, observe the resulting application state, integration responses, logs and failures, and iterate. Consequential decisions can remain behind platform-enforced human approvals. Most importantly, these capabilities can be placed directly in the hands of the people who already understand the business.
The objective is not to eliminate expertise. It is to reduce the repeated cost of translating expertise from the people who possess it to a separate group of people capable of implementing it.
That translation layer was unavoidable when enterprise software could only be built by specialized programmers. With frontier models and the right application architecture, it increasingly does not have to be.
A Test for the AI-Native Enterprise Application Platform
Organizations evaluating this model can reduce the architectural question to three practical tests.
First, can the AI understand and modify the application’s data model, semantic model, processes, rules, integrations and agents without requiring a conventional development and deployment cycle for every change?
Second, can the AI be given meaningful implementation and operational capabilities while permissions, approvals, segregation of duties and auditability remain independently enforced by the platform?
Third, can the AI observe the results of its own work—including application data, process state, integration responses, logs and failures—and use those observations to diagnose problems and iterate?
When all three conditions are present, the role of the Forward-Deployed Engineer begins to change.
The FDE does not necessarily disappear. The capability moves closer to where the business knowledge already resides. Supply chain analysts, component engineers, procurement specialists, master-data experts and internal IT teams can work directly with frontier models to turn their knowledge into functioning enterprise applications.
The model provides much of the engineering capacity. The application platform provides the semantic structure, execution environment and governance. The company’s own people provide the most difficult and valuable ingredient to acquire from outside the organization: a detailed understanding of how the business actually works.