How to choose a forward deployed
engineering partner.
Pick the partner by what they leave behind, who runs the work after launch, and how they define done. A demo, a headcount of engineers and a famous logo do not answer those questions.
This is a buyer checklist, not a ranked list. For what forward deployed engineering is, start with what is forward deployed engineering. For who offers it, see the map of forward deployed AI companies.
Why this checklist
Forward deployed is now a crowded label.
Palantir pioneered the role. In 2026, OpenAI, AWS, Microsoft and Anthropic each launched a forward deployed business, and consultancies built practices around the term. The label now covers very different things: engineers who deploy one vendor’s product, teams that bring their own platform, and large programmes that redesign work at scale. The forward deployed engineer vs consultant note covers the role differences. This page is about how to evaluate any vendor that claims the model.
Use the six criteria below on every shortlist, including us. Where an answer applies to Ortelian, we say so at the end.
01 · What they leave behind
What runs after the engineers leave?
Ask what the work runs on when the engagement ends. If the answer is only code the visiting engineers wrote, you are buying staff augmentation with a better title. Prefer a platform someone hosts and maintains, with the logic written down where your team can see it, so the work does not depend on people who have already moved on.
- Platform or project code
Is there a maintained platform under the agents and workflows, or only custom code for this engagement?
- What you can export
Can you take the data, the model of your business, the agent setup and the history with you?
- Who operates it
Who hosts, patches and monitors the platform after launch: you, the vendor, or a third party?
02 · Who runs after launch
Who runs the work once it is live?
Some teams aim to leave you self-sufficient. Some keep operating it. Both can be fine. Know which you are buying before you start, and what happens to the platform in each case.
- Your team takes over
What training, workshops and written runbooks do they get during the build, not only at the end?
- The vendor keeps running it
What is in the ongoing fee, who is on call, and how do you still own the decisions?
- Either path is open
Can you switch from vendor-run to self-run later without rebuilding?
03 · Standard and evaluations
How is done defined before anyone builds?
A standard agreed on real examples of your work, before the build starts, is what keeps the engagement honest. Quality, cost, time and human effort should all have a number. Evaluations should keep running after launch, not only in a pilot week.
- Real examples first
Do they score the system on your actual cases, or on generic demos?
- Written before build
Is the pass bar agreed in writing before the first two-week cycle?
- Still running later
Do evaluations keep watching the live work, so drift shows up?
04 · Model choice
Whose models do they build on, and can you change?
Lab and cloud vendor teams usually build on their own stack. That is fine if you have already chosen that stack. If you have not, ask whether models are tested against your work, and whether you can move providers without rebuilding the agents.
05 · Data location and control
Where is the data, and who can act on it?
Ask where the platform is hosted, where model calls run, who can see your data, and which actions wait for a person’s approval. For EU buyers, walk the full list on what to check in an EU-hosted AI agent platform, including jurisdiction and exit.
- Hosting and inference
Where do records sit, and where does each model call run?
- Access and approvals
What can each agent read and change, and what needs a person?
- Training and retention
Is your data excluded from training in the contract, and do model providers retain prompts?
06 · Internal owner
Do you have someone inside who can own it?
Forward deployed teams need an internal owner, time with the people who do the work, and agreed access to the systems it depends on. Without that, even a strong team stalls. If nobody inside can make calls and clear blockers, fix that before you hire anyone.
Red flags
Signs to dig deeper before you sign.
- Done equals a demo
If success is a polished demo rather than work in daily use against a written standard, keep asking.
- No answer on who runs it
If they cannot say who operates the system six months later, you will find out the hard way.
- One model only, no test
A team tied to one provider without testing on your examples is selling their stack, not solving your work.
- No internal owner required
A vendor that says they can do it without anyone inside owning the work is selling a fantasy.
- Vague on data and exit
Hosting region, sub-processors and export should be clear before the first agent runs.
Where Ortelian fits
Where Ortelian fits, and where it may not.
Ortelian is a platform plus a forward deployed team for mid-market and enterprise knowledge work. We work on site not because our product needs it, but because your company does. The audit takes about two weeks. We agree a standard on real examples, then build in two-week cycles. After launch, your team runs it or we keep running it for you. Either way, we host and operate the platform in the EU. Inside an engagement, your own agents can use it through scoped tools, and it can plug into tools your team already uses. Detail is on how we work and on what an AI-native deployment partner does.
Where it may not fit: Ortelian is not a self-service product. Access comes with an engagement. We are not an enterprise search product, and we are not a defence or intelligence platform. Ortelian, Inc. is a Delaware corporation, so US jurisdiction questions apply to us as they do to any US-incorporated vendor. If you need a vendor that only deploys one lab’s models inside that lab’s programme, or a multi-year transformation across dozens of teams with a global systems integrator, a different shortlist is the better place to start.
For a mid-market comparison with the company that pioneered the role, see Ortelian vs Palantir.
Questions
Questions buyers ask when choosing a partner.
What should I ask a forward deployed engineering partner?
Ask what runs after they leave, who operates it after launch, how done is defined on your real examples, whose models they use, where data and model calls sit, and who inside your company will own the work.
How is this different from hiring consultants?
Consultants often deliver a recommendation and leave the build to someone else. A forward deployed partner builds on site and is measured on whether the work changed. Some consultancies now run forward deployed practices, so ask who builds and who stays.
Should I pick a lab’s deployment company or an independent team?
Pick a lab or cloud vendor team if you have already standardised on that stack and want engineers who deepen it. Pick a platform-plus-team vendor if you want a maintained platform, model choice tested on your work, and a clear path for who runs it after launch.
What does Ortelian leave behind?
A platform we host and operate in the EU, with agents and workflows built for your work, evaluations that keep running, and a choice for your team to run it or for us to keep running it. You own your data and world model and can export both.
Is this a ranked list of vendors?
No. It is a checklist you can use on any vendor. For a map of who offers forward deployed AI in 2026, see the sister note on forward deployed AI companies.
Bring one piece of work and your shortlist.
On a call, we walk this checklist for your case, including where Ortelian fits and where it does not.
