Understanding the forward deployed engineer role
Notes on requirements, system integration, and evaluation in forward deployed engineering, with connections to software development and deployment projects.
On this page7 sections
A forward deployed engineer (FDE) turns a user's business problem into a software solution. Palantir's official role description includes working directly with customers to understand their problems, then designing and implementing solutions.
These notes organize my understanding of the role around requirements, integration, and evaluation, with attention to the evidence each step should produce.
From requirements to a verifiable delivery
For a document question-answering system, the feature requirements, access rules, and acceptance examples need to agree. A demonstration alone gives limited information about how the system will fit a working process.
1. Clarify requirements and acceptance criteria
Start the discussion with concrete usage scenarios:
- What result does the user need? Can they provide an example of an acceptable answer?
- Which sources can support the answer, and what can each user access?
- Where does the current process get stuck, and who takes over when the system cannot help?
Turn the agreed questions, reference answers, and conditions into evaluation cases with clear acceptance criteria. Include missing information and insufficient permissions so the cases can expose inappropriate answers in those situations.
2. Integrate within the existing system's rules
Before connecting an identity provider, document store, or ticketing API, establish its data formats, access rules, and error handling. The retrieval code below illustrates permission filtering. Its helper functions depend on the actual system, and its parameters are example settings.
// Every retrieval call is scoped by the caller's effective permissions.
// If we can't resolve them, we fail closed — never open.
export async function retrieve(query: string, user: User) {
const acl = await resolveEffectiveAcl(user); // groups → document scopes
if (!acl.ok) throw new Forbidden("Could not resolve permissions");
return hybridSearch(query, {
filter: { scope: { $in: acl.scopes } },
k: 24,
rerank: true,
});
}Check that the caller's permissions constrain retrieval and that a failure to resolve permissions denies access. Tests should include documents the user cannot access and confirm that they do not appear in the returned results.
3. Check changes against the same cases
After changing a prompt, retriever, or model, compare results on the same evaluation cases and record the conditions of each run. The evaluation record can cover these questions:
| Check | Evidence to keep |
|---|---|
| Is the answer supported? | The answer, its sources, and a human review |
| Are permissions respected? | Test identity, permitted scope, and actual results |
| How long does a response take? | Latency recorded under the same conditions |
| What does a call cost? | Model and configuration, usage, and corresponding charges |
Record the test cases, environment, and calculation method alongside each measurement so comparisons can be checked.
Collaboration and delivery
Requirements and technical plans often need several rounds of discussion. A handoff should explain what works, which conditions remain unmet, and who will maintain the system. When scope or cost requires a tradeoff, document the options and their effects so the business owner and engineering team can decide together.
The feedback path back to product
Recurring delivery problems can become product feedback. Anthropic's official FDE role description includes documenting reusable deployment patterns and sharing findings with Product and Engineering.
Include the usage scenario, reproduction steps, and current handling in each report. That gives the team a problem it can verify and discuss, whether the next step is a product change, better documentation, or a different integration approach.
Related project work
For step-by-step practice, explore the FDE learning course. It uses a fictional employee knowledge and ticket assistant, with lesson notes, interactive self-tests and module cases. It is independent material, not official training or certification. Lesson text is currently in Chinese.
The Omnigate project notes describe customization based on new-api, deployment, and backup configuration. The As-a project notes cover permissions, payment logic, and local tests, along with the acceptance work still needed before opening real transactions.
End of article
Keep reading
