How to hire a forward deployed engineer: brief, work sample and acceptance
Start with the customer process that needs to change. Define the outcome, system access and the person who will accept the work. Then compare candidates using the same work sample. Below is a proposed method for choosing a permanent FDE or an engineer for a specific AI deployment.
A good brief reduces guessing on both sides. The candidate knows what to build. The company knows how to judge the result. This article describes my proposed approach. Adapt the example task and criteria below to your own process.
Define the role before choosing the title
A Neurons Lab listing makes the architect responsible for technical delivery and the Engagement Principal responsible for commercial scope and customer commitments. That is an explicit division in the employer’s job description. Your own team also needs named owners for those decisions.
In the brief, I would specify who talks to users, who writes code and who approves production changes. Then I would establish who supports the system after launch. One person can hold several roles if they have the time and authority required.
A title alone does not describe those boundaries. Comparing product-side and customer-deployment responsibilities helps establish the scope the company needs.
A permanent team member or one delivery engagement
A permanent role makes sense when the company has a continuing pipeline of deployments and wants to retain product knowledge in its own team. It also needs to provide management, access and cooperation from process owners. Buying an engineer’s time will not supply those conditions on its own.
An external provider can take on a project with a narrow scope. The brief should then define when the work ends, how it is accepted and what the customer’s team takes over. If maintenance stays with the provider, describe it separately. I would not assume that it follows automatically from the word deployment.
When there is no process owner or approved data access yet, I would start by defining the scope. That can be a short discovery engagement. Its outcome is a decision about what to build and which conditions must be met before implementation starts.
A one-page brief
The following example concerns a fictional support team. Prices, dates and acceptable error thresholds remain for the process owner to agree. The brief should let a candidate ask useful questions.
| Field | Example content |
|---|---|
| Process | A support team member reads a ticket, finds the relevant instructions and drafts a response. |
| Initial scope | The system suggests a response with its source. A support agent approves it before sending. |
| Access | A knowledge-base copy and a test ticket queue. Production access requires separate approval. |
| Acceptance | A shared case set, the current process’s results and agreed thresholds for the new solution. |
| Exclusions | No autonomous refunds, permission changes or messages sent to customers. |
| Handover | Code, tests, setup instructions, error monitoring and a rehearsed return to the previous version. |
For every field, I would name someone who can answer questions. Missing API access is a dependency for the system owner to resolve. The candidate should identify and describe it before presenting a delivery plan.
An agent’s action boundaries belong in the brief. I describe how to separate allowed, approval-required and forbidden actions using examples from company systems.
This is what I do hands-on: advising on AI strategy and building agents that survive the demo.
A paid work sample using a shared task
I would propose a short paid stage using synthetic data or data prepared for this purpose. Agree on time, payment and rights to the output before starting. The task should fit the time available and exercise the work the role requires.
Every candidate receives the same process description, test interface and constraints. They can ask questions. The team should share the resulting clarifications with everyone still completing the exercise.
For the support example, I would ask for a small slice: retrieve a ticket, select a source and draft a response for approval. I would include an API failure and a document that contains no answer. I want to see how the candidate describes the system’s boundary and demonstrates a case it could not handle.
AI tools can be part of the exercise if the rules allow them for everyone. The candidate should still explain their own decisions, check generated code and be able to change the solution during the discussion.
The Agentic Architect
Practical patterns, case studies, agentic projects taken apart and AI news. Zero spam, once a week.
You'll get one email to confirm. Unsubscribe with one click. Privacy policy
Assess decisions and evidence that can be checked
| Area | Evidence in the work sample |
|---|---|
| Problem discovery | The candidate identifies the user, missing data and prerequisites for a credible plan. |
| Integration | They show an ordinary request, an error and a retry. |
| Quality assessment | Expected results are recorded before testing. The report includes failed cases. |
| Access boundaries | Read access, writes and human approval are separated. The candidate explains what is logged. |
| Handover | Another person can run the example and reproduce a documented failure. |
These are proposed criteria, with no universal passing score. The company should identify mandatory conditions in advance. If a candidate violates an agreed access boundary, an impressive demo does not resolve that problem.
After the exercise, I would change one assumption. For example, the knowledge base contains two conflicting instructions. The candidate can explain what they would check and who should resolve the conflict. This conversation shows whether they understand their own solution.
Acceptance and responsibility after launch
I would end the first stage with a working slice of the process that can be inspected and tested. The next stage needs failure cases and access conditions checked. Production launch should have an owner and a path back to the previous version.
Before acceptance, another person starts the system from its instructions. They check an alert, reproduce an incident and restore the earlier version. The team also records who pays for model usage and who handles errors after the project ends.
If the company wants to commission this kind of work, the description of my AI implementation service for customer systems shows where the conversation starts. The brief is the basis for agreeing on the work and its price.
Before publishing a vacancy or sending a request for proposals, fill in one page of the brief. Name the process owner and the person responsible for access. Then define a task that allows candidates to be compared.
