Forward Deployed AI
Most organisations do not lack access to AI. They lack the ability to fit it into real work: inconsistent documents, old systems, informal approvals and the exceptions experienced staff handle without writing them down. This eight-part series treats the forward deployed engineer as an operating model rather than a job title, covering discovery that observes real work, deciding where intelligence belongs, the evidence that turns a demo into production, integrating with the installed estate, selling discovery honestly, building a team rather than relying on a hero, and starting the capability in 90 days. One fictional South African food processor and its delivery partner carry the examples.
8 articles
- Part 1The FDE is an operating model, not a job titleMost organisations do not lack access to AI. They lack the ability to fit it into real work. Part 1 introduces the forward deployed engineer as an operating model: what forward deployment is, what it is not, the two-direction mandate, when the model fits, and where the value really comes from.11 min read
- Part 2The process map is usually fictionDocumented work and performed work are different systems, and AI built from the documented one fails in daily operations. Part 2 covers discovery that observes real work, the operating map, asking for stories rather than requirements, capturing variants before designing automation, choosing the workflow worth changing, and what discovery should deliver.10 min read
- Part 3Where should intelligence live?The most important forward deployed decision is not which model to use, but where probabilistic intelligence belongs in the process. Part 3 covers the five execution modes, a plain-language decision test, the autonomy ladder applied step by step, designing human review that is more than an approve button, architecture by responsibility, model choice, and the design record.8 min read
- Part 4The demo is the beginningA prototype proves an agent can complete one task when everything goes right. Part 4 covers the stages from demonstration to bounded production, building for unhappy paths, the evaluation portfolio, a worked invoice-exception scorecard, observability as part of the deliverable, and production exit criteria.8 min read
- Part 5Build into the business you actually haveAn AI proposal that needs the ERP replaced before it delivers anything will meet justified resistance. Part 5 covers the five integration strategies, respecting the system of record, what 'we will integrate with the ERP' has to mean in practice, the strangler path for AI-enabled modernisation, and why adoption is part of technical delivery.9 min read
- Part 6Sell the discovery, not the fantasyThe way an AI engagement is sold shapes how it is delivered. Part 6 covers the engagement ladder, what a client should keep from discovery even if nothing is built, when free and paid discovery each make sense, pricing uncertainty honestly, a value case that separates realised from potential benefit, and the questions every AI proposal should answer.9 min read
- Part 7One hero is not a delivery modelThe 'million-dollar engineer' headline hides the system around the person. Part 7 covers the capabilities that make forward deployed work valuable, the pod that carries them, a hub-and-spoke practice that scales, how to measure the team, the career paths into the role, and why South Africa is a good place to do this work.8 min read
- Part 8Build the capability in 90 daysThirty days can create evidence, not mastery. The final part covers a 30-day build that lets a practitioner show forward deployed thinking, a 90-day organisational pilot, a maturity model, a readiness assessment, the architecture views an engagement needs, the red flags, and what good looks like after 90 days.10 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala