AI Adoption Doesn't Need More Classroom Training. It Needs Forward Deployed Expertise.

Most companies no longer need convincing that AI matters.

Employees are experimenting with ChatGPT, Claude, Copilot and dozens of specialised tools. Management teams are discussing AI strategies. Training providers are filling calendars with workshops, prompt-engineering sessions and inspiration days.

Yet many organisations still struggle with the same question a few months later:

Where is the measurable impact?

The problem is not necessarily a lack of AI knowledge. It is the gap between knowing what AI can do and applying it to the specific work, systems, constraints and priorities of an organisation.

That gap is why I believe an approach that has been gaining ground in the technology industry will increasingly move into consulting and professional services as well: Forward Deployed Engineering.

The name may sound technical. The principle is remarkably simple.

Instead of explaining AI to people from a distance, put someone with strong AI and business expertise next to the people doing the actual work.

Understand the work. Identify opportunities together. Prioritise them with management. Then build.

What is Forward Deployed Engineering?

Forward Deployed Engineering, or FDE, became known through technology companies such as Palantir and is now being adopted much more broadly across the AI industry.

OpenAI, for example, has built a dedicated Forward Deployed Engineering organisation. Its FDEs work alongside customers across discovery, technical scoping, system design, build and production rollout, with success measured through adoption and measurable workflow impact. EY launched its own Forward Deployed Engineer roles in the UK and Ireland in 2026, explicitly positioning them as a way to move AI use cases from experimentation into production.

The important part isn't the job title.

It is the operating model.

Traditional consulting often separates analysis, recommendation and implementation. A team analyses the organisation, produces recommendations, another team translates those recommendations into requirements, and eventually someone builds something.

With AI, that sequence can increasingly be compressed.

You can observe a process in the morning, prototype an alternative in the afternoon and let the user test it the next day.

That changes what good consulting should look like. (For a deeper comparison of FDE against agencies, freelancers and vendors, see What Is Forward Deployed Engineering?)

AI adoption starts on the work floor

Consider someone in sales who spends every morning combining information from an ERP system, emails and spreadsheets before deciding which customers to contact.

Or someone in operations manually reading incoming PDF orders and transferring information into another system.

Or a marketing employee researching prospects online and preparing personalised outreach.

Or someone in prepress spending hours going back and forth with customers to get files into the right format.

You can bring all of these people into a classroom and teach them about prompting, agents and large language models.

Some will leave inspired. Some will start using the tools. A few will become very good at them.

But you still haven't redesigned any of those workflows.

A Forward Deployed approach starts somewhere else.

Sit next to the employee and watch the work happen.

What information do they need?

Where does that information come from?

Which decisions require judgement?

Which parts are repetitive?

Where do they copy and paste?

What exceptions make the apparently simple process complicated?

Which systems are involved?

What data is sensitive?

What makes a customer or colleague call this person because "only they know how it works"?

These questions uncover opportunities that rarely emerge from an AI training session or a management workshop alone.

And there is another important advantage: the employee brings something the AI expert doesn't have.

Domain expertise.

The person performing the work every day understands the exceptions, customer behaviour, historical decisions, bad data and organisational context. The AI expert understands what has recently become technically possible.

AI implementation works best when you bring those two forms of expertise together.

A different model for AI implementation

At ScopeRight, the model we are developing is deliberately lightweight.

It doesn't start with a six-month transformation programme.

It starts with a short intake to understand the company's strategy, objectives, systems and current AI maturity.

Then the real work begins.

1. Intake: understand the strategic context

Before looking for AI use cases, you need to understand what the organisation is trying to achieve.

Is the priority growth?

Margin improvement?

Reducing administrative workload?

Scaling without adding headcount?

Improving customer service?

Shortening lead times?

Reducing dependency on scarce expertise?

AI opportunities should not exist in isolation from these priorities.

The intake therefore creates a strategic frame. It also identifies obvious governance constraints: sensitive data, security requirements, existing technology choices and initiatives already underway.

Without this step, AI programmes easily turn into a collection of interesting experiments.

2. Half a day alongside key employees

Next, an AI expert spends focused time with a small number of employees in strategically relevant roles.

Not interviewing them from a meeting room.

Actually looking at how the work is done.

Half a day can already reveal surprisingly much when the objective is not to document every process but to identify where AI could fundamentally change the way work happens.

The AI expert combines business understanding with enough technical depth to immediately recognise different solution patterns.

Some opportunities may require nothing more than using an existing AI tool properly.

Others may require connecting existing systems.

Some could be solved through a configurable agent.

Others justify a small custom application.

And sometimes the right conclusion is not to build anything, because Microsoft, Salesforce, Adobe or another platform is likely to solve the problem natively.

Independence matters here.

The objective isn't to sell a particular AI platform.

It is to find the best way to create value.

3. Build the long list of opportunities

The output is not immediately an enormous AI roadmap.

It is first a practical long list.

For every opportunity, you want to understand at least:

• What problem are we solving?
• Who experiences the problem?
• What does the current workflow look like?
• What could AI change?
• How large could the impact be?
• How difficult is implementation?
• Which data and systems are required?
• What are the security or governance implications?
• Should we buy, configure, build or wait?
• What would the smallest useful version look like?

