Forward Deployed Engineering#

Forward deployed is borrowed from military logistics: a unit stationed at the forward operating position rather than at headquarters, close enough to the problem to act on it without a request going up and back down a chain. The engineering translation is literal. You work inside the customer's environment — their site, their Slack, their cloud account, their data — and you write production code there.

The precise definition, and the one worth memorising because every interview probes it:

Three clauses do the work. Embedded rules out remote advisory work. Production code rules out consulting. End-to-end accountability rules out pre-sales. Remove any one and you have described a different, older, less well-paid job.

1.1 The composition of the work#

Practitioners describe the split as roughly 40% engineer, 30% product manager, 20% consultant, 10% therapist. The proportions shift by company and by week, but the shape is stable and it explains most of what is unusual about the role.

1. Engineer. Not a diluted engineer. You are debugging a Kafka consumer at 2am, tuning a Postgres query, and writing the integration nobody else can write. FDEs without genuine depth become expensive project managers within a year.
2. Product manager. Nobody hands you a groomed backlog. You decide what is worth building, in what order, and you are the one who says no — which is only credible because you are also the one who would have to build it.
3. Consultant. You are reading an organisation: who actually decides, who is quietly opposed, which promise was made in the sales cycle that nobody wrote down.
4. Therapist. Deployments run through frustration. A team that has been through two failed vendor projects is not being difficult; it is being reasonable, and the first month is spent earning back trust somebody else spent.

1.2 What the role is not#

• Not staff augmentationYou are not a contractor filling a seat on the customer's team. You bring a platform and an opinion, and the engagement is a co-development partnership, not billable hours.
• Not customer support with a keyboardSupport responds to what broke. An FDE decides what gets built.
• Not a demo roleIf your artefacts are slides and sandbox environments, the title is solutions engineer and the incentives are different.
• Not a licence to write throwaway code foreverThe fifth arrow — patterns flowing back into the platform — is what separates a viable programme from a services shop.

• Origin Palantir, ~2005
• Internal track "Delta"
• By 2016 more FDEs than product engineers

Palantir was founded in 2003 and began selling Gotham into US intelligence agencies. The deployment problem it hit was not technical in the way vendors expect. Three things were simultaneously true of every customer:

1. They could not articulate requirements. Not from incompetence — the work was genuinely novel, adversarial and changed monthly. A requirements document written in January was fiction by March.
2. They could not share their data. Classified, undocumented, and in schemas that encoded tradecraft nobody outside the building would ever be shown.
3. Their workflows were the product. The value was not in a generic analytics tool; it was in the specific chain of decisions a specific unit made under time pressure.

The two available roles both failed. A consultant could produce an excellent document and no software. A solutions engineer could configure the product but could not change its shape, and the product's shape was the problem. So Palantir built a third role: a cleared engineer who sat at the customer's site for six to twelve months, learned the domain, wrote production Gotham code, and fed requirements back to the platform team in Palo Alto.

Two facts show how central it became. Internally the track is called Delta, parallel to Dev (platform engineering) and Echo (deployment strategist, the more business-facing sibling). And until around 2016, Palantir employed more forward deployed engineers than product engineers — a ratio that would be considered a strategic error at almost any other software company, and which produced a business with unusually high retention because the switching cost was not a subscription but a rebuild.

2.1 Why it spread#

Ex-Palantir engineers seeded the pattern across enterprise software, but it stayed niche while products were simple enough to self-serve. What generalised it was a change in the products, not in the idea.

Between 2023 and 2026 the pattern was adopted, near-identically, by OpenAI (Forward Deployed Engineering, stood up in late 2024), Anthropic (under Applied AI), Google Cloud, Databricks, Cohere, Scale AI, Glean, Sierra, Ramp, ElevenLabs, Mistral, Writer and Adobe. Job postings for the title grew roughly 800% between January and September 2025. By mid-2026 both leading labs had institutionalised it into separate ventures — OpenAI's deployment joint venture and Anthropic's enterprise services firm with Blackstone, Hellman & Friedman and Goldman Sachs — which is what it looks like when a staffing pattern becomes a business unit.

Traditional enterprise software front-loads its risk. You design, integrate, test; once it works it keeps working, and when it breaks it breaks loudly with a stack trace attached. That risk profile is what the standard motion — build product, sell it, onboard, hand to the customer's team — is designed for.

AI systems invert it. They are probabilistic, so they do not fail; they degrade. A model that scored well in testing meets production data and real users and starts returning answers that are plausible, confident and subtly wrong. Nothing alerts. Users quietly stop trusting it. Six months later the programme is cancelled and everyone blames the model.

3.1 The knowledge split#

The structural reason a support engineer or a document cannot close this gap is that the necessary knowledge is divided across a contract boundary, and neither party can acquire the other half quickly.

The vendor knows	The customer knows
How the model behaves at volume, and where it breaks	The domain logic and the vocabulary the business uses
Retrieval strategies, chunking, reranking, grounding	Which of forty tables is the one anyone trusts
How to build an eval suite and what it must catch	What the right answer is, case by case
Prompt architecture, structured output, guardrails	The compliance boundary and who enforces it
Cost and latency behaviour under load	The twelve exception types that generate most of the work

You need both columns to ship. The FDE is the mechanism for holding them in one head.

3.2 The integration wall#

There is a second, more mundane reason. Enterprise buyers consistently rank integration complexity above model quality and above cost as their top concern when adopting AI products. The bottleneck is not the model; it is wiring it into the SAP instance, the legacy ticketing system, the on-premises data lake and an identity provider configured in 2014.

Getting a demo working in a sandbox is roughly 20% of the work. The other 80% is enterprise SSO, legacy ETL, regulatory constraints, and the politics of obtaining production credentials from a security team that has never heard of you. No amount of prompt engineering touches any of it.

Job listings blur these constantly, which matters because the blur is how people end up in the wrong job. The distinguishing axis is not "do you talk to customers" — it is what you deliver and when your responsibility ends.

Role	Primary deliverable	New production code	Responsibility ends	Measured by
Forward deployed engineer	A running system in the customer's environment	Yes	After handover, months later	Production adoption and workflow impact
Deployment strategist	Problem framing, analysis, business case	Some; lighter than an FDE	Alongside the FDE	Whether the right problem was chosen
Solutions architect	Reference architecture, configuration	Rarely	At design sign-off	Technical fit of the design
Sales engineer	Demo, proof of concept, RFP answers	No	At contract signature	Deals won
Professional services	Configured implementation, billable hours	Sometimes, scoped by SOW	At SOW completion	Utilisation and margin
Product engineer	Platform features	Yes	Ongoing, one-to-many	Feature adoption across the base
ML engineer	Models, training and serving pipelines	Yes	Ongoing, platform-side	Model quality and serving cost

4.1 The deployment strategist#

