Forward deployed engineering in government and defense

This is the sector the model was built for, and the constraints here are the sharpest version of constraints that exist everywhere else.

Why the model started here

Palantir's early customers were intelligence and defense organizations, and the problem was that nobody could write a specification. The customer did not know what the software should do until they saw it working against their own data, so discovery had to happen inside the environment. The Palantir model covers the origin.

That condition still holds in this sector more than anywhere else, and the sector remains a large share of the market: 18 percent of postings that named a target industry. AWS also named government organizations explicitly among the focus areas for its own forward deployed engineering organization.

Constraint one: clearance

In most engagements, staffing is a question of skill and availability. Here it is a question of who is permitted to be present.

What it changes. The pool is smaller, so the profile is harder to fill and holds its value longer. Substituting a person mid-engagement is slow rather than routine. And the accumulated context in a cleared engineer's head is worth more, because replacing it takes months rather than weeks.

The practical planning consequence. Personnel continuity is a contract term rather than a courtesy, and the handover has to start earlier than elsewhere because the set of people who can receive it is constrained too.

Constraint two: the environment is disconnected

This is the one that surprises teams arriving from commercial work, and it invalidates a large part of a normal toolchain.

No package pull at build time. Dependencies have to be vendored and approved in advance, which turns adding a library from a decision into a process.

No hosted model call. If the work involves AI and the environment cannot reach the internet, the model runs locally under whatever constraints the hardware imposes. That changes which models are viable and therefore what the system can promise.

No external telemetry. Monitoring, error reporting and analytics all have to work inside the boundary. The observability approach most teams assume is unavailable, and observability matters more with generated code rather than less, which is why we wrote about why observability matters more with generated code.

Transfers are events. Moving code or data across the boundary is a scheduled, reviewed action rather than a push. That makes the iteration loop longer, which changes how much has to be right before a transfer.

The engineering response. Assume the constraint from day one rather than building for a connected environment and porting. A system designed for connectivity and then adapted carries assumptions in places nobody remembers.

Constraint three: procurement outlasts the technology

A procurement cycle can be long enough that the technology available at award differs from what was available at specification.

What that does. It creates pressure to specify tightly, in advance, in a document that will be out of date. Which is exactly the wrong shape for work whose scope is discovered by doing it.

The response. Contract for the outcome and the constraint rather than for the implementation. Specify what the system must do, what it must be able to demonstrate, and what environment it must run in. Leave the approach able to change without a new procurement.

That is easier to say than to get through a procurement office, and it is worth attempting, because the alternative is delivering a specification everybody knows is obsolete. Our page on outcome-based pricing covers how to write an outcome that survives, and the contract covers the terms.

What tends to go wrong

A demo built in a connected environment. It works, everybody is impressed, and it cannot be moved inside the boundary without a rebuild. The most expensive predictable mistake in the sector.

Dependencies discovered at approval time. A library that needed clearance nobody sought, found during the review that was supposed to be the last step.

A specification written before the technology was chosen, then defended past the point where anybody believed it.

Handover to a team that cannot be assembled. The inheriting people need clearance too, and if that was not planned, the system stays with the vendor by default, which is the dependency failure with an extra excuse attached.

Where AI-native delivery helps and where it does not

Helps: a specification written to the level that tooling generates from is exactly what a procurement wants, and an eval suite derived from that specification is exactly what an accreditation review asks for. The artefacts the process demands are artefacts this way of working produces anyway.

Does not help: if the environment cannot reach a hosted model, code generation has to happen outside the boundary and the output has to cross it as a reviewed transfer. That is workable and it is slower than the commercial version, and anyone claiming otherwise has not done it.

And the rule that matters most here: generated code is not secure by default. In an accredited environment the checks proving behaviour have to be derived from the requirement and graded independently of whatever wrote the code. Eval-driven development is the method, and here it doubles as accreditation evidence.

Related: regulated industry software for the cross-sector version of these constraints.