The FDE pod versus the consulting engagement: a buyer's contract checklist for healthcare AI.

Two years ago, Forward Deployed Engineer was a Palantir-internal term most healthcare buyers had not heard. In 2026 it is on the home page of consulting firms, agencies, AI startups, and offshore dev shops, alongside words like embedded, partnership, and pod. The label is doing a lot of work.

That is not necessarily bad. The shape of the model (engineers on the vendor payroll, sitting with the customer, building production systems instead of decks) is the right answer for most healthcare AI work that goes past a pilot. But buyers cannot read intent off a website. They have to read it off a contract.

This piece is the checklist. Ten questions, every one of which should be answered in writing, in the MSA or the SOW, before a healthcare organization signs anything that calls itself FDE, embedded, or co-build.

The fastest tell. Real FDE pods are W-2 employees of the vendor, with equity or long-tenure incentives. Sub-contracted engineers (1099s, offshore vendors, partner network resources) rotate, do not carry institutional context across customers, and are incentivized by utilization, not outcome.

Ask for the engineer's LinkedIn and tenure. Ask if they are on the vendor's payroll. Ask if their compensation is tied to your account's outcome. If any answer is fuzzy, the model is staff-aug with a relabel.

On-site time is the difference between a system that fits the workflow and one that fits the spec. Palantir's working norm is roughly one quarter of FDE time on customer site. Commure runs closer to half. Cara's commitment depends on engagement, but always includes scheduled on-site discovery, scheduled on-site reviews, and travel availability when something breaks.

Pin the answer in the SOW. How many days per month on-site, where, and who pays travel. A vendor that resists committing to on-site time is signaling that the work will happen on Zoom, which is the right answer for some integrations and the wrong answer for any work that touches a clinical or front-desk workflow.

Most consulting failures look identical: the engagement ends, the team leaves, the customer inherits an artifact nobody at the customer can run, extend, or debug. Healthcare makes this worse because the artifact often touches PHI, payer integrations, or clinical workflows where stalled maintenance is a safety event.

The contract should specify: who maintains the system after go-live, what the SLA is, what the rate is for additional work, what triggers escalation, and what the runbook looks like. If the answer is we will scope a separate engagement, the engagement is structured to require a second engagement. That is not partnership.

This is the single most-skipped clause in healthcare AI contracts and the single most expensive one to discover later. The default in many SaaS-style agreements is that the vendor retains all IP, with the customer receiving a license to use. That is fine for commodity tools. It is a disaster for an embedded engagement where the customer's data, workflow, and clinical context are the IP.

Cara writes work-for-hire and full IP transfer into the MSA, not buried in a single SOW. A vendor that only offers IP transfer in a per-engagement SOW is keeping the option to renegotiate later, when the customer has less leverage. Ask why it is not in the MSA.

The Gartner caution about vendor lock-in from FDE-led engagements is real. 70% of enterprises will be forced to abandon agentic-AI deployments delivered through FDE engagements by 2028, by their estimate, because of lock-in and a lack of internal skill to evolve them.

The mitigation is a written exit plan: knowledge transfer obligations, documentation standards, hiring support for the customer's internal team, code review windows, and a price for the transition. Cara includes a 90-day exit ramp in every Embedded SOW. If a vendor resists writing one, they are betting on lock-in. Ask them to commit on paper.

Pure time-and-materials pricing aligns the vendor with hours, not outcomes. Pure fixed-bid pricing aligns the vendor with scope, not value. The honest healthcare FDE engagement carries a mix: a base retainer for the embedded pod, plus a meaningful percentage tied to a small set of operational KPIs the customer cares about (no-show rate, scheduling conversion, denial rate, time-to-fill, prior-auth turnaround, whatever the workflow requires).

Outcome-based pricing is harder to write and easier to argue about. That is why it works. It forces the vendor and the customer to agree on what success looks like before any code is written. If the vendor will not take any outcome risk, they do not believe their own pitch.

Healthcare workflows take months to learn. A pod that rotates its engineer every quarter delivers the brand of FDE without the substance. Sales demos every staffing model as continuity. The contract should specify the named engineer and PM, the minimum tenure on the account, the notice period if either is rotated, and the customer's right to interview a replacement before transition.

This is not a hostage clause. It is a recognition that domain context is the entire value proposition. A vendor that refuses to name people is selling capacity, not partnership.

Every healthcare engagement should have these answered before the first call. Where is PHI processed and stored. Who is on the BAA, including subprocessors. Where is data residency. What is the breach notification timeline. What is the audit-log retention. Which model providers are on the BAA when LLMs are in the loop. What is the policy on PHI in prompts. What is the synthetic-data substitution policy.

The right answer is a one-page security overview the vendor can hand over in 24 hours. A vendor that takes two weeks to assemble one is telling you their security posture is bespoke per deal, which means it is bespoke per gap.

Status meetings rot. Written status persists. The PM should produce a weekly written update covering: what shipped, what is blocked, what changed in scope, what the next week looks like, and any decisions that require the customer's input. The customer's executive sponsor should sign each week's update. That is not bureaucracy. It is the audit trail that protects both sides when memory drifts at month nine.

Cara writes the cadence (weekly written status, monthly business review, quarterly on-site planning) into the SOW. If a vendor's only proposed cadence is a standing Zoom, the project will be governed by whoever talks loudest on the call.

This is the diagnostic question. A real partner has refusals. Cara will not build clinical decision support without a named clinical owner. We will not put PHI in a model that is not BAA-covered. We will not let an agent take an irreversible action against a payer or EHR without a human in the loop. We will not pretend a pilot is in production.

A vendor that cannot name a refusal is selling capacity. A vendor that names one too quickly is selling a pitch. The right answer is specific, defensible, and tied to how they actually work. Listen for it.

Send the ten questions to every vendor on the shortlist before the next round of meetings. Require written answers, signed by the vendor's executive sponsor, not pasted in by a sales rep. Compare the answers side by side. The vendors who write back fast and concrete are the ones to keep talking to. The ones who route to legal, hedge, or send a brochure are doing you a favor by self-identifying.

The contract is not a formality after the pitch. It is the operating model. The vendors who treat it that way are the ones who can actually run an embedded engineering engagement in healthcare. The rest are selling the label.

For the broader argument about why Forward Deployed Engineering is the right operating model for healthcare AI in 2026, see our companion piece: Forward deployed engineering for healthcare. For Cara's own definition of an Embedded engagement (FDE plus PM, on Cara payroll, on-site at meaningful intervals, with contractual IP transfer and a written exit ramp), see Cara Embedded Services.