Ask any enterprise technology leader how many AI pilots are running in their organization and you will usually get a confident number. Ask how many of those pilots are embedded in a live operating workflow, governed, monitored, and measured against a business outcome, and the answer gets quieter.
This is the defining problem of enterprise AI right now. The models are capable. The tooling is plentiful. The demos are impressive. Yet most organizations have a collection of sales copilots, document Q&A tools, analytics bots and workflow experiments that never became part of how the business actually runs.
The gap is rarely about the technology. It is about the last mile: connecting an agent to real systems, real data, real policies, and real people, inside an environment the vendor has never seen. That last mile is where the forward-deployed engineer (FDE) earns their place.
In this post, we look at what the FDE model is, why it suits agentic AI so well, and how an embedded engineering approach can get your first governed agent into production in about one quarter, and then hand it over to your own team.
Why pilots stall: the last-mile problem
Most AI pilots do not fail because the model was wrong. They stall because the real enterprise looks nothing like the sandbox.
In a sandbox, the data is clean, access is open, and nobody asks who approved the output. In production:
Data sits in dozens of systems. ERPs, CRMs, data lakes, document archives, and IoT streams each have their own definitions, owners and quality problems.
Workflows cross departments. A single process may touch finance, operations, compliance and customer service, each with different priorities.
Decisions carry consequences. A wrong answer in a demo is an anecdote. A wrong answer in a KYC check, a claims decision or a supplier risk score is a regulatory and reputational event.
Governance varies by team. Access rules, audit expectations and security reviews differ across the organization, so every pilot either reinvents them or skips them.
This is the difference between building an AI demo and running a business on AI. A demo needs a model and a prompt. A production agent needs context, orchestration, access control, observability, cost management, and an owner.
Traditional software delivery handles this badly for AI. A vendor ships a platform, the customer’s team attempts to configure it, a services partner is brought in, requirements documents are written, and months pass. Meanwhile the use case drifts and sponsors lose patience. The pilot becomes a case study that never reaches production.
What a forward-deployed engineer actually is
The forward-deployed engineer model, which popularized the idea of engineers embedded directly with customers rather than working at arm’s length from headquarters. It has since spread across enterprise software and AI.
A useful way to understand the role is by contrast:
A product engineer builds one capability that many customers will use.
A forward-deployed engineer works on one customer’s problem across many capabilities.
An FDE is not a salesperson with a technical background, and not a contractor who works through a ticket queue. An FDE is a hands-on engineer who sits inside the customer’s context, learns the systems and the politics, builds against live data, and takes responsibility for whether the thing actually works in production.
In practice, that means an FDE typically:
- 1.
Clarifies the real problem. Customers rarely arrive with a perfect specification. The FDE helps turn “we want an AI assistant” into a specific workflow with a measurable outcome.
- 2.
Builds integrations. Connecting the agent to source systems, identity providers, and approval workflows is usually where the hardest work lives.
- 3.
Configures and tunes the platform for the customer’s data, policies and domain vocabulary.
- 4.
Deploys inside the customer’s environment, respecting its security perimeter and compliance posture.
- 5.
Feeds learning back. What the FDE discovers in the field improves the product and the next deployment.
For enterprise AI, this combination of engineering depth and proximity to the business is exactly what is missing from most pilots.
Why agentic AI needs embedded engineers more than traditional software
You could ask whether FDEs are needed for every kind of software. They are not. But agentic AI has characteristics that make embedding particularly valuable.
Agents pursue outcomes, not steps
Traditional automation follows steps somebody wrote in advance. Agentic systems pursue a business outcome and work out the steps themselves. That is a different thing to buy and a different thing to govern. Someone has to define the goal, the boundaries, the escalation points and the definition of “done.” That work needs deep business context and engineering skill at the same time.
Agents act inside real systems
An agent that only answers questions is relatively low-risk. An agent that reads from your ERP, writes to your CRM, drafts a settlement or flags a compliance exception is acting inside systems of record. Permissions, audit trails and human approval gates have to be designed correctly from the start, not bolted on after a security review.
Context is the real differentiator
Two companies can use the same underlying model and get very different results. The difference is context: how well the agent understands the organization’s data, definitions, processes and constraints. Building that context layer is custom, domain-specific work, and rarely something a generic platform can do alone.
The first agent sets the pattern
The first production agent becomes the template for everything that follows: how agents are registered, approved, monitored, costed and retired. If it is built without governance, the next ten will be too. Getting the first one right, with the right guardrails, creates a repeatable path instead of a one-off.
The embedded model: scope, deploy, prove, hand over
A well-run FDE engagement follows a clear shape. It starts with scoping, moves to deployment inside the customer’s environment, reaches production under governance, and ends with a handover.
Stage 1: Strategists scope the workflow
The engagement begins with strategy, not code. The aim is to scope one domain, one outcome, one quarter.
That constraint is deliberate. Enterprise AI programs fail most often by trying to do everything: a company-wide assistant, ten use cases, a transformation roadmap. Narrowing to a single workflow with a single measurable outcome forces clarity on:
Which process is being reimagined, rather than merely automated
Who owns it, and who approves the agent’s actions
Which systems and data sources it depends on
What “success” looks like in numbers the business already tracks
This is also where the principle “don’t bolt AI onto yesterday’s workflow, reimagine the workflow with AI” matters most. If you simply automate a clumsy process, you get a faster clumsy process. Good scoping asks what the workflow would look like if intent, intelligence and execution were designed together.
Stage 2: Engineers deploy inside your perimeter
Next, the forward-deployed engineers stand up the platform inside the customer’s boundary, whether that is a public cloud account, a private VPC, or an air-gapped environment on the customer’s own hardware. For regulated industries, this matters enormously. Many financial services, healthcare and public-sector organizations cannot send sensitive data to an external environment, and a solution that only works in someone else’s cloud is a non-starter.
Deploying inside the perimeter, rather than asking the perimeter to bend, shortens security reviews and builds trust with risk and compliance teams early.
Stage 3: The first workflow reaches production, governed from day one
The first workflow goes live under governance, not after it. From the first day, the organization can see what the agent is doing, what it is costing, and who can stop it.
Stage 4: The handover
The final step is as important as the first. The deployment is handed over, either to your internal team or to a partner who owns the depth. An FDE engagement that creates permanent dependence on the vendor has failed. The goal is capability transfer: your people understand how the agent is built, governed and improved, and can extend it without starting again.
What gets built in the first quarter
A production-grade agent is more than a model with a prompt. It rests on several layers, and an FDE engagement typically starts with the layer where the pain is greatest. Think of them as five capabilities: sense, evaluate, remember, act and assure.
Evaluate: reasoning across everything you already own
If the first workflow depends on answers drawn from many systems, the data and reasoning layer is often the starting point. It connects ERPs, CRMs, data lakes, documents and IoT streams through a broad set of connectors into one semantic layer, then reasons across them.
The strongest approaches combine three retrieval methods in a single chain: SQL for structured precision, vector search for the meaning of documents, and graph traversal for relationships. Each answer should carry an audit trail showing how it was reached, which matters most in regulated industries where “the model said so” is never enough.
This layer also handles master data. Rules written in plain language can build governed, continuously improving “golden records,” and clean data should not be a prerequisite to start. Waiting for a perfect data foundation is one of the most common reasons AI programs stall.
Act: building, orchestrating and monitoring agents
The agent runtime covers the lifecycle from build to production:
Build: No-code and pro-code agent creation in one interface, with access to multiple language models and a standard way to connect tools.
Orchestrate: A visual canvas for sequential and parallel agent workflows, with support for agent-to-agent protocols so agents from different vendors can work together.
Register: A catalogue of every agent, with promotion gates from development through QA and staging to production.
Monitor: Cost attribution by agent, model and provider, a full audit log of every model call, runtime guardrails for content and personal data, and an instant kill switch.
For the first production agent, this is where the FDE builds, registers and monitors the workflow, so the agent is a managed asset from day one.
Remember: memory with a human in the loop
An agent that starts cold every time never gets better. But a flat vector store is not an enterprise memory, because enterprises are not flat. A better design uses a hierarchy that mirrors the real structure of the organization, so that one region’s local exception cannot leak into another region’s answers.
The most important design principle is that nothing becomes shared company knowledge until a person approves it. A reviewer should see the exact text that would be written to shared memory, and be able to approve, edit or reject it. This lets the agent improve over time without the risk of unreviewed knowledge spreading across the organization.
Sense: capturing what never reaches a system of record
Some of the most valuable business knowledge is never typed into a database: what was said in a customer meeting, what a competitor just announced, what a field team noticed. A signal layer can capture meetings, market feeds, publications and filings, then produce insights that are confidence-scored and linked back to their source. That evidence trail is what separates useful intelligence from a black box.
Assure: governance across every layer
Governance works best as part of the architecture, not as a separate module. One effective pattern is scope-based access control, organized around three nested scopes that mirror how enterprises already operate: system, organization and project.
The key rule is that two types of resource flow in opposite directions. Assets such as agents, knowledge bases and tools flow up, so governance teams can see everything built beneath them. Infrastructure such as approved models, environments and providers flows down, so teams cannot reach for capability their parent has not granted. A single person might be a viewer at the system level, an admin in one organization, and a contributor on one project.
Alongside access control, look for alignment with recognized standards such as ISO/IEC 42001 for AI management systems and the EU AI Act, plus PII detection and redaction, and per-customer data sovereignty.
Governance from day one is not optional
Many organizations treat governance as something to add once an AI solution proves valuable. In practice, that is backwards. Retrofitting access control, audit and cost visibility onto agents already in production is slow, politically difficult and risky.
Embedding governance into the first deployment gives you three advantages.
You can answer the regulator’s questions. For every action, you can say what the agent did, with what data, under whose authority, and with what result.
You can control cost. Agent costs can rise quickly as usage grows. A single record of what an agent did and what it cost, with attribution by agent, model and provider, stops a successful pilot from turning into an unpredictable bill.
You can scale with confidence. When the second, third and tenth agents follow the same registration, promotion and monitoring path, adding agents becomes an operational routine rather than a new risk review each time.
Accelerating from use case to production
The promise of the FDE model is going from use case to production AI in weeks, not months. Speed in enterprise AI comes from removing the waits between steps, not from rushing the steps themselves:
Waiting for data access shrinks when connectors and a semantic layer already exist.
Waiting for security approval shrinks when deployment happens inside your perimeter, with governance built in.
Waiting for engineering capacity shrinks when experienced engineers are embedded and already know the platform.
Waiting for stakeholder alignment shrinks when strategists have scoped one outcome with one owner.
Any vendor’s published speed-up figures should be treated as directional. Validate them against your own environment during scoping, and agree on baselines before you start.
A sample one-quarter timeline
Every engagement differs, but a quarter-long first deployment might look like this.
Weeks 1 to 2: Scope and align
Choose one workflow, one outcome and one accountable owner. Map the systems involved, the data needed, and the approval points. Agree what success looks like in business terms such as cycle time, error rate, cost per case, or revenue influenced. Confirm the deployment perimeter and compliance requirements.
Weeks 3 to 6: Deploy and connect
Stand up the platform inside your environment. Connect the priority data sources. Establish access scopes so the right people see the right things. Build the first version of the agent and its tools. Set up guardrails and the human approval steps.
Weeks 7 to 10: Test, tune and prove
Run the agent against real cases in a controlled setting. Compare its output with the current process. Tune retrieval, prompts, rules and escalation thresholds. Bring in compliance and risk reviewers early so their feedback shapes the build.
Weeks 11 to 13: Go live and hand over
Promote the agent through registry gates to production. Monitor cost, behavior and quality in the control tower. Document what was built and train your team to operate it. Agree who owns the next workflow.
The aim is not just to deliver one agent. It is to leave behind a working pattern and a team that knows how to repeat it.
Choosing the right first workflow
The choice of the first workflow can make or break the engagement. A strong candidate usually has these traits:
It is painful and measurable. Teams already track the cost, delay or error rate of the current process.
It crosses systems. The value comes from reasoning across data that is currently siloed.
It has a clear owner. Someone has the authority and motivation to change the process.
It has bounded risk. Consequences are significant enough to matter, yet a human approval step can contain mistakes while trust builds.
It is repeatable. The pattern can apply to adjacent processes later.
Some examples of what such workflows can look like by industry:
Banking, financial services and insurance: onboarding and KYC document triage before a reviewer opens them, pre-validation of regulatory submissions to prevent next-day rework, and settlement checks where an agent proposes and a human approves.
Manufacturing: multi-tier supplier risk detection, OEE optimization with cross-system root cause analysis, and predictive maintenance cross-referenced with history.
Healthcare and life sciences: readmission risk scoring with cross-system context, revenue cycle optimization and billing anomaly detection, and reduced manual compliance work.
A good rule of thumb: if you cannot describe the workflow’s success metric in one sentence, it is not ready to be the first one.
From one agent to an operating model: the AI Center of Excellence
A successful first agent raises a new question: what happens next? Without a plan, every business unit starts its own initiatives, with its own tools, definitions and controls. The fragmentation returns.
This is where an AI Center of Excellence (CoE) comes in, covering platform, talent and operating model for enterprise AI. An effective CoE does not centralize all AI work. It sets the standards that let many teams build safely:
A shared platform, so teams do not reinvent infrastructure, connectors or governance.
Approved models and tools, curated at the enterprise level and made available to business units and projects within clear boundaries.
Reusable assets, such as agents, knowledge bases and tools that flow up so the organization can see and reuse them.
Skills and roles, including the people who will carry on after the FDEs hand over.
Value tracking, so that investment is tied to outcomes rather than activity.
The FDE engagement and the CoE reinforce each other. The FDE proves a pattern in the field, and the CoE turns that pattern into a repeatable practice across the organization.
Common pitfalls to avoid
Even with strong engineers, certain mistakes recur in embedded AI engagements.
Scoping too broadly. Trying to solve three workflows in a quarter usually delivers none. Hold the line on one domain and one outcome.
Treating governance as a phase. If guardrails, access scopes and monitoring come at the end, they will slow go-live or be dropped.
Skipping the business owner. An agent without an accountable business owner becomes an IT project that nobody adopts.
Waiting for perfect data. Data will never be perfect. Use tooling that can master and improve data as you go.
Ignoring the handover. If your team does not take part in the build, they will not be able to run it. Pair your engineers with the FDEs from the first week.
Measuring activity, not outcomes. Number of prompts or users is not a business result. Track the metric that was agreed during scoping.
How to measure success
At the end of the first quarter, you should be able to answer a handful of plain questions.
- 1.
Is the agent in production? Not in a demo environment, but running on real cases with real consequences.
- 2.
Is it governed? Do you know what it did, what it cost, and who can stop it?
- 3.
Did the business metric move? Cycle time, accuracy, cost per case or revenue impact, compared with the baseline set at the start.
- 4.
Can your team operate it? Could they extend it or build the next agent without starting from scratch?
- 5.
Is there a next workflow? A good first deployment creates demand rather than closing the topic.
If the answer to all five is yes, the engagement did more than deliver an agent. It built an enterprise capability.
Is the FDE model right for you?
The embedded approach is a strong fit if:
You have run several AI pilots without a clear path to production.
Your environment is complex, regulated, or restricted, such as VPC-only or air-gapped.
Your internal team has strong domain knowledge but limited experience deploying and governing agents.
You want a repeatable pattern, not a single bespoke project.
It may be less suited if you have no clear business owner, no defined use case, or no willingness to involve your own people in the work. Embedding engineers cannot substitute for business ownership.
Frequently asked questions
How is an FDE different from a consulting engagement?
A traditional consulting engagement often produces recommendations and documentation. An FDE builds and deploys working software inside your environment, and stays accountable for whether it runs in production.
Do we have to adopt a full platform at once?
No. The strongest approach is modular: start with the single capability where the pain is greatest, whether that is data reasoning, agent operations, memory or signal capture, and add layers as the business case grows.
Can this run in a regulated or restricted environment?
Yes, provided the platform supports deployment in your cloud, your VPC, or fully air-gapped on your own hardware. Confirm this early in scoping.
What happens after the first quarter?
The deployment is handed over to your team, or to a partner who owns the depth. Many organizations then use a Center of Excellence to extend the pattern to further workflows.
How do we control agent costs?
Through observability and control: cost attribution by agent, model and provider, and an audit log of every model call.
The takeaway
Enterprise AI does not suffer from a lack of ideas or models. It suffers from the distance between a promising demo and a governed, measurable, production workflow. Closing that distance takes engineers who understand both the technology and the business, working inside your environment, under real governance, with a clear plan to hand over.
The forward-deployed engineer model is built for exactly that. Scope one workflow. Deploy inside your perimeter. Put it in production under governance. Hand it over. Then repeat.
If you have one question your data cannot currently answer, or one agent estate nobody can see, that is a good place to start. Pick that single workflow, name its owner, define its metric, and give yourself one quarter.