Worth knowing because it is the most commonly confused sibling. At Palantir the Echo track pairs with Delta on the same account: the strategist owns problem selection, stakeholder mapping and the business case; the engineer owns the system. In smaller companies one person does both, which is why FDE postings read like two jobs — because they often are.

You cannot make good decisions inside an engagement without understanding why the company is paying for you, because the pressures you feel — for speed, for reuse, for saying no — all originate here.

Classical SaaS economics assume low marginal cost per customer: build once, sell many, and gross margin approaches the cost of servers. Forward deployment deliberately breaks that assumption by putting an expensive engineer on a single account for months. The bet is that it buys three things worth more than the margin it costs.

1. Time to value measured in days. The customer sees working software in week one rather than an implementation roadmap, which shortens the sales cycle for the next department in the same organisation.
2. Retention that is structural, not contractual. When a system is woven into the customer's pipelines and daily decisions, switching is a rebuild rather than a cancellation. High acquisition cost, very high retention, very high contract value.
3. Product feedback at the highest possible fidelity. The platform roadmap is set by what actually broke in the field, not by what a customer wrote on a survey.

5.1 The unit economics you must protect#

The whole model only works if the engineering effort per customer falls over time. Each engagement should leave behind a reusable component, so the next one starts further along. Plot it and you want a decaying curve.

effort per new customer

high |  ●
     |     ●
     |        ●          ← healthy: patterns are being extracted
     |           ●  ●  ●
 low |________________________________
     |  ●  ●  ●  ●  ●  ●
     |                     ← consultancy creep: flat line,
     |                       every customer costs the same
        C1 C2 C3 C4 C5 C6

A flat line means every account is bespoke, headcount grows linearly with revenue, and the business is a consultancy with a software brand. That is not a moral failure, it is a valuation difference of roughly an order of magnitude — and it is why the pressure to extract patterns is real rather than rhetorical.

5.2 Staffing ratios and compensation#

A rule of thumb used when standing up an FDE function is roughly one FDE per $2–5M of enterprise pipeline, with engagements of eight to sixteen weeks at a single customer. The important framing in that rule is that FDEs are treated as pipeline generation rather than cost of sale.

Compensation follows the scarcity. Reported 2026 figures — point-in-time, heavily role- and location-dependent, and worth treating as ranges rather than promises:

1. Palantir (FDSE) — roughly $171K–$295K total compensation, median near $211K on public aggregators; senior and staff levels reported substantially higher.
2. OpenAI (FDE, San Francisco) — posted band around $185K–$300K plus equity, hybrid three days a week, travel up to 50%.
3. Google Cloud (FDE-equivalent) — published bands around $127K–$183K base plus equity.
4. Anthropic (Applied AI) — frontier-lab compensation, weighted heavily towards equity.

Four stages plus a feedback arrow. The durations below are the common case; a bootcamp-style engagement compresses all four into a week, and a defence programme stretches them over years.

Stage	Typical span	Output	Exit criterion
Discover	Weeks 1–3	Falsifiable hypothesis, measured baseline, scoping doc	An operator agrees the problem statement is right
Prototype	Weeks 2–8	Working system on real data, in their environment	A real user completes a real task with it
Harden	Months 3–6	CI-gated evals, traces, security sign-off, runbook	It survives a week without you touching it
Hand off	Month 6+	Trained customer engineers, transferred pager	Their engineer ships a change alone
Feed back	Continuous	Extracted patterns merged into the platform	The next engagement starts with it

6.1 The compressed variant#

Palantir productised a three-to-five-day version as the AIP "bootcamp", and the shape is worth knowing because it is the clearest statement of what the stages are actually for:

1. Day 0–1. Model the customer's domain into an ontology — entities, properties, link types.
2. Day 2. Wire the ontology to the model as tool calls it can reason over.
3. Day 3. Ship one working, grounded application: a single decision workflow an operator can run end to end.
4. Day 4–N. Stay embedded and iterate the ontology and the tool surface against continuous feedback.

More than a thousand of these ran through 2024, converting at a high rate into seven-figure contracts. The lesson is not "everything should take four days" — it is that the stages are compressible because none of them is bureaucracy. Each one exists to retire a specific risk.

The highest-leverage decision available to an FDE is which engagements to decline. A bad one consumes two quarters, produces nothing reusable, and ends with a reference customer who is quietly negative.

7.1 The qualification checklist#

1. Is there a named workflow with a number attached? "We want to use AI" is not an engagement. "Our claims handlers take ninety minutes per exception and we process 4,000 a month" is.
2. Can you get to the data within two weeks? Not "will they agree in principle" — is there a named person who can grant read access and a network path that exists? This single question predicts more failures than any other.
3. Is there an operator who will give you time? Not the sponsor. Someone who does the work and is allowed to spend hours with you.
4. Does a decision follow the output? If nobody acts differently based on what you build, it is a reporting exercise and the value will not survive a budget review.
5. Is roughly 80% of it platform, not bespoke? If the platform covers almost none of it, you are about to write custom software forever.
6. Who signs off on production? Identify the security and change-control owners in week one. If nobody can name them, that is the finding.

7.2 Saying no well#

Declining is a skill with a technique. Never refuse the outcome; refuse the sequence. Offer the smaller thing you can do, and name what would have to change for the larger thing to be possible.

Discovery is engineering work, not a formality that precedes it. Modern AI forward deployed engineers spend roughly 30–40% of the week on customer conversations, running five to fifteen substantive discussions, and treat the output as a technical artefact. The reason is arithmetic: every hour of building is multiplied by whether the thing being built is the right thing, and no downstream excellence recovers from a wrong choice here.

8.1 The three layers of any process#

Every enterprise process exists in three versions, and they disagree. Knowing which one you are being shown is most of the skill.

1. The espoused process — the wiki diagram, the training deck, what the sponsor describes. Accurate about intent, silent about cost.
2. The actual process — what people do, including the spreadsheet, the phone call, the second login and the WhatsApp group. Where the time goes.
3. The exception process — what happens when the actual process fails. Usually 10–20% of volume and 60–80% of the effort, and it is almost never documented at all.

8.2 The interview technique#

The governing principle: people are reliable narrators of the past and unreliable designers of the future. Ask what happened; never ask what they would want.

Ask this	Not this	Because
"Walk me through the last one you did."	"Walk me through a typical one."	"Typical" is a reconstruction with the mess sanded off
"What did you do immediately before and after?"	"Is there anything else in the process?"	Adjacent steps are invisible to the person doing them
"When did this last go wrong? What happened?"	"What are the common failure modes?"	A story contains detail; a category contains none
"Which of these two numbers do you trust?"	"Is the data good quality?"	Everyone says the data is bad; only some know which part
"Show me on your screen."	"Describe the interface you use."	You will see four tabs they never mentioned
"What would you stop doing if you could?"	"What would you like the AI to do?"	The second invites them to design; the first reveals pain

8.3 Who to talk to#

