An FDE engagement runs in three phases. Find the value: embed with your team, map workflows and data, and prioritize the highest-impact opportunities. Ship the value: design, build, and deploy a production AI system grounded in your data. Multiply the value: codify the patterns and transfer context so your team moves faster on everything that follows.
Hiring an embedded engineer is an act of trust, and trust is easier when you know exactly what you are buying.
This is a walk through what a forward deployed engagement actually looks like, week by week, from the first day of embedding to the point where your team can run without the FDE. No jargon, no black box.
If you are evaluating whether this model fits your organization, this is the inside view.
The short version
Key takeaways
- An FDE engagement follows three phases: Find, Ship, Multiply.
- Week one is embedding, not onboarding. The FDE is senior and starts inside your tools, data, and standups immediately.
- Find takes roughly the first few weeks: mapping workflows and data, then scoring opportunities for value and buildability.
- Ship is the build: production AI grounded in your data, with evaluation and governance built in, not bolted on.
- Multiply is the phase most models skip: codified patterns and a team that can carry the work forward.
The shape of a typical engagement, from the first day of embedding to ongoing transfer.
-
Week 1
Embed, not onboard
Access to your tools, codebase, data, standups, and the channels where the work actually happens.
-
Weeks 1 to 3
Find the value
Map the workflows that matter and the data that would feed them, then score candidate opportunities on value and buildability.
-
Weeks 3 to 10
Ship the value
Build and deploy the first production system, grounded in your real data, with evaluation and governance designed in from the start.
-
Ongoing
Multiply the value
Codify the patterns, transfer the context to your team, and shorten the path to production for the next initiative.
Week one: embedding, not onboarding
The first difference you notice with a forward deployed engineer is what does not happen. There is no multi-week ramp, no request for a fully written requirements document, no waiting for a statement of work to be amended before anyone looks at the real problem.
An FDE is senior by definition, and the engagement is designed for them to be useful inside the first week.
Embedding means exactly what it sounds like. The FDE gets access to your tools, your codebase, your data, and the channels where the work actually happens. They join the standups and the operations reviews. They start reading the runbooks and, more importantly, watching how the work is really done versus how it is documented.
This is not overhead before the value starts; it is the value starting. Every hour spent understanding your actual constraints is an hour that will not be wasted later building the wrong thing beautifully.
Find the value (roughly weeks 1 to 3)
The first phase answers a deceptively hard question: of all the places AI could help, which one should we build first?
Getting this wrong is expensive, because a poorly chosen first project burns budget and, worse, burns the organization's belief that AI can deliver. So the FDE treats opportunity selection as real work, not a workshop.
In practice that means mapping the workflows that matter and the data that would feed them, then scoring candidate opportunities on two axes at once: how much value would this create, and how buildable is it given the real state of your data and systems.
A high-value idea sitting on data that does not exist yet is not a first project; it is a second or third one, after a foundation is laid. The output of this phase is a scored opportunity map grounded in your business, plus a clear first build chosen because it is both worth doing and shippable soon.
HatchWorks AI uses structured tools to accelerate this, including an AI Opportunity Finder and an Agentic Opportunity Finder, so the prioritization is disciplined rather than a matter of whoever argues loudest in the room. The point of the instruments is the same as the point of embedding: replace opinion with evidence about your specific situation.
Ship the value (roughly weeks 3 to 10)
With a first build chosen, the FDE does the thing that separates this model from consulting: they build it, personally and to production quality. This is hands-on senior engineering, not oversight of someone else's implementation.
Two phrases carry most of the weight in this phase.
Grounded in your data
The system works against your real information through retrieval, integration, and the connective plumbing to your systems of record, rather than performing well on a curated demo set and falling over in reality.
Built in, not bolted on
The ways you will measure whether the system is working, and the controls that keep it safe and compliant, are part of the design from the start rather than a scramble before launch.
Concretely, the shape of the work depends on what the Find phase surfaced, but the through-line is the same.
If the first build is an agent that handles a multi-step operations workflow, shipping it means wiring it into the systems that hold the data, giving it deterministic guardrails and human checkpoints where judgment belongs, and building the evaluation harness that tells you whether it is actually getting the workflow right before it touches anything that matters.
If it is a retrieval system over institutional knowledge, shipping it means solving the unglamorous data and permissions problems that decide whether the answers are trustworthy, then measuring answer quality honestly rather than assuming it.
In every case the demo-to-production distance is where the real engineering lives, and it is the FDE's job to cover that distance rather than declare victory at the demo.
The work runs on Generative Driven Development, HatchWorks AI's methodology for AI-native delivery: human direction, AI acceleration, and accumulated context. In concrete terms, that combination is what lets a single senior builder cover ground that used to take a full team, without losing the judgment about what to build and why.
The deliverable at the end of this phase is not a slide about a system. It is a system, in production, tied to the workflow and the metric agreed on before the build began.
Multiply the value (ongoing)
This is the phase that most delivery models quietly skip, and it is the one that separates renting an outcome from buying a capability.
Shipping one system is good. Making your organization faster and more capable at shipping the next ten is the actual prize, and it does not happen by accident.
Codify
The patterns, prompts, architectures, and evaluation approaches that worked get documented as reusable assets rather than living in one person's memory.
Transfer
Your engineers and product people have been building alongside the FDE, so the context moves to them by osmosis and by design, not through a thrown-over-the-wall handoff.
Accelerate
Because the first system established patterns and proved the path, the second initiative starts far ahead of where the first one did.
This is also where the earlier problem of access versus adoption gets solved for real. The FDE has spent the engagement inside the actual workflow, so the system fits how people work, and the team that will live with it helped build it.
Adoption is not a launch-day hope; it has been accumulating the whole time.
What you should expect to see
A good engagement produces evidence, not just activity. Use this as a checklist for what a forward deployed engagement should leave in its wake.
What a client should be able to point to at the end of each phase of an FDE engagement.
| Phase | What you should be able to point to |
|---|---|
| Find | A scored opportunity map grounded in your workflows and data, and a first build chosen for both value and buildability |
| Ship | A system in production, integrated with your real data and systems, moving a metric you agreed on up front, with evaluation and governance in place |
| Multiply | Documented, reusable patterns; a team that has leveled up; and a measurably shorter path to production for the next initiative |
If an engagement cannot point to the Multiply row, you got a contractor, not a forward deployed engineer, no matter what the title on the invoice said.
See what Find, Ship, Multiply looks like on your workflow
Our Anthropic-certified Forward Deployed Engineers deploy Claude into your business and make it stick.
Explore FDE engagementsHow the working relationship actually feels
A fair question from anyone who has been burned by outside help: will this person understand our business, or will we spend months explaining it?
The embedded model is specifically designed to answer that in your favor. Because the FDE is inside your context, the usual translation tax between "the vendor" and "the team" largely disappears. They are in the same channels, looking at the same data, present for the same hallway conversations where the real requirements surface.
It should feel less like managing a supplier and more like a very senior colleague joining for a focused period with a clear mandate. They will ask direct questions, push back when a requested feature is a bad idea, and prioritize ruthlessly toward the production outcome.
That candor is a feature. The whole value of embedding is having someone close enough to the work to tell you the truth about it.
What the engagement needs from you
Embedding is a two-way arrangement, and the engagements that move fastest are the ones where the client sets a few things up front. None of it is heavy, and being honest about it early prevents the most common sources of drag.
Access, granted early
The single biggest accelerant is timely access to the tools, systems, and data the FDE needs. Access delays are the most common and most avoidable reason a fast start becomes a slow one.
A real business owner
Someone on your side who owns the problem and can make decisions about priorities and trade-offs. The FDE brings execution; they need a counterpart who can speak for the business.
Time with the people who do the work
The team members who actually run the target workflow are the most valuable source of truth in the engagement. Protecting a few hours of their time up front pays back many times over.
Permission to hear hard truths
Sometimes the most valuable early finding is that the data is not ready, or that the chosen use case is weaker than a different one. An engagement that can absorb that feedback outperforms one that cannot.
Set those up and the model works the way it is meant to. Withhold them and even a strong FDE is reduced to guessing, which is exactly the failure the embedded model exists to avoid.
When one FDE is not enough
A single embedded engineer is the right shape for a well-defined first system and a focused mandate. There is a point, though, where the work outgrows one person, and recognizing it early keeps momentum from stalling.
Parallel workstreams
Multiple validated opportunities need to move at once and cannot share a single person's calendar.
Product-scale scope
The build has grown into something that needs dedicated product, engineering, and QA coverage rather than one generalist.
Cross-team demand
Business units beyond the original pilot are asking for their own systems, and the pattern is worth industrializing.
When those signals appear, the engagement can scale from a single FDE to an Agentic AI Pod, a compact cross-functional team that owns a larger outcome, without losing the accumulated context.
That is the next rung of the engagement path, and it is a deliberate step up rather than a restart. The FDE model is the on-ramp; it is built to grow with the value it creates.
The practice behind the person
The reason a HatchWorks AI FDE can be useful in week one is that they are not starting from scratch on method. They arrive with Generative Driven Development as a shared way of working and a bench of more than 100 certified engineers behind them, trained across GenDD, Claude, data and ML, DevOps, and architecture.
When a problem exceeds one person's depth in a given area, the FDE can pull on that bench and on certified partnerships across Anthropic, Google Cloud, and Databricks.
That backing is what makes the three-phase model reliable rather than dependent on getting a single heroic individual. The engagement is designed to leave you with more capability than you started with, and the practice exists to guarantee it.
Frequently asked questions
What does a forward deployed engineer do day to day?
Early on, they embed and map: sitting inside your workflows, reading your data, and scoring opportunities. In the build phase, they write production code, handle integration, and stand up evaluation and governance. Throughout, they document patterns and work alongside your team so capability transfers.
How long is a typical engagement?
It varies with scope, but a first production system is typically measured in weeks, not quarters, followed by the ongoing Multiply work of transfer and acceleration. The model favors a fast first win over a long, open-ended build.
Do FDEs work on-site or remotely?
Embedding is about access and presence in the work, not a specific location. FDEs integrate into your tools, channels, and rhythms, which works both on-site and remotely depending on how your team operates.
How do FDEs transfer knowledge to our internal team?
By design, not by handoff. Your people build alongside the FDE, and the patterns, prompts, and architectures that work are documented as reusable assets. The goal is a team that moves faster after the engagement than before it.
Sources
- HatchWorks AI, Forward Deployed Engineers service overview and Find, Ship, Multiply operating model
- Matt Paige, "The Forward Deployed Engineer Is the Hottest Job in AI," Substack, 2026 (embedded delivery and adoption)
Embed, find your highest-value opportunity, ship it
HatchWorks AI is an Official Anthropic Claude Partner. Our Forward Deployed Engineers take it to production, then leave your team faster than they found it.
Start a conversation
