Forward-deployed engineering: build the system with the people who will use it

Begin beside the work

Picture a workshop in which the first exercise is simply to watch. A colleague opens a supplier document, copies a figure, checks a second source and asks someone whether an exception still applies. Nothing spectacular happens. Yet that short sequence contains much of the system we need to build: evidence, judgment, relationships and a decision that must survive being recorded. This is an illustrative scene, but a useful place to begin.

Forward-deployed engineering means putting engineers close enough to the operation to understand its constraints and change the implementation with the people using it. The useful unit of work is a real case carried from beginning to end. A presentation about what AI could do rarely exposes the awkward handoff, the missing permission or the record that has three conflicting versions.

Consider an illustrative operations team preparing supplier summaries. The first workshop should follow an actual approved example: where the documents came from, which figures matter, who checks the result and where the summary goes. The engineer watches the team’s existing method before suggesting a model or an agent. Some steps may need search, others a database query, and one may require a person’s judgement.

Practise checking the results

We propose building training around three kinds of case: ordinary work, a plausible mistake and an exception that should stop the process. A participant should be able to explain why the output is useful, identify what supports it and recognise when the evidence is insufficient. Completing an exercise quickly is less revealing than being able to challenge its result.

The Art of Programming is part of the ground behind this approach: Python and AI taught through projects that learners build themselves. In a company, that same habit becomes a short playbook, examples from the approved workflow and exercises that use the tools employees will actually have. A finance reviewer, a support colleague and a technical operator need different materials.

The customer-support study by Brynjolfsson, Li and Raymond studies AI assistance in customer support and finds that its effects differ across workers. That is evidence from a particular setting, not a promised return for another business. It is a reason to examine who benefits, who needs more support and what changes in the work, rather than reporting one adoption number for everyone.

The quiet risk of a convincing answer

A training programme can accidentally reward fluency. Someone learns a prompt, receives a polished paragraph and leaves with more confidence, even though their ability to inspect the result has not changed. The next exercise should interrupt that comfort: present an answer with one plausible but unsupported claim and ask the participant to show where it came from.

Lee and colleagues surveyed knowledge workers about AI use and critical thinking. Their findings concern self-reported effort and confidence; a survey cannot establish that AI caused a loss of ability. It does sharpen a practical question for training: which judgments are people still making, and which are they accepting without inspection?

Build exercises that require checking the model’s output. Ask a reviewer to choose between two sources with different effective dates. Ask a support colleague to explain an uncertain answer to a customer. Ask an operator to resume a stopped process without repeating a completed action.

A useful workshop ends with better questions from the people doing the work.

Let use change the implementation

A training session is also a design review. If several people misread the same status, improve the interface. If checking an answer takes longer than doing the task, revisit the retrieval or the output format. If a useful exception is invisible to the model, give the workflow a reliable way to capture it. Training should not become a way of teaching people to compensate indefinitely for avoidable product defects.

The human–AI interaction guidelines from Amershi and colleagues give this review useful structure: establish expectations, support people while they work, help them recover when the system is wrong, and allow adaptation over time. We use that as a design prompt. Where can someone disagree with the result, and what happens after they do?

Keep a small record of the cases that changed the design. Record the input, the expected action, what actually happened and the decision made together. Remove private details that are unnecessary for learning. Some cases belong in the evaluation set; others call for a policy clarification or a different ownership boundary.

Make independence observable

A practical handover asks a team to run a normal case, correct a flawed result and recover a stopped workflow without the builder taking over. The exercises reveal missing documentation more reliably than asking whether everyone understood the workshop. Assign someone to keep the materials current, and agree when the team can escalate to engineering.

For a pilot, compare accepted work, rework and review time against the previous process. Ask employees where the tool helps and where it interrupts them. Expand access when the evidence supports it, and update the training whenever the workflow changes. A growing login count alone does not show that the business has gained capability.

• Choose one real workflow and its owner.
• Practise success, error and recovery in approved tools.
• Turn recurring confusion into a product improvement.
• Check that the team can operate without the builder.

Leave something small enough to keep using

At handover, document the system’s limits, a few representative examples and who users can contact for help. Address the questions that came up during the work.

Schedule a discussion after the team has used the system independently. Review where they got stuck and decide what needs changing in the system or explaining more clearly.