• The operatorDoes the work daily. Knows the exceptions, the workarounds and which system lies. Your primary source, and the person whose adoption decides everything.
• The supervisorSees the queue, the backlog and the seasonality. Tells you what volume actually looks like versus the sponsor's estimate.
• The one engineer who has been there nine yearsKnows why the schema is like that, which job runs at 03:00, and what broke the last time someone tried this.
• Only the sponsorThey describe the problem visible from their seat, usually a reporting problem, and they are systematically optimistic about data quality.

8.4 Recording what you learn#

Discovery notes that are only prose decay into anecdote. Structure them so they convert directly into two downstream artefacts: the ontology and the eval set.

The second half of discovery runs in parallel and answers a different question: not "what do people do" but "what can I actually reach, how fresh is it, and who has to say yes".

9.1 The four questions per source#

1. Who owns it? A named human, not a team. You will need them, probably twice.
2. How do I read it, and how fresh is what I read? A nightly export and a live API are different products. An agent acting on a four-hour-old position is a failure mode, not a latency complaint.
3. What does it actually contain? Not the schema — the distribution. How many rows, how many nulls, how many values that violate the documented enum, and what changed in the last year.
4. What is its classification? Personal data, special category, regulated, export controlled. This determines the topology in section 22, so ask it now rather than in the security review.

9.2 The access critical path#

Data access is almost always the longest lead-time item in an engagement, and it is a queue rather than a task — which means it cannot be compressed by working harder, only by starting earlier.

request raised ──▶ owner identified ──▶ DPIA / risk review ──▶ account created
      2d                3–10d                 5–20d                  2–5d
                                                                       │
 network path opened ◀── firewall change ◀── change window ◀───────────┘
       1–3d                  5–15d              weekly

TOTAL, SERIAL: 3–8 weeks.   TOTAL, STARTED IN PARALLEL IN WEEK 1: 2–3 weeks.
The difference is not effort. It is when you started the slowest queue.

Discovery ends with one page. Not a requirements specification — a falsifiable hypothesis with a measured baseline and an explicit list of what you are not doing. If it cannot be proved wrong by the end of next week, it is not a hypothesis and you have not finished discovering.

10.1 The seven fields#

1. Who — the specific population, by role, location and headcount. "Users" is not an answer.
2. Today — the measured baseline, pulled from history before you build anything.
3. Belief — the causal claim. "If X were automatic, Y would fall below Z."
4. Test — what you will build this week and the observation that would falsify the belief.
5. Measure — the one primary metric and one guardrail metric, both defined precisely enough to compute.
6. Not doing — the explicit exclusions. This field prevents more disputes than the other six combined.
7. Needs from you — the customer's obligations, with names and dates.

10.2 Getting it disagreed with#

The document is not finished when you are happy with it. It is finished when an operator has read it and argued with at least one line. Silent agreement from a room of stakeholders usually means nobody has engaged closely enough to disagree, and you will hear the objection in month four instead.

An ontology is a typed model of the customer's nouns, their properties, the links between them, and the actions that can be taken on them. It sits between source systems named by people who have left and everything you build on top.

Palantir made it the centre of Foundry, and the pattern reappeared near-identically in enterprise tool-calling designs at every lab that copied the model — because the same constraint produces the same answer. A general-purpose model has no idea what your company means by "active account", and that knowledge has to live in a typed, testable, permissioned place rather than in a paragraph of prompt.

11.1 The four elements#

1. Entities — the nouns the business says out loud. Claim, Policy, Site. If an operator would not use the word in a sentence, it is not an entity.
2. Properties — including derived ones. is_overdue is a property even though no column holds it, and defining it once is the entire point.
3. Links — the verbs. claim → covered_by → policy. These encode joins that currently live in six analysts' heads.
4. Actions — the functions that read or change the world. This is the only surface the model is allowed to touch.

11.2 The rules that keep it useful#

• Use their vocabularyIf dispatchers say "dark" for a vehicle with no recent ping, the property is is_dark. Adoption is partly a naming problem.
• One definition, everywhereThe UI, the alerts and the model must call the same is_overdue. Two definitions diverge within a quarter and destroy trust.
• Start with three to six entitiesEnough to support one real decision. You are modelling a workflow, not the enterprise.
• Do not model everythingSix weeks of ontology and no working workflow is a failed engagement that looks productive from the outside.

"Ship on day one" is the operating principle the discipline is named for. It is a claim about risk: in an enterprise deployment the expensive unknowns are access and fit, and neither is discoverable by thinking. Only by trying.

12.1 What counts as shipping#

Three conditions, all necessary:

1. It runs on their real data, not a sample you were emailed. The sample is always cleaner than production, in ways that matter.
2. It runs in their environment, not on your laptop. The network path and the credential are the things you are testing.
3. Someone who does the work has seen it and has said something specific about it. "That one's wrong" on day one is worth a month of requirements gathering.

12.2 Why a read-only view is the right first artefact#

No model, no inference, no cleverness — a connector and a list. It seems too small to be worth doing, and it is the highest-information artefact available, because it simultaneously proves that you can authenticate, that a network route exists, that the data means what the schema claims, and that you have understood which records the operator cares about.

It also changes the conversation's mode. A diagram invites opinions; a screen with their own records on it invites corrections, and corrections are data.

Weeks two to eight produce a prototype whose purpose is to be thrown away. Say that out loud, early, to the customer — otherwise the first working version becomes load-bearing by accident and you spend a year maintaining a scaffold.

13.1 What to do properly even in a prototype#

Taste under pressure is the skill being tested: knowing which corners are safe to cut. The dividing line is whether a shortcut is reversible.

Cut this	Never cut this	Why
Styling, polish, responsive layout	Entitlement checks	A permission bug in a demo is a reportable incident
Horizontal scaling, caching, queues	Not writing to production systems	Read-only is reversible; a bad write is not
Configuration UI, admin screens	Secrets handling	A key in a notebook becomes a key in a repo
Test coverage on glue code	The eval set	It is the artefact you keep when the code goes
Error handling on internal paths	Provenance and citations	Unverifiable output cannot be trusted or defended
Perfect data modelling	Using the customer's vocabulary	Renaming later is disproportionately expensive

13.2 The honest demo#

Demonstrate to operators before sponsors, on live data, and include a case you know it gets wrong. Showing a failure and explaining why builds more confidence than a flawless run on hand-picked inputs — partly because the audience knows their domain well enough to spot the hand-picking, and partly because the failure is what tells them where the boundary is.

Most of the code an FDE writes is not model code. It is the unglamorous work of getting data out of systems that were not designed to be read by anyone, reconciling it, and keeping it fresh — and it is the part that determines whether anything above it can be trusted.

14.1 The four shapes of source#

Shape	Typical example	Freshness	What bites you
Batch export	Nightly CSV to SFTP from an ERP	6–30 hours	Silent failures; yesterday's file served as today's
Database replica	Read replica of the operational store	Seconds to minutes	Replication lag during exactly the busy period
API	Ticketing, CRM, carrier tracking	Real time	Rate limits, pagination bugs, undocumented 5xx
Event stream	Kafka topic of state changes	Sub-second	Out-of-order and duplicate delivery; no replay window

