In a previous article, we explored why most enterprise AI projects stall at proof of concept. Enhans identifies the root causes directly at the client site and resolves them from the ground up.
This article goes deeper into what happens on the ground. What does an FDE (Forward Deployed Engineer) actually do first when a client engagement begins? What must be defined before a project can move forward? And what does enterprise AI that actually executes in production look like?
What follows draws from the experiences of three Enhans FDEs, shared during our webinar (held in Korean). Their approach can be summarized in four words: Define First, Build Later.
FDEs Do Not Build What Was Asked
A manufacturing company came to Enhans with this request: "Build us an AI that automatically generates production schedules."
It sounds specific. They have production planning data, line status, and materials inventory. But an Enhans FDE does not go straight to development. They go on-site first, observe how work actually flows, interview the people doing it, and identify where the real bottlenecks repeat.
The interviews bring the problem into focus. What appeared to be a need for automated scheduling turned out to be something else. The real bottleneck was that every time materials were delayed, the schedule that had already been finalized fell apart. In that situation, building a scheduler first misses the point. What creates more impact is an AI that detects material delay risk early and alerts the right person before the disruption hits.
Receiving a request and defining a problem are not the same thing. FDEs work alongside clients to surface the actual problem worth solving. They operate one step before implementation.
What Must Be Defined at the Start of an AI Project
Once the problem is clear, the next step is aligning on project terms. Enhans FDEs define six things at the outset: the problem to solve, success criteria (KPI), how success will be measured, what the output looks like, the scope of automation, and what is explicitly out of scope.
This alignment matters because AI project success cannot be evaluated against something vague like "it works well." There must be a shared definition of which task, by what standard, and to what degree of automation counts as success. Equally important is specifying where human judgment is required, and what the project will not attempt.
Defining what will not be done is what keeps project scope from shifting. This is the starting point of an AI project that can be operationalized.
Constructing the Ontology Layer on Top of the Defined Problem
Once the problem is defined and the terms are agreed upon, the build begins. AgentOS projects at Enhans proceed through four stages. After problem definition and domain interpretation, construction of the ontology layer begins. The workflows and data surfaced through on-site interviews, along with the tacit knowledge inside the organization, are structured into an ontology layer.
The sequence works as follows. First, data from fragmented systems is connected into a single view. Then inconsistent formats, units, and terminology are normalized. When the same vendor appears under different names across different systems, those records are unified into a consistent representation. Finally, business meaning and relationships are applied to the data. That is what ontology is.
Ontology is built from four components. Objects: the business entities decisions are made about, such as materials, vendors, and production lines. Properties: attributes like expected arrival dates and delay history. Links: the meaningful connections between objects, such as the relationship between a material, its production line, and its vendor. Knowledge: the tacit rules and exceptions from the field, for example, the fact that a specific vendor consistently runs two days late during a particular season.
With this structure in place, AI moves beyond retrieving similar documents. It can assess what to examine in a real business situation and determine what risks to surface.
AI Agents Execute on Top of the Ontology
AI agents that carry out actual work are built on top of the ontology layer. Dashboards and views are built alongside them, so operators can review the agent's outputs and make final decisions. AI executes. Humans decide.
After the build, accuracy and utility are validated against real business data. As the system runs, the agent's judgments are reviewed. Where improvement is needed, the ontology and the agents are updated together. Once validation is complete, repetitive tasks are automated and the system transitions into live operations.
Why FDE Is Decisive for Enterprise AI That Actually Executes
Return to the manufacturing company from earlier. When the material delay problem has been precisely defined and the relevant data and operational knowledge have been structured into an ontology, what the agent does changes entirely.
Every morning, the agent reviews incoming materials and delay history. When it detects a high risk of delay for a specific production line, it surfaces an alert to the relevant operator. The operator reviews the evidence in the dashboard and makes the final call: take immediate action, or continue monitoring.
AI does not replace people in this structure. It delivers the right information and actionable signals at the right time, so people can make faster and more accurate decisions.
The AI agents Enhans FDEs build do not stop at demo. They are validated against real business operations, built on the organizational knowledge assets that FDEs construct for each client, and transitioned into live workflows.
Define First, Build Later. That is what it takes to deploy AI within a real enterprise environment.
in solving your problems with Enhans!
We'll contact you shortly!