ai:engineers
Forward-deployed AI engineers for agencies: what an embed actually ships.
By Loan Laux · October 19, 2026 · 8 min read
Forward-deployed AI engineers embed with your agency's team, work in your actual repo and stack, and ship production AI workflows instead of recommendations. The difference from an advisor is the deliverable: an advisor leaves a roadmap you still have to staff, while an embedded engineer leaves running software and a team that knows how to operate it. The difference from a dev shop is where the work happens: inside your tools and your constraints, not behind a spec.
This is the model we sell as forward-deployed engineering, so read what follows with that in mind. The useful test is not whether we like the model; it's whether the week-by-week below describes work you could point to in your own delivery six weeks after an engagement starts.
Where the title comes from.
The role originated at Palantir, which found that shipping software to defense and intelligence customers didn't work unless it also shipped the engineers to make it run inside those environments. The name borrows from the military, where forward-deployed means stationed in the field rather than back at base. The title has since spread across the industry: OpenAI and Anthropic both hire forward-deployed engineers today, under that exact name, to embed with enterprise customers.
Agencies should care about the model, not the pedigree. The insight that made the role work at Palantir applies directly to agency AI projects: the hard part is rarely the model or the tool, it's making either one work inside a specific team's systems, data, and habits. That work can't be done from a distance, and a growing pile of stalled agency AI pilots is the evidence.
What forward-deployed AI engineers actually do.
The embed starts inside your environment, not a discovery deck. The engineer sits with your delivery team (on-site or remote), reads the repo, watches how work moves through your PM tool, and picks the highest-leverage thing to build first. That selection step matters: the best first build is usually not the one the kickoff meeting voted for, it's the one the tickets and the handoffs reveal.
Then they build it. Custom agents, workflow automations, model integrations: written in your stack, wired into the tools you already pay for, and shipped to production rather than left as a recommendation. Your team pairs on the work as it happens, which is what makes the last step (handover) possible instead of theoretical.
What an embed ships that an advisor cannot.
None of these items can be produced from outside your environment, which is the point of the role:
:
Code in your repo
Pull requests in your codebase, through your review process and your CI. Not a reference implementation in a sandbox you then have to port.
:
Workflows wired to your tools
The meeting-to-ticket pipeline writes real tickets in your PM tool; the reporting draft pulls from your actual analytics. Integrations, not mockups of integrations.
:
Evals against your real cases
A test set built from your projects' actual inputs, run on every change, so quality is measured rather than vibes-checked.
:
Guardrails that fit your clients
Permissions, review checkpoints, and logging designed around what your contracts and your clients' data actually require.
:
A handover your team can hold
Runbooks, documented decisions, and a team that paired on the build. The system survives the engineer leaving, which is the test of the whole engagement.
How an engagement runs, step by step.
01:
Start inside the environment
Access to the repo, the PM tool, and the docs, then a short stretch shadowing real delivery. The goal is to find where hours actually leak, not to confirm the brief.
02:
Pick the first build
One workflow, scoped to weeks, with a clear baseline cost in hours. High frequency and an existing human review step beat ambition every time.
03:
Ship a thin working version early
End to end and in front of real work within the first couple of weeks, even if narrow. A thin slice in production teaches more than a wide design document.
04:
Harden against real cases
Build the eval set from actual project inputs, meet the edge cases, add the guardrails. This is where a demo becomes a system, and it's most of the work.
05:
Pair through the build
Your developers and leads work alongside the engineer the whole way. Knowledge transfer during the build, not a training session bolted on after it.
06:
Hand over and step back
Runbooks written, ownership named, exit criteria met. A defined end is part of the model; an embed that never leaves is just expensive staffing.
Advisor, dev shop, or embedded engineer.
All three models are legitimate; they just buy different things. The honest comparison:
| Model | What you get | Where it falls short |
|---|---|---|
| Advisor or consultant | A roadmap, tool recommendations, and workshops | You still have to staff the build, and momentum dies in that gap |
| Dev shop | Software built to a spec, delivered at the end | The spec meets your real workflows for the first time at delivery |
| Forward-deployed engineer | Production workflows built inside your stack, with your team pairing on them | Senior-engineer rates, and it needs real access to earn them |
When you don't need one.
An embed is the expensive tier, and most agency AI work doesn't start there. Honest reasons to hold off:
- The workflow is coverable by configuration. Agent features in tools you already pay for, or a configured automation platform, handle most agency use cases. Our build, buy, or configure breakdown draws that line in detail; escalate to custom only when a configured version has actually fallen short.
- You can't name an internal owner. Whatever gets built needs someone on your side who runs it after handover. No owner means the system rots regardless of who built it.
- The need is one-off. A single automation with stable inputs is a project for a contractor or a platform, not an embed.
- You haven't found the right workflow yet. If you don't know which workflow to fix first, start with an AI workflow audit; it's cheaper than discovering the answer at embedded rates.
Do it yourself, or bring us in.
The in-house version of this is hiring an AI-capable engineer and giving them the mandate to work inside delivery rather than off to the side. That's the right call when AI work is a durable line of your business and the hiring market cooperates. The failure mode is the lonely hire: one engineer, no second opinion, and a backlog of feature requests before the first workflow is stable. Our post on getting a pilot to production covers why that first stretch is where most internal efforts stall.
We run the embedded model as forward-deployed engineering: an engineer in your repo and your tools, the first workflow shipped and hardened, and a handover your team can hold. When you'd rather not own the maintenance either, managed operations keeps what was built running as models and tools change.
Frequently asked questions.
What is a forward-deployed AI engineer?
An engineer who embeds with your team and builds AI systems inside your environment: your repo, your tools, your constraints. The role originated at Palantir and is now a standard title at the major AI labs. The defining trait is the deliverable: production software your team can run, not recommendations.
How is this different from hiring an AI engineer full-time?
A full-time hire is the better deal when you have sustained, year-round AI build work and can win the hiring market for it. An embed fits when you need the first systems shipped and the capability transferred without carrying a permanent senior salary, or when the honest volume of AI work is a few months a year, not fifty-two weeks.
How long does an engagement last?
Long enough to ship and hand over the first workflow or two, which is typically a couple of months rather than a year. Be suspicious of open-ended embeds: a defined exit is what separates this model from body-shopping, and the handover only gets tested when the engineer actually leaves.
Can we resell this to our clients?
Yes. Agencies put embedded engineers behind their own front line and sell the resulting AI work under their own brand. Our white-label AI services playbook covers the delivery models, the pricing rules, and what to check in a partner before you promise a client anything.
What access does the engineer actually need?
Repo access, the PM and communication tools your team lives in, and a named decision-maker who can approve scope. Treat it like any senior contractor: least-privilege credentials, your security review, NDAs, and IP assignment in writing. An embed that can work without any of that isn't really embedded.