14.2 The non-negotiables#

1. Idempotency. Every load must be safe to re-run. You will re-run it, at 3am, without remembering what it does.
2. Watermarks, not "yesterday". Track the maximum processed timestamp so a missed run catches up rather than skipping a day silently.
3. Freshness as a first-class signal. Every record carries when it was last true, and the UI shows it. "The roster was last updated 14 hours ago" is the field that stops the phone call in our running example.
4. Schema assertions on every run. Fail loudly on an unexpected column or a changed type, rather than quietly producing nulls that degrade a model three weeks later.
5. Reconciliation. Row counts and control totals against the source. Enterprises trust numbers that tie out and distrust everything else, correctly.

Grounding answers a question the model cannot: what is true at this company. Two pipelines — one that runs on a schedule to build the index, one that runs per question to serve it — and conflating them is why teams find themselves reindexing 40,000 documents to fix a ranking bug.

15.1 Decisions in the ingest pipeline#

1. Corpus selection. The first question is not chunking, it is which of these documents does anyone trust. A share drive contains superseded drafts, personal copies and three versions of the same policy. Indexing all of it produces a system that confidently cites the 2019 version.
2. Chunking. Fixed-size splitting severs clauses from headings and destroys tables. Chunk on the document's own structure and carry the heading path into every chunk, so a retrieved fragment still knows which section it came from.
3. Embedding model. A customer decision, not a default. An English-tuned model over a German contract corpus silently loses recall, and "silently" is the operative word.
4. Metadata. Permissions, effective dates, document status and version. All of it is needed at query time and none of it can be added later without a reindex.

15.2 Decisions in the serve pipeline#

• Hybrid search by defaultVector search misses exact identifiers — part numbers, policy codes, ticket references — which is precisely what enterprise users search for.
• Retrieve wide, rerank, pass narrowTwenty candidates, reranked, five into the prompt. Usually worth more than upgrading the base model and far cheaper.
• Filter by entitlement inside the queryPost-filtering turns "you may not see this" into "there is no answer", which is a different and worse failure.
• Never let the model self-police access"Do not reveal documents the user cannot see" is not access control. It is a request.

15.3 Measuring retrieval separately#

Debugging grounded systems is tractable only if you separate the two questions: was the right passage retrieved, and given the passages, was the answer right. Teams that measure only end-to-end quality spend weeks tuning prompts to fix a retrieval problem.

A prompt that works in a demo and a prompt that holds across thousands of production inputs are different artefacts. The second is architecture: a stable, versioned structure with variable slots and a contract on what comes out.

16.1 The layers#

1. Role and boundary. What the system is, and explicitly what it must not do. Short.
2. Domain vocabulary. The handful of terms the model cannot be expected to know — pulled from the ontology, so it cannot drift from the code.
3. Policy. The rules that are genuinely rules. Keep this short, because anything important enough to be a rule belongs in code (section 17).
4. Output contract. A schema, not a description of a schema.
5. Few-shot examples. Chosen to cover the edges, not the centre. Three edge cases beat ten typical ones.
6. Retrieved context. Last, clearly delimited, with citations attached.

16.2 Structured output#

Free text is not an integration point. If the output feeds anything downstream — a database, a workflow, a decision — constrain it to a schema and validate it. Prose becomes a field inside the structure, not instead of it.

16.3 Versioning prompts#

Prompts are production code. In the repository, in review, with a version id emitted on every trace so that "when did this start getting worse" has an answer. A prompt edited live in a console is an unversioned production deployment, and it is how a working system becomes a mystery.

An agent is a bounded loop around a model with a tool surface. The loop is a dozen lines. Every difficult decision is about the boundary: which tools exist, what they may do, how many turns are allowed, and who approves the ones that matter.

17.1 Designing the tool surface#

1. Few tools, well named. Six good tools outperform thirty overlapping ones. Selection accuracy degrades as the surface grows.
2. Verbs from the ontology. find_claims, escalate_claim — the actions the business already recognises, not run_sql.
3. No general escape hatches. A run_sql tool is a data exfiltration primitive with a friendly name, and it makes every other control irrelevant.
4. Separate read from write. Different approval requirements, different logging, different blast radius.
5. Bounded returns. Cap rows and truncate fields. An unbounded return is how a context window and a token budget disappear at once.
6. Descriptions written for a stranger. The description is the only documentation the model reads. Ambiguity there produces confident misuse.

17.2 Where policy lives#

Constraint	In the prompt	In code
Tone, formatting, verbosity	Yes	Unnecessary
Preference between two valid options	Yes	Optional
Spending limits	Also, for steering	Required
Which records a user may see	Never rely on it	Required
Which counterparties are permitted	Also, for steering	Required
When a human must approve	Never rely on it	Required

17.3 Turn limits and failure#

Cap the turns and fail loudly at the cap. An unbounded loop is a way to spend a large amount of money slowly while appearing to work. When a guardrail blocks a call, feed the reason back as an observation — a model told why it was blocked will replan; a model told only "denied" will retry the same call.

17.4 Framework choice#

The framework wars of 2023–2024 resolved into a practical consensus for forward deployed work: reach for the first-party SDK, and add an abstraction only when you have a concrete reason. The reasoning is specific to the role rather than to taste.

• Bare SDKFewest dependencies to defend in a security review, easiest to debug in an environment you cannot attach a debugger to, and simplest to hand to the customer's team.
• A graph frameworkJustified when you genuinely have cycles, branching state and human-in-the-loop checkpoints — express that explicitly rather than reinventing it badly.
• Durable executionWhen "the process ran for 47 minutes and the container was recycled" must not be a failure mode, use a workflow engine. Long-running agents need durability more than they need cleverness.
• Deep abstraction stacksPrototype with them if they help; unwind before production. Every layer is a question on a Thursday and a thing the customer must maintain.

Evaluation engineering is the most-cited differentiator in forward deployed hiring, and the reason is operational rather than academic. Without evals nobody can tell whether a change helped, so eventually nobody changes anything, and a frozen system diverges from the business until it is switched off.

18.1 Where cases come from#

Not from imagination. Four sources, in descending order of value:

1. Discovery observations. The cases you watched in section 8, with the decision the operator made and the reason they gave.
2. Field failures. Every production complaint becomes a case, permanently. This is what makes the suite compound.
3. Known-hard historical cases. Ask the supervisor for the ten that caused arguments. These are the edges the business actually cares about.
4. Adversarial and safety cases. Prompt injection in a retrieved document, a request outside the user's entitlements, a question the system should refuse.

18.2 The anatomy of a case#

18.3 How big#

