01The FDE Model
Forward deployed engineering is often described as consulting with better engineers. It is not. It is a specific claim about where software for a regulated institution has to be built, and by whom, and what that changes about the architecture.
A requirements document is a lossy compression of what an operator knows. The loss is not evenly distributed: what survives is the process as it is described, and what disappears is the exception handling that is most of the actual work.
An engineer sitting next to the person running the queue recovers that loss in days. No amount of discovery calls recovers it at all, because the operator does not know which of the things they do are surprising.
A weekly cadence is not a productivity habit. It is a forcing function on access. If a pod cannot ship something runnable in week two, the reason is almost always that access, environments or the control boundary are unresolved, and those problems do not improve with time.
So we treat the first shipped artefact as a diagnostic. It tells us whether the engagement is real.
Whether a system can produce per-decision reasoning is decided by the architecture, not by a later feature request. The same is true of whether a decision can be replayed, and whether an auditor can see what the model read.
This is why the boundary is agreed in week one with risk and security in the room. Not for governance theatre. Because it determines what we are allowed to build and therefore what we build.
Every serious institution we work with has the same reservation, and it is correct: a model that can act without review is an unbounded liability. The answer is not a better model. It is a system where the consequential step is structurally reserved for a named human.
Once that is true, the conversation changes from whether to deploy to where the leverage is. The leverage turns out to be enormous, because the expensive part of most decisions is assembling the evidence, not making the call.
We write the evaluation harness from the institution's own adjudicated history before touching a prompt. A public benchmark tells you how a model performs on someone else's distribution. It says nothing about yours.
The harness then becomes the release gate. A regression blocks the deploy, including when blocking it is inconvenient, which is the only condition under which a gate means anything.
A delivery model that can only end in a renewal is a dependency, not a capability transfer. We price and plan for both outcomes.
Handover means your engineers hold the repository, the harnesses and the runbooks, and we have watched them run an incident before we leave. If that has not happened, the engagement is not finished, whatever the contract says.
02Pod composition
A pod is small enough to hold the whole problem and senior enough that nothing has to be escalated to be decided.
07How engagements work
Handover is a first-class ending, not a failure to renew. If your engineers hold the repository, the harnesses and the runbooks, and we have watched them run an incident, the engagement worked.
A pod lands inside your estate, not beside it. We take read access to the systems the work actually touches, sit with the operators whose queue we are changing, and write down the control boundary before we write code.
Weekly ship cadence against your environment. Every agent gets an evaluation suite before it gets a user, and the suite is written from your own historical cases, not a public benchmark.
Production behind a gate, on a slice of real volume, with the rollback path tested before the first live request. Model risk and internal audit review the evidence pack we have been generating since week two, not a retrospective write-up.
We run it, or we hand it over. Both are real endings. Handover means your engineers hold the repository, the evaluation suites and the runbooks, and we have watched them run an incident before we leave.
Next
If you disagree with any of the six, that is a good first conversation.