The AI shortage that matters is not models or AI engineers. It is people who can sit with a team, understand how the work actually gets done, and turn that into something reliable staff will use every day. The frontier labs already hire for this and call it Forward Deployed Engineering. A federation like YMCA Canada, with 37 associations and 24,000 employees, could easily surface hundreds of workflows worth redesigning, and each one still needs someone who understands the process well enough to get it into production. McKinsey has 88 percent of organizations using AI somewhere and only 44 percent scaling it. Deloitte found worker skills to be the top barrier to getting AI into existing workflows. Software scales instantly. The capacity to implement it grows one hire at a time.
I think we’re going to run short of people who can actually implement AI inside organizations. I don’t mean people who can use ChatGPT, and I don’t necessarily mean AI engineers either. I mean the people who can sit with a team, figure out how the work really gets done, and turn that into something reliable that staff will use every day.
The frontier AI companies already have a name for this person. They call them Forward Deployed Engineers, and OpenAI describes the job as running from discovery and scoping all the way through to production rollout. The model vendors are hiring these people to work directly with customers, which tells you something. Better models haven’t made implementation go away.
YMCA Canada is a good way to see the size of the problem. I ran national technology there for three years across 37 associations and about 24,000 employees. We ran one of the first enterprise AI pilots in the federation with Microsoft Copilot and ChatGPT. Fully deploying AI in an organization like that would not mean handing 24,000 people an assistant. It would mean redesigning how the work gets done, one workflow at a time.
Take child care. Registration, wait lists and subsidy administration each come with their own rules, their own systems and their own regulatory reporting. Before anyone builds an agent to help with subsidies, someone has to understand how each association handles it today, where they differ, which data is authoritative and who is allowed to see it. Fitness, camps and newcomer services are all different problems again.
If each association found just 10 workflows worth redesigning around AI, that’s 370 implementations. There would be a lot of overlap, and the smart move is to build shared capabilities once instead of the same accounts-payable agent 37 times. Even the shared version still needs someone who understands the process well enough to get it into production, and that’s a very different problem from buying licences.
Say it’s really 100 workflows over three years. An experienced team might take five of them from discovery to production in a year, which works out to 20 team-years of work. The exact numbers don’t matter much. The software scales almost instantly while the capacity to implement it grows one hire at a time.
Demand isn’t slowing down. McKinsey’s 2026 survey found nearly 90% of organizations regularly use AI in at least one business function, and 44% said they were already scaling it. Deloitte found the biggest barrier to getting AI into existing workflows was worker skills.
Technical skill on its own doesn’t close that gap either. An engineer doesn’t automatically understand child-care licensing or newcomer settlement services. The domain expert has to be on the implementation team, explaining what needs to happen, while the implementer works out how to make it reliable. More and more, the AI platform writes a lot of the software itself.
AI getting easier to use may actually make the bottleneck worse. A few years ago building an AI application meant a machine-learning team and months of work. Now a developer, or even a domain expert, can prototype one in hours. That means far more candidate projects, and every one that heads for production runs into the same questions. What’s the authoritative data? What happens when the model is wrong? What can an agent do on its own, and when does a person step in? How does the employee’s job change once the workflow does?
None of those are model problems.
The job market is starting to reflect it. PwC looked at more than a billion job ads across 27 countries and found postings that require AI skills grew 69%, compared with 9% for jobs in general.
A federation like the Y could have hundreds of these opportunities on its own. Multiply that by every bank, hospital and government ministry trying the same thing and the demand for implementers gets very large very quickly. I think the organizations that get furthest will be the ones that paired their own domain experts with a few good implementers early, and built each capability once for everyone to use.
Frequently Asked Questions
What is a Forward Deployed Engineer?
Someone who embeds with a customer and takes an AI use case from first conversation to production. OpenAI describes the role as covering discovery, technical scoping, system design, build and rollout. Palantir popularised the title years ago, and the AI labs have adopted it because selling a model is not the same as getting a model into someone’s daily work.
Isn’t this just what an AI engineer does?
No. An AI engineer builds the system. An implementer works out which system is worth building, who it serves, what data it can trust and how the job changes around it. Those skills overlap, but plenty of strong engineers have never had to sit with a front-line team and map how the work actually happens.
Why can’t a large organization just buy licences and let staff figure it out?
Because a licence gives people an assistant, not a redesigned workflow. Deloitte’s 2026 survey found worker skills to be the top barrier to getting AI into existing workflows, and that 84% of organizations had not yet redesigned jobs or workflows around what AI can do. Giving everyone a chat window is the easy part. Changing how registration, intake or subsidy administration runs is the work.
How do you avoid building the same thing in every region or business unit?
Build shared capabilities once and let each unit configure them. Nobody needs 37 versions of the same accounts-payable agent. The catch is that a shared capability needs someone who understands the process deeply enough to see where the real differences are and where the differences are just habit.
Where should an organization start?
Pair your own domain experts with a small number of good implementers and pick workflows where you already know the process and own the data. Get one into production and learn what actually broke. That is a far better use of a year than another round of pilots nobody adopts.