# Forward-deployed engineer: what it is and what it does on a real deployment > Forward deployed engineer meaning: where the role comes from and what it does on a deployment, connecting systems, encoding rules and setting controls. - Canonical: https://arkatai.com/en/what-is-a-forward-deployed-engineer/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: en - Published: 2026-07-19 --- A forward-deployed engineer (FDE) is an engineer who works inside the client's operation rather than from the provider's office: they connect a piece of software to the real data, rules and exceptions of one specific company and leave it running in production. They do not write a report or propose an architecture for someone else to build. They hand over a working capability. The role was popularised by software firms serving government and defence and by the model labs, and it has become central to agentic AI because it does the work you cannot buy off the shelf: fitting a shared platform into a company unlike any other. ## Where the role comes from and why it appears now The name comes from two worlds that shared a problem: delivering software that works on the client's ground, not in the lab. Software firms serving government and defence coined it when they found that their product only worked if someone sat next to the end user, understood their workflows and adapted it to an environment the vendor did not control. The model labs revived the role when they saw that a powerful model, on its own, does not solve a specific company's problem: someone has to connect it to that company's systems, data and rules before it produces useful work. It now appears inside ordinary companies because the technology has matured unevenly. Language models are already a utility you buy by API and swap when it suits you. Orchestration frameworks are on their way to becoming standard products. What still cannot be bought finished is the layer that touches your company: encoding your rules, your exceptions, your permissions and your integrations into agents that work with your operation. That specific work is what an FDE does, and it is the reason the role exists. I have set out why that layer stays hand-built in [the custom phase](/en/the-custom-phase/). ## What an FDE does on a real deployment The work of an FDE is concrete and can be described without metaphors. On a real deployment it comes down to four things. **Mapping the process.** They sit with whoever knows the operation and make explicit what usually lives in two or three people's heads: what comes in, which rules apply, which cases fall outside the script and what result is expected. Without that definition there is nothing you can automate with any guarantee. **Connecting the systems.** They integrate the platform with the ERP, email, CRM or whatever tools the work lives in, with specific permissions: what the agent may read, what it may write and what it is forbidden to touch. Integration is not a finishing detail. It is where most proofs of concept that worked in the demo quietly die. **Encoding rules and exceptions.** They translate company policy into executable behaviour, including the edge cases nobody had written down. This is where operating judgement becomes code: the happy path is not enough, because the real operation lives on its exceptions. **Setting controls and traces.** They define where the agent escalates to a person, which decisions require human approval and how every action is logged so it can be audited. That boundary is a business decision, and an important one, because it governs the real risk of the system. I cover the full framework in [AI agent governance](/en/ai-agent-governance/). When they finish, they do not leave a recommendation. They leave an operation running against real cases, measured and traceable. That sequence of mapping, deploying, operating and updating is the one I follow on every implementation, and I describe it in [the method](/en/method/). ## How it differs from a consultant A consultant delivers an analysis, a design or a plan, and the client decides who executes it afterwards. The value sits in the judgement and the document. Execution and maintenance fall outside the engagement or are contracted separately. When the project ends, the company has a recommendation and a pending decision: who builds and who operates what was proposed. An FDE delivers the working capability, not the blueprint. Their engagement ends not at the presentation but in production, with the process running on real systems. The practical difference shows in who is accountable for the result: the consultant is accountable for the quality of the analysis; the FDE, for the agent doing the work within the agreed controls. This is the same distinction that separates contracting an operation from contracting a project, which I analyse in [buy, build or contract the outcome](/en/buy-vs-build-enterprise-ai/) and, with a focus on the provider, in [in-house team, consultancy or forward-deployed engineers](/en/inhouse-consultancy-or-boutique/). ## How it differs from staff augmentation Nor is it a rented programmer. In staff augmentation you buy hours of an engineer who joins your structure, takes tasks from your backlog and works under your technical direction, and responsibility for what to build and how to maintain it stays with you. If you have nobody inside able to evaluate their architecture, you end up depending on the judgement of the first team that arrived. An FDE keeps the provider's responsibility for the deployment and works to make the shared platform solve your case, not to accumulate hours on a separate solution. Their aim is to incorporate what is specific to your operation into a system the provider keeps maintaining, and to move the patterns that repeat across clients back into the product core. They do not fill a vacancy or create a codebase you then have to operate. That is the difference between renting technical capacity and contracting a sustained result. ## Vendor or independent: not the same mandate The FDE title does not tell you who the engineer optimises for. An FDE working for a model maker has a mandate to take that maker's stack into production: adoption of its ecosystem is part of success. An independent FDE optimises your operation and preserves the ability to swap the model when cost, quality or data policy justifies it. This is not a matter of bad faith, but of incentives and architecture. It is a difference important enough to treat separately in [vendor FDE or independent](/en/vendor-fde-vs-independent/). This role is also the piece that makes possible the commercial model I call [service as software](/en/service-as-software/): the provider keeps the software and the FDE connects that system to your operation, so you buy the outcome and not a codebase to maintain. If you are deciding how to bring in agents without building a technical department, the starting point is [preparing your company for agents](/en/prepare-your-company-for-agents/), and the full map of the terrain, [AI agents for business](/en/ai-agents-for-business/). ## Frequently Asked Questions ### What does forward-deployed engineer mean? It is an engineer deployed on the client's ground rather than at the provider's office. Their job is to connect a piece of software to the real operation of a specific company (its data, rules, exceptions and systems) and leave it running in production, not to hand over a report or a design. ### Is a forward-deployed engineer the same as a consultant? No. A consultant delivers an analysis or a plan and leaves execution to the client, and is accountable for the quality of the recommendation. An FDE delivers the capability running in production and is accountable for the system doing the work within the agreed controls. ### Do I need a technical team to work with an FDE? Not an AI department. You need a process owner with business authority to decide rules, permissions and the cases that require human judgement, and to open access to the systems. The technical capacity comes from the FDE and the provider that maintains the platform. ### What does an FDE leave behind when a deployment ends? A working, measured operation: the process running on your systems, the rules and exceptions encoded, the controls and human escalation defined, and a trace of every decision so it can be audited. The operating architecture specific to your process is documented and yours.