Hire forward-deployed engineers when work your team does by hand every day could be done by an AI agent, and you want that agent built on your own tools and handed to your own people. A forward-deployed engineer joins your team, learns the work from the people who do it, and builds the agent where it will run. Before you hire, ask any provider how they will find the first workflow, where the agent will run, what happens to your data, and what you keep at the end.
What a forward-deployed engineer does
A forward-deployed engineer builds software inside the customer’s team instead of from a specification handed over at the start. The term comes from Palantir, which called its engineers who worked at customer sites “forward deployed”. AI companies such as OpenAI and Anthropic now use it for engineers who build inside a customer’s own systems, and we use it in the same sense.
For AI agents, the role combines three jobs:
- Learning the work. They join your channels and standups, watch the work being done, and write it down step by step before deciding what to build.
- Building on your tools. The agent connects to the systems your team already uses. It reads what your people read and writes where they write.
- Handing it over. The engagement has an end date, and your team should be able to run the agent, change it and check its results once the engineers have gone.
The building is the part most people picture. The learning and the handing over are what make the role forward-deployed. An agent built from a specification follows the work as someone described it. An agent built by someone who has watched the work also handles what nobody thought to describe, like the supplier who sends two PDFs instead of one, or the field that is always left blank.
Whether you hire or bring in a service, look for an engineer who:
- writes software that runs in production, including the dull parts: connecting to old systems, handling bad inputs and writing tests;
- is at ease with people who are not engineers, since much of the first two weeks is listening to an accounts clerk or a dispatcher explain their day;
- tests an agent against real examples and can say, with numbers, how often it gets a case right;
- knows when to leave a step with a person, and can explain why to the people involved;
- writes clearly, because the handover is mostly writing.
An engagement, week by week
Ours have a fixed shape. One or two of our engineers join your team for one workflow, and the handover is planned from the first week.
-
Weeks 1–2
Sit with the team
You get a written map and a ranked shortlist
-
Weeks 3–6
Build the first agent, on your tools
You get a working agent your team has tried, with frequent demos on the way
-
Weeks 7–8
Run it beside your people
You get before-and-after numbers
-
Then
Hand over, or take on the next workflow
You get 30 days of fixes after handover
Your team runs it, with 30 days of fixes after handover.
The first two weeks decide what gets built. Our engineers watch the work, map it, time it and rank the steps with your team; choosing the first workflow for an AI agent explains how. Weeks 3 to 6 build the first agent in your environment. In weeks 7 and 8 it does the work with a person checking, measured against the numbers from the start. Then your team runs it, or the engineers move to the next workflow on the list.
Three ways to bring the role in
There are three common routes to a forward-deployed engineer, and each suits a different kind of company.
Hire your own
You can hire forward-deployed engineers onto your own payroll. The knowledge stays with you, and the engineer is still there after the first agent goes live, to look after it and build the next one.
The harder part is that the role is new, so the job description is hard to write and the interview harder to run. Hiring takes time. And one engineer on their own has nobody to review their work unless you already have engineers who know how agents are built and tested. This route suits companies that expect to run many agents for years and have an engineering lead to manage the role.
Bring in a service
A service puts engineers into your team for a set engagement. You can usually start sooner than a hire, the engineers have a team behind them, and their work is reviewed before it reaches you.
In exchange, the people who built the agent leave at the end, so the handover has to be real, with your team running the agent before the engineers go. And you depend on the provider’s standards, which is what the questions further down are for. This route suits companies that want the first agent working before deciding whether to build the skill in-house. It is the route we offer.
Use the platform vendor’s engineers
Some AI and software vendors have forward-deployed engineers of their own, who help customers build on that vendor’s platform. They know the product in depth and have a direct line to the people who make it.
The catch is that they build on their own platform, so the agent is tied to it, and their brief is to make that platform work for you rather than to weigh it against others. This route suits companies that have already chosen the platform and want the most from it.
Forward-deployed engineers, an extended dev team or consultants
If you are bringing in a service, forward-deployed engineers are one of three ways to put outside people on a piece of work. They differ most in what you have at the end.
| Question | Forward-deployed engineers | Extended dev team | Consultants |
|---|---|---|---|
| Where they work | Inside your team, on your tools | Inside your engineering team | Beside your team, in workshops and reviews |
| What you get | A working agent on one workflow, and the map behind it | Features shipped on your roadmap | A recommendation and a plan |
| How long | Eight weeks for the first workflow | Ongoing, month by month | A study of agreed length |
| Who runs it after | Your team, with 30 days of fixes after handover | Your team, with our engineers still in it | Your team, or whoever builds it |
| Suits | Work people do by hand every day | A roadmap bigger than your team | A decision before anything is built |
If the work is a product roadmap that has outgrown your team, an extended dev team fits better: engineers who join your product and your process for as long as the roadmap needs them. If the question is whether to build anything at all, or which of several directions to take, a consultant’s study answers it before money goes into a build. If the work is people checking, matching, chasing and re-keying by hand every day, that is what forward-deployed engineers are for.
We would also point you away from forward-deployed engineers when no one on your side can own the outcome, or when the systems involved cannot be reached, even through a sandbox. Both can be fixed, and both are worth fixing before anyone starts.
Questions to ask any provider
Ask these of anyone you are considering, us included. Good answers are specific, and you should be able to get them in writing.
Before anything is built
- How will you find the first workflow? Look for a provider who watches the work and maps it, rather than one who starts from a list of ideas.
- What will you measure, and against what? There should be numbers from before the agent (how many cases, how long each takes, how often a person steps in) to compare the results with.
- What do we get from discovery, and is it ours if we stop there?
Your data
- Where will the agent run: in our cloud, in yours, or on our own servers? Can you work with the one our setup requires?
- Which AI models will it use, and on what terms? Is our code or data ever used to train a model?
- Who will have access to our systems and data, and when does that access end?
- Will you sign our NDA, and a data processing agreement (DPA) if we need one?
The build
- Who reviews the code before it reaches our repository?
- Which hours do your engineers work, and when do they overlap with our team?
- How often will we see it working, and how will you report progress?
After the build
- What do we keep: the code, the prompts, the tests, the examples it is checked against?
- How does the handover work, and what support is there after it?
- How is the price set, and at what point do we see it?
Warning signs
Some answers deserve a second look:
- A price for the whole build before anyone has watched the work.
- No starting numbers, so no way to tell afterwards whether the agent helped.
- Vague answers on data: where the agent runs, which models it uses, whether they train on your data.
- Access with no end date, or no answer on what happens to your data when someone leaves the project.
- The code or the prompts kept in the provider’s accounts instead of yours.
- No plan for the cases the agent cannot settle. An agent needs a queue where a person picks up what it could not resolve, with the evidence in front of them.
- A handover that is a document delivered at the end, rather than something your team has already done with the engineers beside it.
Most of these are gaps rather than bad faith, and a gap is easier to close before the work starts than after it.
How we answer these
Our answers, in the same order as the questions. The full detail is on our forward-deployed engineering page.
- Finding the workflow: one or two engineers sit with your team for the first two weeks and give you a written map of the workflow and a ranked shortlist of what to automate first.
- Measuring: the same two weeks record the numbers to measure against, and weeks 7 and 8 give you the before-and-after.
- Discovery: the map, the shortlist, the numbers, and a fixed plan and price for the pilot are yours to keep, whether or not you go ahead.
- Where it runs: in your cloud, in ours or on your own servers, whichever your setup requires.
- Models: mainly Anthropic’s Claude models, and Claude Code for writing software, on business terms that exclude training on your data. We never use your code or data to train AI models.
- Access: only the engineers working on your project. When someone leaves the project, their access ends, and our employment terms require them to delete your data.
- Agreements: we sign your NDA or send ours, and a DPA if you need one. The your data section sets all of this out.
- Review: a senior engineer reviews everything our engineers ship.
- Hours: our engineers work remotely, on Indian hours, with an overlap with your working day for the standup and handover.
- Progress: frequent demos while the agent is built, and a progress update every week.
- What you keep: the code, in your repository, under your accounts; the prompts, the tests and the set of examples the agent is checked against; a runbook your team has used, not just read; and the numbers, where you started and where you are now.
- After handover: 30 days of fixes, then an optional monthly arrangement for fixes and changes, or your team takes it from there.
- Price: the pilot has a fixed price, agreed after discovery. If the work continues, it becomes a monthly engagement. A partner sends you a written proposal with the price.
Engagements usually start within 2–3 weeks of a signed proposal. A partner onboards every new client and is a call away after that. How we work covers the rest of what working with us is like, and forward-deployed engineering sits within our wider AI engineering work.
If you have a workflow in mind, tell us about it, and a partner will tell you honestly whether forward-deployed engineers are the right fit.