Key takeaways
- Agents fail between the specification and the floor: the real exceptions, the source systems’ actual behavior, the approvals that exist in practice. FDE closes the gap by closing the distance.
- FDE for agents is near-mandatory because agent correctness is environment-specific — there is no generic agent to ship.
- The model’s endgame is handover: documentation, runbooks, trained owners. An engagement that ends in dependency has failed its own definition.
- The economics: FDE front-loads the discovery that remote delivery re-pays for later as rework, escapes, and stalled pilots.
The gap that eats agent projects
Every experienced AI buyer recognizes the failure arc. The pilot demos well. The build against the specification proceeds. Then production touches reality: the exception the workflow docs call “rare” happens hourly; the core system’s API behaves differently from its documentation; the approval that policy describes turns out to be an email thread and a shrug; the “standard” case the vendor built against is the 60% case, and the other 40% is where the cost lives. The agent was built correctly against a world that does not exist.
This gap — between the documented process and the operational one — is where agent projects die, and it is not a documentation problem. The operational process is tacit: it lives in the muscle memory of the analyst who knows which vendor’s PDF lies, which queue overflows on Mondays, and which exception the policy manual gets wrong. No specification transmits that. Two things do: living inside it, or paying for the discovery in rework.
What forward-deployed engineering actually is
FDE is the first option, institutionalized: the engineers who build the agent sit with the workflow’s owner and its practitioners, in the customer’s environment, against the customer’s systems. The implications are concrete:
Discovery is continuous, not a phase. The “requirements” keep arriving — at the desk, in the queue, during the daily exception triage — and the build absorbs them the same day. The remote alternative books them into a change-request queue and pays in latency.
The build targets the real system. The agent is developed against the customer’s actual error codes, document quirks, data shapes and latency — not a sandbox abstraction. The “works in the demo, breaks in production” class of defect mostly cannot form, because demo and production share an address.
Governance is designed with the people who own it. The agent-human split is negotiated with the analysts who will live behind the gates — which is how you get gates people actually use, approval interfaces shaped to the real decision, and an authority ladder calibrated to the team’s genuine trust curve. Governance designed remotely gets rubber-stamped; governance designed on the floor gets operated.
The knowledge transfers by construction. The customer’s team watches the build, asks the questions, learns the control plane while it is being configured against their workflow. Handover is a process, not an event — and the documentation describes the system they watched being built.
Why this matters more for agents than for software generally
For conventional software, environment-specific defects are real but bounded: the interface is defined, the behaviors are deterministic, and the gap is mostly integration details. For agents, the environment is the product surface: what the agent decides depends on the customer’s documents, rules, data quality and risk appetite. Two banks with identical “invoice-matching agent” requirements have different products, because their exception distributions differ. A generic agent shipped across that boundary is a guess about the customer’s world — and guesses at the consequential-action layer are exactly what governance review exists to catch. Building inside the environment converts the guess into observation.
FDE versus consulting — and versus body-shopping
The distinction that matters is the ending. Consulting engagements classically end in a deliverable about the system — recommendations, architectures, a roadmap — with the build remaining on the customer. FDE engagements end in the system itself, running and governed, with the customer’s team in ownership: documentation, runbooks, trained operators, the registry entries, the drill results, and a runway of support that shrinks by design. The opposite failure — FDE as body-shopping, warm bodies parked indefinitely with knowledge never transferring — is the same destination as consulting, reached slower. The discipline that separates them is writing the handover criteria into the engagement’s definition and measuring against them from week one.
How Moring runs it
Every Moring engagement is forward-deployed: our engineers work in your environment, on your cloud, with your team beside them — the discovery is the floor, the governance is designed with your risk owners, and the ending is your team operating the system with us on call, not in the loop. The how it works page shows the four phases and the 8-week shape; why Moring describes the model from the engineer’s side; and the workflow diagnostic is the zero-commitment starting point.
Frequently asked questions
What is forward-deployed engineering in AI?
The engineers who build the AI system work inside the customer's environment and workflow context — at the desk of the person whose queue the agent will change, against the systems the agent will touch — rather than building from a specification handed across a boundary.
Why does AI agent delivery need forward-deployed engineering?
Agent behavior depends on the customer's specific systems, data shapes, exception patterns and approval culture. Those live in the environment, not in any document. Teams building remotely discover the gap as rework; forward-deployed teams never create it.
How is FDE different from hiring a consultancy?
Consulting produces recommendations; FDE ships the running, governed system — and the engagement ends in handover: documentation, runbooks, trained owners, the customer's team operating what was built. Dependency is the failure condition, not the business model.
Governing Autonomous AI Agents in Production
Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.
About the author
Balaji Nagaraj KumarChief AI Officer, Moring AI, Moring AISweden
Leads platform and delivery engineering at Moring AI, turning each engagement into a substrate the customer’s own team operates at handoff. His background spans developer-platform leadership at Volvo Cars and engineering at CERN. He writes about governance for agents that take actions in production systems.
LinkedIn profile