ai and machine learning · forward deployed engineering
Our engineers sit with your claims team until the AI workflow runs in production.
The pilot ran on a spreadsheet export. Production is the real policy system, its permissions, and the people who'll be using it on Monday. Our forward deployed engineers join your business team and build on your systems and data, and once they leave your own engineers run it.
A forward deployed engineer is a software engineer who joins a business team and ships working systems on that team's real data and applications.
Ours build production AI workflows, such as document intake, case triage or agent-assisted service. Each workflow comes with an evaluation suite and least-privilege access to your systems. We document the handover so your team can run and change it after we leave.
you probably need this if
The AI pilot demoed well on exported data but nobody has connected it to the real system.
The platform team builds AI features, but nobody has sat with the people who'll use them.
Every new AI use case waits months in a queue for a central team.
Workflow map with real examples and edge cases gathered from the team
Evaluation set with expected outcomes and a grading rubric
Production integration code in your repository
+ 3 more documents
who does it
Forward deployed AI engineerAI integration engineer (APIs and service identities)Evaluation engineer for LLM workflows
AWS Certified Generative AI Developer - Professional
Microsoft Certified: Azure AI Apps and Agents Developer Associate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Forward Deployed Engineers, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · forward deployed engineers3 open
openThe AI pilot demoed well on exported data but nobody has connected it to the real system.
recurringThe platform team builds AI features, but nobody has sat with the people who'll use them.
blockedEvery new AI use case waits months in a queue for a central team.
exposure
Embedded discovery with the…Building against real systemsEvaluation before launchAccess controls for models and…Production operations from day oneHandover to your engineers
startrehearsehandover
Embed and pick one workflow
Build the eval set first
Ship to a small group
Hand over and move on
we are here
ready to hand over
Each submission now arrives in the policy system as a draft for an assistant to check…
Answers come with citations and only use content the agent is allowed to open.
Workflow map with real examples and edge cases gathered from the team
Evaluation set with expected outcomes and a grading rubric
chapter 01 · where it hurts
Why teams reach out
The AI pilot demoed well on exported data but nobody has connected it to the real system.
The platform team builds AI features, but nobody has sat with the people who'll use them.
Every new AI use case waits months in a queue for a central team.
chapter 02 · what we change
How we solve it
Embedded discovery with the people doing the work
Building against real systems
Evaluation before launch
Access controls for models and agents
Production operations from day one
Handover to your engineers
chapter 03 · how it runs
Our approach
Embed and pick one workflow
Build the eval set first
Ship to a small group
Hand over and move on
chapter 04 · where you end up
What changes
Each submission now arrives in the policy system as a draft for an assistant to check and submit.
Answers come with citations and only use content the agent is allowed to open.
Workflow map with real examples and edge cases gathered from the team
Evaluation set with expected outcomes and a grading rubric
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We sit with the team whose work changes, watch the current process, collect real examples and the edge cases people handle from memory, and agree a narrow first workflow with a measurable definition of done.
Integrations with your CRM, policy, claims, ERP or ticketing systems through their APIs, with the same identity and network controls as any other production service. No shadow copies of data on a laptop.
A test set built from real cases and graded by your subject matter experts runs every time a prompt, model or retrieval setting changes. Until it clears the business owner's bar, nothing ships.
We gave each workflow its own service identity and scoped permissions, made retrieval respect the user's document access, and added approval steps for anything that writes to a system of record.
Tracing, cost and latency dashboards, error alerts and a fallback path to the manual process. When something breaks at 2 a.m., the runbook says who gets paged and what to switch off.
Your developers pair with ours during the build. They own the repository and run the last releases themselves, and we finish with code, evals, runbooks and a named internal owner.
capability 01 / 06in production
Embedded discovery with the people doing the work
We sit with the team whose work changes, watch the current process, collect real examples and the edge cases people handle from memory, and agree a narrow first workflow with a measurable definition of done.
Integrations with your CRM, policy, claims, ERP or ticketing systems through their APIs, with the same identity and network controls as any other production service. No shadow copies of data on a laptop.
A test set built from real cases and graded by your subject matter experts runs every time a prompt, model or retrieval setting changes. Until it clears the business owner's bar, nothing ships.
We gave each workflow its own service identity and scoped permissions, made retrieval respect the user's document access, and added approval steps for anything that writes to a system of record.
Tracing, cost and latency dashboards, error alerts and a fallback path to the manual process. When something breaks at 2 a.m., the runbook says who gets paged and what to switch off.
Your developers pair with ours during the build. They own the repository and run the last releases themselves, and we finish with code, evals, runbooks and a named internal owner.
We pieced these together from Forward Deployed Engineers situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Commercial insurance submissions keyed by hand from broker emails
composite · not a client story
Beforethe situation
Underwriting assistants are retyping broker submission emails and attachments into the policy admin system by hand. There was a pilot that extracted fields from sample PDFs. It never ran against the live mailbox or the policy system's API.
What we dothe work
Sit with the assistants for two weeks and collect a few hundred real submissions with the fields they actually key. Build the eval set from those, connect the mailbox and the policy API through a scoped service account, and route low-confidence extractions to a human queue.
Afterwhere you end up
Each submission now arrives in the policy system as a draft for an assistant to check and submit. Nobody retypes any more. They work the exceptions queue, and the eval set catches regressions before changes ship.
case file 02
Service agents copying answers between five knowledge bases
composite · not a client story
Beforethe situation
Every call means searching several knowledge bases and old ticket notes. A central team built a chatbot for the agents. They don't trust it. It answers from documents they can't see and cites nothing.
What we dothe work
Embed with a team lead and log the questions agents actually ask. Rebuild retrieval so results follow each agent's document permissions, require citations in every answer, and grade a sample of real calls with senior agents each week.
Afterwhere you end up
Answers come with citations and only use content the agent is allowed to open. Senior agents do the grading. The quality bar belongs to the floor, not to IT.
Where a forward deployed engineer sits between the business and your systems
Our engineer sits with the business team, turning real cases into an eval set and a workflow. The workflow calls a model through your AI platform. It gets to systems of record through a scoped service identity, and traces and eval results flow back to the owners.
01 · Business team
Claims or service teamreal cases · edge cases → Forward deployed engineer · examples
Business owneracceptance bar · sign-off → Eval set · grade
Eval setgraded real cases → AI workflow · gate releases
AI workflowintake · triage · draft → Model platform · inference→ Service identity · token→ Traces and dashboards · traces
03 · Model and identity
Model platformBedrock · Foundry · Vertex AI
Service identityscoped OAuth client → CRM · scoped API calls→ Ticketing · create task
04 · Systems of record
CRMSalesforce
TicketingServiceNow
Traces and dashboardscost · latency · errors → Business owner · weekly review
Read the diagram as text
Claims or service team → Forward deployed engineer: examples
Forward deployed engineer → Eval set: build
Business owner → Eval set: grade
Eval set → AI workflow: gate releases
AI workflow → Model platform: inference
AI workflow → Service identity: token
Service identity → CRM: scoped API calls
Service identity → Ticketing: create task
AI workflow → Traces and dashboards: traces
Traces and dashboards → Business owner: weekly review
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Embed and pick one workflow
Two to three weeks with the business team to map the work, gather examples and pick the first workflow by volume, risk and how easy it is to check the output.
step 02
Build the eval set first
Real cases with expected outcomes, reviewed by the business owner. This becomes the acceptance test and the regression suite.
step 03
Ship to a small group
Integrate with production under scoped access. Roll out to a few users and review every output by hand, then widen the rollout as long as eval results and user feedback hold up.
step 04
Hand over and move on
Your engineers run the releases. The runbook is tested, then we either leave or start the next workflow with your team in the lead.
you keep
What you're left with
We write these for your Forward Deployed Engineers setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Workflow map with real examples and edge cases gathered from the team
yours to keep
document02
Evaluation set with expected outcomes and a grading rubric
yours to keep
code03
Production integration code in your repository
yours to keep
design04
Service identity and permission design for each workflow
yours to keep
runbook05
Monitoring dashboards, alerts and an incident runbook
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
AI integration engineer (APIs and service identities)
Evaluation engineer for LLM workflows
Retrieval and search engineer
Delivery lead embedded with the business team
due diligence · forward deployed engineers
Questions to ask any partner, including us.
Put these to anyone bidding on your Forward Deployed Engineers work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who on your side will sit with our business team, and for how long?
The forward deployed model only works if engineers spend real time with users. If discovery is a one-day workshop, you are buying a build team, not forward deployment.
Q2
What will the eval set look like, and who grades it?
Without graded real cases, nobody can tell whether the workflow is good enough to ship or whether a model change broke it. The business, not the vendor, should set the bar.
Q3
What identity will the workflow use to call our systems, and with what scopes?
Prototypes often run on an admin key. Production needs a dedicated identity with least privilege, reviewed like any other service account.
Q4
What does handover include, and when do our engineers start shipping releases?
Make sure your own team ships a release before the engagement ends. Otherwise every change after that goes back to the partner.
Q5
How will you decide a workflow isn't worth building?
You want a partner willing to kill a weak use case early. Ask what evidence would make them say stop.
01How is a forward deployed engineer different from a consultant or a contractor?
A consultant often recommends and a contractor builds to a spec. A forward deployed engineer works out the spec with the business team and then builds and ships it, sitting with the users while they do. The job is measured on a working system in production.
02Where did the forward deployed model come from?
Palantir, mostly. Its Forward Deployed Software Engineers work directly with customers to understand and solve their biggest problems. Frontier AI labs, OpenAI and Anthropic included, now hire forward deployed engineers as well, to put their models into production with customers.
03How long does an engagement last?
The first workflow usually takes a few months from embedding to handover, depending on how many systems it touches, how clean the data is and how fast access gets approved. Access approvals are often the longest wait, so we request them in week one.
04Which model or AI platform do you use?
That's decided by your contracts, data residency rules and security review. We work with Claude, OpenAI models, Amazon Bedrock, Microsoft Foundry and Google Vertex AI. Run the eval set first and you can compare them on your own cases before committing.
05Do the engineers need to be onsite?
For discovery, it helps a lot to be in the room with the people doing the work. Build work can be nearshore or offshore once the workflow and the evals are agreed. We plan the split at the start.
06What if the first workflow turns out not to be worth automating?
Then we say so early, usually during the eval-set work, when it becomes clear the output can't be checked reliably or the volume is too low. Stopping a weak workflow in week three costs less than shipping it.
related
Often paired with
Projects on Forward Deployed Engineers usually end up touching one of these, so they're worth a look.