A spreadsheet is genuinely fine for the first ten cases. By fifty you want a runner; by a few hundred you want stratification, so that "94% pass" cannot hide a category that fails entirely. Report per category — standard cases, edge cases, adversarial, entitlements — because the aggregate is what lets a systematic failure hide in plain sight.

19.1 Choosing a grader#

Match the grader to the case. Reaching for a model-graded rubric by default is the most common mistake, because it introduces variance into the instrument you are using to measure variance.

Grader	Use for	Cost	Watch out for
Exact match	Classifications, routing decisions, refusals	Free	Brittle if the output is not constrained
Field assertion	Structured output — one field checked	Free	Passing while the reasoning is nonsense
Set overlap	Extraction, entity lists, citations	Free	Partial credit hiding systematic omissions
Deterministic rule	"Never exceeds the cap", "always cites"	Free	Nothing — prefer these wherever possible
Model-graded rubric	Genuinely open-ended answers only	Tokens + variance	Position bias, verbosity bias, drifting with model updates
Human review	The sampled tail, and anything high-stakes	Expensive	Reviewer fatigue and inconsistency

19.2 Gating CI#

The suite has to be a gate, not a report, or it becomes a dashboard nobody opens. The rule that works in practice distinguishes two kinds of failure:

1. Regressions block the merge. A case that passed on the baseline and fails now stops the pipeline. No exceptions, including for you.
2. Still-failing cases do not block. They are known gaps, tracked honestly. Blocking on them means nobody can ever add a hard case, which means the suite stops describing reality.

19.3 Watching for drift#

Offline evals catch what you thought to test. Production drifts in ways you did not: input distributions move, the corpus grows, an upstream schema changes, a new team starts using it differently. Three signals, cheap to compute, that catch most of it:

1. Abstention and low-confidence rate. A rising rate means the inputs have moved away from what the system was built for. It is the earliest warning you get.
2. Retrieval hit rate. Falling median similarity or rising empty results means the corpus or the questions have changed.
3. Outcome rate. Accepted versus edited versus ignored. A quiet decline here precedes every cancelled programme, and it is the only direct measure of trust you have.

Autonomy is a dial, and the customer sets it. Your job is to build the dial, instrument it, and produce the evidence that justifies moving it — not to argue for a position on it in month one.

20.1 The four settings#

1. Assist. The system surfaces information; the human decides everything. Lowest risk, and often the majority of the value — most of our running example's ninety minutes was spent gathering information, not deciding.
2. Propose. The system drafts a decision with reasoning; the human approves or rejects. Every interaction is a labelled training and eval example arriving for free.
3. Act with threshold. Autonomous below a value or confidence line, human above it. The line comes from the propose-mode data, which is why you run propose mode first.
4. Autonomous with audit. Acts alone; every action is logged, sampled and reversible. Justified only where the evidence supports it and reversal is genuinely possible.

20.2 Designing the approval step#

A badly designed approval step degenerates into rubber-stamping within a fortnight, at which point you have the risk of autonomy with the cost of review.

• Show the reasoning and the evidenceThe retrieved passages, the tool results, and the rule applied — enough for the reviewer to disagree on substance.
• Make rejection cheap and informativeOne click plus a reason from a short list. Those reasons are your best eval cases.
• Batch by similarityReviewing thirty similar cases together is faster and more consistent than thirty context switches.
• Do not show only the conclusionA yes/no with no evidence trains the reviewer to click yes, and you will not find out until an audit.

20.3 Failing gracefully#

Every AI system must have a defined behaviour for "I do not know" and for "the dependency is down", and both must be visible rather than silent.

1. Abstention is a valid output. Make it a first-class value in the schema and route it to a human. A model with no way to abstain will guess, confidently.
2. Degrade to the previous workflow, explicitly. If retrieval is down, say so and show the operator where to look manually. Silence makes them assume the answer is complete.
3. Never fail into a default decision. Timing out into "approve" is how an outage becomes a financial incident.
4. Show freshness and coverage. "Indexed to 14:05 today; 3 of 9 sources stale" lets a user calibrate their trust instead of guessing at it.

Your prototype has one API key and one implicit user. Production has an identity provider configured in 2014, four hundred groups with overlapping meanings, and a joiners-movers-leavers process that must revoke access within a day. This is the first gate in the integration wall and the one engineers most reliably underestimate.

21.1 The four identities in play#

Getting these confused is the source of most authorisation bugs in AI systems, because the interesting one — the third — does not exist in ordinary applications.

1. The end user. Authenticated through the customer's IdP via OIDC or SAML. Their group memberships determine what they may see.
2. The application. A service identity with its own, ideally narrower, permissions on each backing system.
3. The agent acting on the user's behalf. The subtle one. When a tool runs, whose authority does it carry? It must be the user's, not the application's, or you have built a confused deputy that answers any question for anyone.
4. The reviewer. For approval steps: a distinct identity, recorded, and ideally not the same person who submitted.

21.2 Mapping groups to entitlements#

The customer will hand you group names like GG-CLM-LDS-T2-RW and nobody will fully remember the convention. Build an explicit, reviewable mapping from their groups to your entitlements — and fail closed on anything unrecognised.

Where the system runs is determined by the data's classification, and it constrains every other decision. Decide it in week one from the answers in section 9, not in month four during a security review.

22.1 Choosing#

Topology	Choose when	You give up	Operational cost
Vendor SaaS	Data is not regulated; speed matters most	Control over where prompts are processed	Lowest — one deploy, one on-call rota
Customer VPC	Regulated data; the common 2026 case	Direct access — you cannot log in and look	High — one deployment per customer
On-premises / air-gapped	Classified, sovereign or no-egress estates	Frontier model quality; fast iteration	Highest — releases as signed artefacts
Hybrid	Sensitive processing in, non-sensitive out	Simplicity; you now have two of everything	High — and the boundary must be provable

22.2 The consequences of a VPC deployment#

The most common shape deserves its own list, because the consequences reshape how you work day to day:

1. You cannot attach a debugger. Debugging happens entirely through telemetry you had the foresight to emit, often relayed by someone else. Log more than feels necessary, structure it, and make log levels changeable without a redeploy.
2. Version fragmentation is guaranteed. Eleven customers means eleven versions. Script the deployment identically from the first account and keep a version matrix you actually update.
3. Upgrades are negotiated, not shipped. Every version bump is somebody's change window. Batch changes and make releases boring.
4. Their SRE team may be on call. If so, choose technologies they already run. A perfect stack nobody in the building understands is an outage waiting for a Sunday.
5. Cost is theirs and visible. Compute shows up on their cloud bill, which makes efficiency a relationship issue as well as an engineering one.

Compliance is not a tax applied at the end. It is a set of constraints that determine your architecture, and finding them late is the most expensive ordinary mistake in this job.

23.1 The questions to ask in week one#