This final question is particularly important.

Because instead of immediately defining the finished solution, you define a Minimum Viable Agent — an MVA.

From use case to Minimum Viable Agent

The MVA is to AI implementation what the MVP became to product development.

It is the smallest version of an AI-enabled workflow that can prove whether the idea creates real value.

Imagine a sales organisation with an ambition to create an "AI sales assistant".

That could become a massive project.

CRM integration. Email integration. Account research. Lead scoring. Meeting preparation. Follow-up. Forecasting. Proposal creation.

Instead, the first MVA might simply do this:

Every morning, analyse the available customer and prospect information and give each salesperson ten accounts worth contacting today, together with the reason why and a suggested opening message.

That is narrow enough to build.

And specific enough to measure.

Does the salesperson use it?

Is the information relevant?

Does it save time?

Does activity increase?

Does it lead to more conversations?

If the answer is yes, expand it.

If the answer is no, you have learned something valuable without spending six months and a large transformation budget.

4. Management debrief: select what actually matters

The long list then comes back to management.

This step is critical because bottom-up discovery without top-down prioritisation creates another familiar problem: dozens of interesting AI ideas competing for attention.

Management needs to make choices.

Which opportunities support our strategy?

Where is the economic value?

Which problems are genuinely painful?

Where can we learn quickly?

What shouldn't we touch yet because of security, data quality or dependencies?

Which initiatives should simply use an off-the-shelf product?

And which workflows are differentiated enough to justify something custom?

The result should be a small number of deliberately selected MVAs, not a catalogue of possible AI experiments.

That creates strategic alignment before development begins. (This is exactly what an AI Use Case Prioritisation & Scoping Workshop is designed to produce.)

5. Build in short MVA sprints

Once an MVA is selected, the Forward Deployed model doesn't produce another recommendation deck.

It builds.

Ideally in a sprint measured in weeks rather than months — the shape of a Minimal Viable Agent Sprint.

The employee who originally demonstrated the process remains involved throughout that sprint. They test early versions, explain exceptions, challenge assumptions and help shape the solution.

The MVA therefore evolves inside the environment where it will ultimately be used.

That has several important consequences.

Applicability is built into the process, because the solution originates from real work rather than a theoretical use case.

Strategic alignment is built in, because management chooses which opportunities deserve investment.

Results arrive early, because every selected opportunity has to become something usable rather than remain a recommendation.

And perhaps most importantly:

Training happens automatically.

The best AI training may not look like training

This is one of the aspects of the model I find most interesting.

Companies understandably feel they need to train their people in AI.

But sending twenty employees into a classroom for a day has a substantial cost.

Twenty people spending eight hours in training represents 160 working hours before anything has changed operationally.

And the transfer from general knowledge to day-to-day behaviour is uncertain.

Embedded implementation reverses that model.

Instead of first teaching people everything AI might be able to do, you teach them while solving a problem that matters to them.

An employee works alongside the AI expert.

They learn why one approach works and another doesn't. They see what prompting can achieve, what an agent is, where data becomes important, why integrations matter, what security constraints need to be considered and when a custom build makes sense.

More importantly, they start learning to recognise new AI opportunities themselves.

That creates a very different type of capability.

The objective isn't that everyone becomes an AI specialist.

It is that employees become better at combining their domain expertise with an understanding of what AI can now do.

This is the skill organisations really need.

From AI training to continuous transformation

There is another reason why the traditional training model is struggling.

AI changes too quickly.

A curriculum built six months ago may already omit important capabilities. Products that required custom development last year can become standard functionality this year. Costs fall. Models improve. Interfaces change. New agentic capabilities appear.

So AI capability cannot be treated as something an organisation learns once.

It needs a feedback loop.

Observe.

Identify opportunities.

Prioritise.

Deploy.

Measure.

Learn.

Then repeat.

Some companies will eventually develop this capability internally.

Others will continue to combine internal domain experts with independent external AI experts who periodically bring the latest technological perspective.

Either way, the capability itself becomes permanent.

This will change consulting

I expect this model to influence consulting far beyond AI.

For decades, consulting economics were partly built around scarcity: expertise was expensive, analysis took time, and implementation required large teams.

AI is changing those constraints.

Small teams with strong business judgement, deep domain knowledge and AI-enabled technical capabilities can increasingly move from problem to prototype at extraordinary speed.

The distinction between strategy consultant, technologist and implementation specialist therefore starts to blur.

That doesn't make strategy less important.

It makes the distance between strategy and execution much shorter.

The consultant of the future may spend less time producing recommendations about what a company should do and more time working alongside employees to determine, build and test how the company could actually work differently.

Forward Deployed Engineering is one name for that change.

For SMEs, I suspect the terminology will ultimately matter less than the promise:

Bring AI expertise to the work, rather than bringing the workforce to an AI classroom.

Start from real processes.

Combine domain expertise with AI expertise.

Align the opportunities with management.

Build the smallest useful solution.

Measure what happens.

And make the organisation smarter while doing it.

That, to me, is a much more compelling path from AI ambition to AI impact.

---

Curious what a Forward Deployed approach would surface in your organisation? Book a free 30-minute intake. We'll help you find the workflows where AI expertise next to the work — not in a classroom — creates measurable impact.