What does a forward-deployed engineer do in the first 30 days?

A forward-deployed engineer’s responsibilities in the first 30 days come down to one job: turning an AI pilot, or a business problem, into a system with a written definition of done and two named owners. The first two weeks are a diagnosis that ends with a signed production definition, or a written reason to wait. Weeks three and four start the build inside your own systems.

A forward-deployed engineer is an engineer who works directly with the client’s business and technical teams, determines what has to be built, and takes ownership until it runs.

This article is about the engineer: what they own each week, what they need from your team, and what you can check on day 30. How the whole engagement runs, gate by gate, is described in how a forward-deployed engineering engagement works. How OrNsoft offers the model is on our forward-deployed engineering page.

Key takeaways

• Days 1 to 14 decide. The diagnosis ends with a one-page production definition signed by your owners, or a written answer that the pilot is not ready.
• Days 15 to 30 build. Work starts in your repository, against your systems, under your access rules.
• Your team provides two owners, access and examples. Without them, the 30 days cannot start.
• Day 30 is checkable. A signed page, work in your repository and four written weekly reports.

What are a forward-deployed engineer’s responsibilities?

Job descriptions list skills. A buyer needs to know what the engineer answers for. In the first 30 days, that is five things:

1. Understanding the operation. Who uses the output, which decision it supports, and what happens today without it.
2. Writing down what production means. Scope, success criteria, the examples the system is measured against, security, approvals and the go-live date, on one page.
3. Building in your environment. Code in your repository, connected to your systems under the identity and permissions they require.
4. Preparing the reviews production needs. The security file, and the list of outputs a person must approve.
5. Reporting in writing, every week. What was done, what is blocked, and what is needed from whom.

The role itself, and how it differs from a product engineer or a solutions engineer, is covered in what is a forward-deployed engineer.

What happens in week 1?

Week 1 is people before code. The engineer meets the business owner and the technical owner, reads the pilot as it exists (code, prompts, data, the examples it was tried on) and maps the systems it would have to talk to in production.

The useful output of week 1 is a list of open decisions, not a prototype. In our experience, stalled pilots stop on the same few: how the system connects to live data, who reviews its security, how success is measured, which outputs a person approves, and who runs it afterward. We describe them in why AI pilots stall.

This is also where “bring us the problem, not the specification” matters. A specification written before anyone has seen the operation tends to describe the pilot. The engineer’s job in week 1 is to find out what the operation needs.

What happens in week 2?

Week 2 turns the open decisions into one signed page: the production definition. It fixes the scope, the success criteria in measurable terms, the evaluation set, the security constraints, the approval rules, and when the system goes live. The evaluation set is frozen at signature, so later results are measured against the same examples.

The page is signed by your two owners and by the engagement lead. If it cannot be written, the engineer says so in writing, with the reasons. That answer is a result, not a failure: it costs two weeks instead of another pilot. The sections are explained in how to define production for an AI system.

Public frameworks ask for the same discipline at this stage. The NIST AI RMF Playbook groups its suggested actions into four functions, and the first two, Govern and Map, are about accountability and context before anything is measured. ISO/IEC 42001 sets requirements for an AI management system inside an organization, including defined roles and responsibilities.

What happens in weeks 3 and 4?

The build starts where the system will run. The engineer works in your codebase and your target environment, not in a separate sandbox that someone has to port later.

Workstream	What starts in weeks 3 and 4	What it leads to
Integration	Connections to the systems named in the definition, under the required identity and permissions	Working integrations in your repository
Security review	The security file: data flows, hosting, access	The security file and questionnaire answers
Measurement	Runs against the frozen evaluation set	An evaluation report against agreed criteria
Approvals	Which outputs need a person’s approval	The approval matrix

Nothing is in production on day 30. The go-live date is the one written in the definition, after the system has been proven on live work.

What does the client’s team provide?

A forward-deployed engineer cannot invent an owner. These are the inputs that decide whether the 30 days move:

Week	What the engineer owns	What your team provides	What exists at the end of the week
1	Understanding the operation and the pilot	Two named owners, access to the pilot, its data and its users	The list of open decisions
2	Writing the production definition	Decisions on scope, criteria, approvals; examples for the evaluation set	A signed definition, or a written no-go
3	Integrations and the security file	Access to the target systems and the security contact	First integrations in your repository
4	Measurement and the approval path	Time with the people who will approve outputs	Evaluation runs and a draft approval matrix

In our experience, the delays at this stage are rarely technical. They come from an owner who is not named, or access that arrives in week 3 instead of week 1.

How are the first 30 days measured?

By what you can check, not by how busy the team looks:

• The production definition is signed, or a written no-go explains why.
• The evaluation set exists and is frozen, so “good enough” has a number.
• Work is in your repository, reviewed by your technical owner.
• Four written weekly reports say what moved and what is waiting on whom.

Engineering teams that run services in production work the same way: they agree on a measurable objective before they argue about results. The Google SRE book defines a service level objective as a target value or range of values for a service level measured by an indicator. The production definition plays that role for an AI system.

What should you do next?

If you have a pilot that works and has to run in production, start with the two names: who owns the result, and who owns the system. Then tell us about your pilot. One call is enough to know whether the first 30 days can start.