1. What classification is this data? Personal, special category, financial, export-controlled, classified. Each carries different handling rules.
2. Where may it be processed and stored? A jurisdiction, not a preference. This decides the topology and often the model provider.
3. Is the model provider an approved sub-processor? If not, adding them is a contractual change with a legal review attached, and that is a multi-week queue.
4. What is the retention policy on prompts and completions? Zero-retention endpoints exist and are frequently mandatory. Find out before you design the trace store.
5. Is there an automated-decision constraint? Some decisions carry a right to human review or explanation. That is section 20's dial being set by law rather than by preference.
6. What is the audit requirement? Who must be able to reconstruct a decision, how far back, and in what form.

23.2 Building for audit#

In eighteen months somebody will ask why a specific decision was made on a specific day. Everything needed to answer must have been captured at the time; none of it can be reconstructed afterwards.

Deterministic systems fail loudly. Probabilistic systems degrade quietly, and an uptime dashboard will report 100% while trust collapses. Observability for these systems has to measure something else.

24.1 The trace record#

One structured event per request, with a correlation id that reaches the user interface so a complaint maps to an exact run.

1. Inputs — the question, the principal's role, the entry point.
2. Retrieval — which documents, which scores, how many candidates.
3. Generation — model and version, prompt version, token counts.
4. Tools — each call, arguments, latency, and outcome.
5. Timing — per span, not just the total. The total tells you there is a problem; the spans tell you where.
6. Cost — in currency, tagged by team or cost centre.
7. Outcome — accepted, edited, ignored, escalated. The field teams skip, and the only direct measure of quality you have.

24.2 The four dashboards that matter#

Dashboard	Answers	Audience
Volume and adoption	Who is using it, how often, and is that growing?	You and the sponsor
Quality proxies	Accept / edit / ignore rates, abstention, retrieval hit rate	You, weekly
Latency by span	Where is the time going, and is it getting worse?	You and their SRE team
Cost per outcome	What does one resolved case cost, and against what?	The person who renews the contract

24.3 Tuning in the right order#

The waterfall above shows the general shape: the model call usually dominates, the instinct is usually to optimise the retrieval code you wrote, and those two facts are why measurement precedes tuning. The ordered list of moves, cheapest first:

1. Stream. Total time unchanged, perceived latency transformed. Users report perceived latency.
2. Cache the stable prompt prefix. The system prompt and schema are identical every call; caching them cuts latency and spend at once.
3. Cache slow tool results where staleness is acceptable. Often removes a legacy round-trip from the hot path entirely.
4. Route by difficulty. A smaller model for the easy majority, the frontier model for the hard minority. Your eval suite tells you where the line sits.
5. Shrink context. Fewer, better chunks after reranking. Cheaper and usually more accurate, because irrelevant context degrades answers.

Being on call for a system inside someone else's estate is materially different from being on call for your own. You often cannot log in, the people who can are not on your team, and the escalation path crosses a contract boundary.

25.1 What actually breaks#

In roughly descending order of frequency, and notice how few involve the model:

1. An upstream data source stopped or changed. The export did not run; a column changed type; an API deprecated a field. By far the most common cause.
2. A credential expired. Certificates, tokens, service accounts caught by a password rotation policy nobody told you about.
3. A dependency was slow, not down. The legacy API takes eight seconds during their nightly batch window and your timeouts were tuned at noon.
4. A model provider changed something. A version rolled, a rate limit changed, a response format shifted subtly.
5. Someone changed the customer's environment. A firewall rule, a proxy, a DNS entry, a Kubernetes upgrade.
6. Genuine quality degradation. Real, important, and the rarest cause of a page.

25.2 The runbook#

Written from real incidents, as they happen, symptom-first — because symptom is what the person at 2am has. A runbook written at the end of the engagement is fiction, and everyone can tell.

25.3 The kill switch#

Every autonomous system needs a documented way to drop to propose-only or to turn off entirely, executable in under a minute by someone who is not you. Test it. Then tell the customer it exists and show them how to use it — the conversation where you demonstrate the kill switch does more for a security review than any architecture document.

A system that works and is not used has failed. Adoption is the metric that decides renewal, and it is measured, not asserted.

26.1 The adoption funnel#

eligible users    400          ← everyone who could use it
      │
ever used         210  (53%)   ← onboarding / awareness problem if low
      │
used this month   120  (30%)   ← habit problem
      │
used this week     64  (16%)   ← THE number. Weekly use = it is in the job.
      │
acted on output    51  (13%)   ← accepted or edited, not ignored
      │
would miss it     ~40          ← ask them. The honest renewal signal.

Each step has a different diagnosis. A collapse between "ever used" and "used this month" is a habit problem and usually means the system sits outside the workflow — a separate tab, a separate login. A collapse between "used this week" and "acted on output" is a trust problem, and trust problems are quality problems wearing a disguise.

26.2 Proving value#

In month six somebody will ask what this bought. The answer must be a number computed the same way as the baseline from section 10, with the guardrail metric alongside it.

1. Same definition, same query, same source as the baseline. If the definition changed, the comparison is worthless and a sceptical CFO will say so.
2. Report the guardrail next to the primary metric, always. Volunteering "reopen rate held at 32%" is what makes the primary number credible.
3. Segment by team and by case type. An aggregate improvement hiding one team that got worse is an argument waiting to happen — better that you find it.
4. Use a comparison group where you can. Cardiff not yet live while Leeds is gives you a natural control that is far more persuasive than a before-and-after line.
5. Be honest about attribution. If they also hired six people, say so. Credibility compounds over an engagement and is spent instantly.

The engagement is measured by what still works and still changes ninety days after you leave. Handover is not a phase at the end; it is something you do continuously from about month two.

27.1 The hero trap#

27.2 The five things to transfer#

1. The runbook, written from real incidents, symptom-first.
2. The eval suite, with the expected answers signed off by their domain expert. Without it they can run the system but cannot safely change it.
3. The deployment path — scripted, documented, and executed by them at least twice while you watch.
4. The pager, with their engineer primary and you secondary for a fortnight. The first page they handle alone is the real handover.
5. The decision log — why the architecture is the way it is, and which options were rejected. Without it the first new engineer will redo a decision you spent a month on.

27.3 The pattern that works#

Reverse the pairing direction. Watching you deploy teaches nobody anything; doing the deploy while you watch teaches everything. From month two: they drive, you advise. Take your hands off the keyboard even when it would be faster to take over — especially then, because that impulse is exactly how the bus factor stays at one.

The fifth arrow in the engagement loop is the one that makes the whole model economic, and it is the one under the most pressure — because it is always less urgent than the customer in front of you.

28.1 The rule of three#

Once is a one-off. Twice is a coincidence. Three times is a missing platform feature. The rule is deliberately mechanical, because the judgement call — "is this general?" — is one engineers make badly under delivery pressure, in both directions.

28.2 Extracting well#

