Working notes
Forward Deployed Engineering
Working through the role, the process, and what it takes to bring an AI use case into a real workflow.
What I’m exploring
I’d start by understanding how the work really happens, then decide how it should work with AI. Each step gives me what I need for the next: audit, build, evals, deploy, observe, and improve.
How I’d work through it.
One step feeds the next. What I learn in use goes back into the work.
01 / Audit
I’d understand the real workflow and its exceptions first. That gives me an operating map and one worthwhile problem to build around.
Why the workflow comes first
The process someone describes can miss the exceptions they handle every day. An email might be forwarded, already resolved, or routed using knowledge that only one person has. I’d collect interviews, emails, spreadsheets, procedures, systems, and approvals before choosing what to build.
Why I map before I build
The operating map connects the current workflow to a proposed future version. I’d choose one worthwhile use case, define its boundaries, and estimate the value in time, cost, or errors. Then I’d decide where software handles predictable steps, where an agent gathers information or drafts, where a person approves, and where the record gets updated.
Why I check before I deploy
The build turns the map into something I can try. Evals show whether it has the right information, follows the intended steps, and hands off to a person when needed. I’d investigate failures before connecting it to the business. Deployment starts with existing systems, a controlled environment, and a small useful action. Observation then shows what to improve in the next pass.
Questions I want to work through
- How do you identify a use case worth building?
- What happens between the first prototype and a production deployment?
- How do you know the system is useful to the people using it?
Working notes. I’m continuing to develop and test this understanding.