A Forward Deployed Engineer (FDE) is not a consultant who happens to write code. An FDE is an engineer with deep subject matter expertise in a specific product or platform who deploys into the customer’s environment to solve the customer’s problem using that expertise. They write code in the customer’s systems, under the customer’s governance, against the customer’s data.
What distinguishes an FDE from an embedded consultant is the feedback loop: every problem solved in a customer engagement, every gap discovered, every pattern that works feeds directly back into the product or platform development lifecycle. The FDE does not just consume the platform. The FDE improves it. The customer engagement makes the product better for the next customer.
The question every FDE team faces on a modernization engagement is, where do you start when the system spans code, data, integration, and infrastructure, and no single person can draw the complete map?
You start with Setup.
Phase 1: Setup (days 1-5)
Before any agent runs or any system is analyzed, the FDE team locks in the scaffolding that makes everything downstream repeatable. This is where the FDE’s expertise matters first: the team already knows what agent operating model works with their tooling, what quality gates produce reliable outputs, and what specification formats the downstream tools consume. A consultant would research this. The FDE team configures it from experience.
The deliverables:
A problem statement with success metrics and baselines (what does “done” look like, and how will we measure it)
Non-functional requirements and target architectural patterns
Architecture Decision Record (ADR) templates and specification pack formats (the structured artifacts that will carry decisions from advisory into execution)
An agent operating model: which models are permitted, which data sources agents may cite, where human approval is mandatory, quality scoring criteria
At least one reference agent dry-run on a known system
FDE teams deploy in days, not months. That speed is only possible because the standards, templates, and governance are agreed before the first investigation agent runs. Without Setup, every decision made during investigation becomes a point of re-litigation during execution.
Exit gate: the customer’s execution teams have accepted the spec pack format, the ADR template is agreed, quality gates for agent outputs are defined, and phase transition criteria are documented.
Phase 2: Investigation (days 5-15)
The FDE team designs investigation agents for the specific system. This is where deep expertise becomes the differentiator. The FDE knows the AWS tooling well enough to select the right investigation approach for the system type, knows which agent patterns have worked on similar systems in prior engagements, and knows how to connect the tooling to the customer’s specific data sources and APIs. A generic analysis tool treats every system the same. The FDE designs investigation that fits both the tooling and the target.
A 2-5 day bootstrap assessment establishes three things: which dimension of the system carries the most complexity (code, data, integration, or infrastructure), which system type pattern the target fits (monolithic database, coupled enterprise applications, or hybrid IT/OT), and what data sources are accessible for agent tooling.
Then the agents are built. For a monolithic database: schema ownership agents, business logic extraction agents, data flow agents, integration topology agents, infrastructure boundary agents. For coupled enterprise apps: behavior observation agents, vendor documentation agents, contract mapping agents. For IT/OT hybrids: connectivity and durability agents, protocol translation agents, data semantics agents.
These agent designs compound. An FDE team that has investigated the same system type before starts from validated patterns and output schemas refined across prior engagements.
The agents run against the target system under the customer’s governance and security posture. The investigation outputs are structured findings that feed directly into advisory.
This is also where the feedback loop operates. When investigation reveals a gap in the platform’s capabilities, a data source the tooling cannot reach, an integration pattern the existing agent designs do not cover, that gap feeds back to the product team. The next version of the platform addresses it. The customer gets their findings. The platform gets better.
In practitioner experience, the cost difference between programs that invest in structured discovery and those that skip it can be substantial. In one engagement, a program that skipped investigation saved $150K on discovery and spent an extra $890K reaching the same destination as a comparable program that invested. The specific numbers vary, but the pattern is consistent: the FDE team’s investigation phase converts unknown unknowns into known risks before a single architectural decision is made.
Phase 3: Advisory (days 10-20, overlapping)
The FDE team does not hand the customer a recommendation deck. The investigation found the technical reality. But the architecture has to survive the organization, not just the technology. Deadlines, vendor commitments, regulatory requirements, team restructures, these are constraints that no investigation agent can discover. They live partly in customer documents and partly in the customer’s head. Advisory is the process that brings the technical findings and the business reality together.
It works as a structured loop. Agents present their findings to the customer and the FDE team in a working session. The customer responds with the constraints the investigation could not discover: this vendor contract expires in six months, that team is being restructured, this regulatory deadline is non-negotiable. The agents revise the architecture to account for those constraints. The customer reviews the revision and challenges it: does this actually work given what we know? If new constraints surface, the loop runs again. When decisions stabilize, they lock as Architecture Decision Records (ADRs).
The ADRs are not merely documentation. They are binding execution constraints. Each captures: the decision, the reasoning, the constraints that shaped it, the alternatives rejected, and the conditions for revisiting. ADRs are the primary artifact for the architecture review board that governs the program.
The FDE team runs this loop until decisions stabilize. Three rounds is typical for complex integration decisions. Each round is triggered by a constraint the agent could not have known without human injection.
Phase 4: Design-to-Spec (days 15-25)
Design agents translate ADRs into structured design specifications. The specifications are precise enough to drive code generation without requiring further design decisions.
The FDE team produces specifications in the format that the customer’s chosen AI coding tool can consume. Different tools accept different input structures. The specification format is tailored to the tool; the specification itself is the durable artifact.
Specification formats also compound across engagements. Formats already tested against execution tools in prior programs require fewer validation cycles.
A human architect on the FDE team validates every specification against the ADRs and investigation findings before code generation begins. This step is non-negotiable.
Phase 5: Execution (days 20+)
Execution is the commodity layer. The FDE team uses whatever tools fit the workload: code transformation (AWS Transform, Kiro, OpenRewrite), data migration (AWS DMS, Striim), infrastructure migration (AWS Application Migration Service, VMware HCX), schema conversion (AWS SCT).
The tools are interchangeable within their category. We have already seen this: in November 2025, AWS closed five modernization tools to new customers, recommending customers transition to using AWS Transform. The design knowledge survived. The tooling did not. A 2026 Gartner report predicts 70% of AI agents developed before 2027 will require substantial rebuilding. The FDE team invests in the design layer, not tool mastery.
Exit gates: formal Go/No-Go decision record based on the success metrics defined in Setup, operational readiness evidence (monitoring, alerting, runbooks, rollback procedures), and change management approval workflows.
When execution hits a tool limitation, a migration pattern the tool handles poorly, a specification format the tool cannot consume cleanly, that limitation feeds back to the tool team. The FDE does not just use the tools. The FDE makes the tools better for the next engagement.
What the Customer Keeps
The FDE engagement is designed to produce customer self-sufficiency. When the team leaves, the customer has deployed production systems, a knowledge graph connecting architecture decisions to their reasoning, ADRs that governance boards can enforce, runbooks for operation, and trained internal champions who participated in every phase. The specification templates and agent patterns remain configured for their specific system type.
What Feeds Back
Every FDE engagement produces more than a customer outcome. The investigation patterns that worked, the agent designs that fit, the advisory loops that stabilized decisions, the edge cases that broke assumptions: all of this feeds back into the tools, platform and methodology. The patterns compound. Each engagement refines investigation agents, enriches advisory methodology, and hardens specification formats. The customer gets a production system. The platform gets better. The next engagement of the same system type starts from a higher baseline. That is the compounding effect, and it is what allows strong FDE teams to accelerate delivery across multiple customer engagements.
The five phases described here are the AI-Accelerated Modernization Framework. The full framework, including detailed agent design patterns for the three system types described above (monolithic databases, coupled enterprise applications, and hybrid IT/OT), the advisory interrogation loop, and the evidence base, is available at awslabs.dev/ai-modernization.
The accelerator is not the AI. The accelerator is the design of the AI agents.
About the Authors
Erik Farr is the global Director of Solution Architecture for Consulting Partners at Amazon Web Services, where he leads the Partner-Led FDE motion and is focused on growing and scaling consulting partners worldwide. He is the author of Cloud Native Architectures and Architecting Cloud Native Applications, both precursors to how the cloud has evolved to use AI and how FDEs will be deployed long into the future.
Aaron Sempf is APJ Principal Partner Solutions Architect, Frontier AI at Amazon Web Services, specializing in autonomous systems architecture, enterprise modernization, and AI agent design. He is the author of the AI-Accelerated Modernization Framework and the Architecting Autonomy series on constitutional governance for autonomous systems.