• Take the intersection, not the unionThe 80% genuinely common across the three implementations, with extension points for the rest. Union-shaped abstractions are how platforms become unusable.
• Migrate the existing accountsAn extraction that leaves three forks running is a fourth implementation, not a consolidation.
• Write down what you did not generaliseand why. The next person will rediscover the same edge case and needs to know it was considered.
• Do not abstract on the first repeatTwo data points define a line through anything. The third tells you the shape.

28.3 The feedback that is not code#

Not every field insight is a component. Three other channels matter as much, and they are the ones a busy FDE drops first:

1. Failure patterns to the model and research teams. "German umlauts break normalisation in this class of document" is worth more than a feature request, because it generalises to customers nobody has met yet.
2. Eval cases to the shared suite. A case discovered at one customer protects every other customer from the same failure. This is the cheapest and most-skipped form of leverage in the whole model.
3. Deployment friction to product. "Every customer asks the same four questions about data retention" is a documentation gap that costs a week of FDE time per account and can be fixed once.

The forward deployed model is not a panacea and its failure modes are well documented. Recognising them early is part of the job, including recognising them in yourself.

29.1 Consultancy creep#

Symptom: engineering effort per customer is flat across accounts; the platform team's roadmap is not influenced by field work; each engagement starts from near zero.

Consequence: headcount grows linearly with revenue and the business is valued as a services firm rather than a software one — a difference of roughly an order of magnitude in multiple.

Counter: the rule of three, protected extraction time, and an explicit reuse metric reported alongside delivery.

29.2 Hero culture#

Symptom: one irreplaceable engineer per account; the customer refuses to work with anyone else; nothing is documented because everything is in someone's head.

Consequence: churn on reassignment, and a systematic underestimate of how much work the account really takes.

Counter: forced rotation, bus-factor targets, and treating the runbook and eval suite as deliverables rather than nice-to-haves.

29.3 Platform–product mismatch#

Symptom: the platform covers a small fraction of what customers need; FDEs write bespoke software indefinitely; the same gaps are reported from every account and never closed.

Consequence: an unwinnable position. FDEs cannot fix a weak product; they can only delay the reckoning, and in the meantime they absorb the blame for it.

Counter: qualification (section 7) and escalating the pattern honestly rather than heroically absorbing it. This one is not an individual's problem to solve, and pretending otherwise is how good engineers burn out.

29.4 Burnout#

Symptom: travel, customer pressure, and a complete context switch every quarter. The cognitive load of holding an entire unfamiliar domain is genuinely high and is usually invisible to management.

Counter: the healthiest programmes plan rotation and rest deliberately rather than hoping. Individually: the eval suite and the runbook are also your tools for sleeping — they are how you stop being the only line of defence.

You will write a Terraform module for an SRE and a one-page memo for a CFO in the same week, and both have to be good. Communication range is not a soft add-on to this role; it is the load-bearing skill that decides whether good engineering reaches production.

30.1 The four audiences#

Audience	Cares about	Length	Fatal mistake
Operator	Does it make Tuesday easier? Can I trust it?	Show, do not write	Explaining the architecture
Their engineers	How does it work; what will page me	Precise, complete	Hand-waving the hard parts
Security / risk	Where does data go; what can it do; who approved	One diagram, one table	Defensiveness, or vagueness about data flow
Executive sponsor	Is it working, what does it cost, what is the risk	One page, numbers first	Technical detail; hiding bad news

30.2 The weekly update#

The single highest-return habit available to an FDE. Same format, same day, every week, whether or not there is news. It builds a written record, surfaces blockers while they are still cheap, and — most usefully — creates a standing, low-drama place to say "I need something from you".

Every deployment happens inside an organisation with its own history, incentives and unresolved arguments. Ignoring that is not neutrality — it is how technically excellent projects die quietly.

31.1 The map to draw in week one#

1. Who benefits if this works? Name them. They are your allies and they should be visible in every demo.
2. Who loses — budget, headcount, relevance, control? They are not villains and they are not going away. Engage early, honestly.
3. Who has a veto that is not on the org chart? Security, a works council, a regulator, a long-tenured engineer everyone defers to.
4. What was promised in the sales cycle? Find out precisely. You will be measured against it whether or not it was realistic, and whether or not you were in the room.
5. What failed here before? There is almost always a previous project. Knowing why it failed tells you what the room is braced for.

31.2 Staying useful without taking sides#

• Be the person with the dataIn an argument about whether the process is slow, the one who can show the distribution wins without needing an opinion.
• Give credit outwardEvery win belongs to the customer's team in public. You are not there to be seen; you are there to be renewed.
• Do not become a weapon in someone's internal fightYou will be invited to, and it always looks like being trusted. It ends the engagement when that person loses.
• Do not promise on behalf of the sponsorEspecially about headcount, timelines or anything involving another department's budget.

32.1 What the bar actually is#

Hiring for this role screens for a specific and unusual combination. Palantir's version of the bar has four components, and every company copying the model screens for something close to it:

1. Engineering depth. Production experience with real systems — typed languages, distributed systems, data engineering. Not "familiar with".
2. Domain curiosity. Willingness to spend three months learning anti-money-laundering rules, naval logistics or trial enrolment, and to find it interesting.
3. Conversational range. Interview a warrant officer and a Fortune 100 executive in the same week and extract what each of them needs.
4. Refusal to hide behind process. Walk into a site with no statement of work and start delivering value.

32.2 The backgrounds that convert#

• Early-stage startup engineerThe single strongest predictor. First ten engineers have already done this job: talked to customers, worn every hat, shipped under existential pressure.
• Hands-on solutions architectNot the ones who only produce diagrams — the ones who build the proof of concept themselves.
• Data or ML engineer with real systems chopsIf you have built and operated pipelines rather than living in notebooks.
• Consulting with deliveryThoughtWorks-style engagements where you shipped code in a client's environment map almost directly.
• Deep-but-narrow backend specialistStrong signal on one axis and nothing on the others. Fix it by building the portfolio below before applying.

32.3 The portfolio that gets you past screening#

Three projects, each mapping to one round of the loop. Build them in this order:

1. Something deployed in someone else's environment. A non-profit, a small business, a partner team. The specific experience being screened for is running discovery, shipping into constraints you did not choose, and managing the relationship.
2. An enterprise integration. Pick a real enterprise API, implement OAuth 2.0 properly, handle rate limits and retries, add structured logging and a monitoring setup. Write up what broke.
3. An AI deployment under constraint. Run an open-weight model on hardware you control, build retrieval over a realistic corpus, and — the part that differentiates — build the eval harness and show the numbers. Very few candidates do the third part.

32.4 The loop#

Round	Tests	Prepare by
Recruiter screen	Motivation, travel tolerance, salary alignment	Having an honest answer about the trade-offs
Behavioural	Ownership, ambiguity, stakeholder management	Five written STAR stories where you owned it
Practical coding	Can you build the unglamorous thing quickly	Messy-data parsing, API building, not LeetCode
System design	Data-heavy and AI-heavy architecture	Practising a RAG-over-internal-wikis and a private deployment
Decomposition case	Scoping, sequencing, judgement under ambiguity	Section 33 — this is the one people fail
Deployment simulation	Hands-on execution plus communication, together	Palantir-specific; several hours on a simplified platform

Sixty minutes, a whiteboard, and one ambiguous sentence. The interviewer is not looking for an answer — they are watching how you handle not having one.

33.1 The method#

1. Do not solve. The first instinct — "train a model to predict traffic" — fails immediately, because you have optimised something before knowing whether it is the constraint.
2. Interview the interviewer. Metric, user, data, constraint. Each answer can invalidate half your ideas, which is the point of asking first.
3. Decompose by dependency. Sub-problems in the order they must be solved, stating which depends on which.
4. Propose the boring MVP. The simplest thing that changes someone's day. Usually no model at all.
5. Iterate out loud on trade-offs. When they push, reason rather than defend. Changing your mind on new information is a positive signal, not a retreat.
6. Name what you would not build, and why. This is the clearest evidence of judgement you can give them.

33.2 A full worked answer#

34.1 The engagement#

Stage	Do	Deliverable	Exit criterion
Qualify	Named workflow, data access path, operator time, a decision downstream	Go / no-go with reasons	You can name the production approver
Discover	Watch the work; find the exception process; profile the data	One-page scoping doc + measured baseline	An operator argues with a line of it
Model	3–6 entities in their vocabulary; links; actions	Typed ontology + tool surface	One real decision is expressible in it
Prototype	Real data, their environment, narrow scope	Working artefact by day 1; end-to-end by day 3	A real user completes a real task
Harden	Evals in CI, traces, entitlements, security review	Gated pipeline, runbook, audit records	A week passes without you touching it
Hand off	Pair in reverse; transfer pager and eval suite	Bus factor ≥ 3	Their engineer ships a change alone
Feed back	Rule of three; intersection not union; migrate forks	A platform feature	The next engagement starts with it

34.2 The rules worth memorising#

1. The model is the easy part. Deployment is the product.
2. A prompt is a suggestion; code is a control. Anything whose violation is an incident lives in code.
3. Discovery is engineering. You cannot eval your way out of building the wrong thing.
4. Ship on day one, narrow not shoddy. Access and fit are only discoverable by trying.
5. Read-only first. Shortest approval chain; earn write access with a track record.
6. One definition, everywhere. UI, alerts and model call the same is_overdue.
7. Filter by entitlement inside the query. Never post-filter, never ask the model to be discreet.
8. Diff evals per case, not in aggregate. Red-to-green-to-red is a release blocker.
9. Traces are personal data. They live where the data lives.
10. Freshness alerts beat error-rate alerts. Stale indexes produce no errors.
11. Cost per resolved case, never cost per token.
12. Start every agent at propose-only. The approvals are your labelled dataset.
13. Rule of three. Third repeat is a missing platform feature.
14. Bus factor ≥ 3, where one means you.
15. Put the ask in bold with a name and a date.

What to do when you see a given signal. This is the table to re-read before a decomposition interview and in the first fortnight of any engagement.

You observe	It usually means	Do this
The brief is a technology, not a problem	Nobody has named a workflow	Refuse to scope until a workflow with a number exists
Everyone praises the process diagram	You have seen the espoused process only	Ask "and when does that not work?"
An operator keeps a personal spreadsheet	A real requirement lives outside every system	Model it as an entity; it is load-bearing
Two systems disagree on a number	There is an unwritten rule about which is right	Find the rule; encode it once in the ontology
Data access "will be fine"	Nobody has actually asked the owner	Get a name and a date this week; it is the critical path
The demo is flawless on five cases	The cases were curated	Demo a failure deliberately, before the sponsor does
Answers are wrong but fluent	Retrieval, not generation	Measure recall@k before touching the prompt
Quality argument with no numbers	No eval suite	Stop; build twenty cases with the domain expert
Scores flat but a new case broke	Aggregate reporting is hiding a regression	Diff per case; gate CI on pass-to-fail
Rising abstention or low confidence	Inputs have drifted from the design	Sample the new inputs; promote them into evals
Usage plateaus at ~15%	It lives outside the workflow	Move the output into the ticket or record
Output accepted without reading	Rubber-stamping; review is theatre	Show evidence and reasoning; make rejection one click
Security engaged in month four	Your architecture may be void	Take them a threat model now; expect rework
You are the only one who can deploy	Hero trap	Reverse the pairing; give away the pager
You have built this integration a third time	Missing platform feature	Extract the intersection; migrate the forks
Every account needs bespoke work	Platform–product mismatch	Escalate the pattern; do not absorb it heroically

Reading this course does not make you an FDE any more than reading about sailing makes you a sailor. The skills are built by shipping into constraints you did not choose. Here is a sequence that produces the evidence hiring screens for.

36.1 Weeks 1–4 — the technical floor#

1. Take a messy public dataset — government open data is ideal because it is genuinely inconsistent. Profile it (section 9), model three entities (section 11), and expose them as an API.
2. Build retrieval over a real corpus with hybrid search, reranking and citations. Measure recall@k against forty annotated questions before you touch a prompt.
3. Wrap it in an agent with three tools, a turn cap, and a guardrail enforced in code. Break it on purpose with an injected instruction in a retrieved document.

36.2 Weeks 5–8 — the differentiator#

1. Build the eval harness. Fifty cases across four categories — standard, edge, adversarial, entitlements — with per-case diffing and a CI gate that actually fails the build.
2. Add tracing: prompt version, retrieval, tool calls, latency per span, cost, outcome. Produce the four dashboards from section 24.
3. Deploy it somewhere constrained — a private network, an on-prem box, an open-weight model behind a local server. Write down every blocker you hit; that list is the integration wall.

36.3 Weeks 9–12 — the part that cannot be simulated#

1. Find a real user who is not you. A local charity, a small business, a team in another department. Run genuine discovery (section 8) and write the one-page scoping doc.
2. Ship something narrow on day one against their real data, in their environment, and get them to tell you it is wrong.
3. Run it for a month. Watch the adoption funnel. Write the value memo with the guardrail metric next to the primary one.
4. Hand it over. Write the runbook from your own incidents and teach someone else to deploy it. If you cannot, you have learned the most important lesson in this course.

36.4 Ongoing#

1. Practise decomposition weekly. Take any news story about an organisational problem and run the section 33 method out loud, in fifteen minutes. This is the round people fail and the only one that improves purely with repetition.
2. Keep a written STAR bank. Five stories where you owned an outcome end to end, navigated ambiguity, or worked with an external stakeholder. Write them out fully before you start applying.
3. Read three FDE job postings side by side — Palantir, a frontier lab, and an enterprise-AI company. The overlap is the real syllabus, and it moves.
4. Learn one domain properly. Claims, clinical pathways, supply chain, settlement. Domain curiosity is screened for, and it is much easier to demonstrate than to claim.