Hiring AI specialists or bringing in consultants can help an organization adopt AI. But the work also depends on the people who understand its processes, exceptions, and constraints. Giving those domain experts the skills and authority to shape adoption is an investment that deserves much more attention.
An organization becomes AI-native when it builds the processes and practices needed to automate and optimize work through AI. This isn’t a one-time transformation but an ongoing effort. It requires people inside the organization whose job is to continuously identify high-value opportunities where AI can automate or augment existing work, and crucially, this demands deep domain expertise. The people who understand a workflow deeply enough to spot a real opportunity are usually the same people who can describe it in enough detail to redesign it. Separate those, and you get use cases that look promising on a slide but fall apart in practice.
Think about the most experienced person on your team. Now think about how much of what they know is actually documented. That gap is the entire argument.
Why outsourcing ownership fails
External specialists can contribute technical expertise and challenge assumptions. The failure mode is asking them to identify and own opportunities without sustained involvement from the people who do the work. Tacit knowledge—the edge cases, unwritten rules, and failure modes—takes deliberate effort to uncover. A short engagement should strengthen internal ownership, not substitute for it.
An organization can buy platforms and specialist support while retaining ownership of its processes, priorities, and acceptance criteria. That distinction matters: delegating implementation is different from outsourcing the judgment needed to decide whether the system is doing useful work.
The AI process designer
This makes investment in existing employees essential. One particularly valuable role is what I’ll call the AI process designer: a domain expert who can help redesign work with AI.
In some ways the role looks like a traditional business analyst. I’ve worked with people in insurance companies who had a remarkably deep understanding of their processes and their domain, and could explain every step in great detail. That kind of person is exactly who you want here. They map a process from start to finish, formalize the sequence of steps, identify the resources required, and surface the interaction points between systems and people.
But the AI process designer needs to think about a few things a traditional analyst doesn’t. They have to decide where humans need to stay in the loop, what I’ll call HITL gates (human-in-the-loop checkpoints where the AI proposes and a person approves before anything irreversible happens). They have to figure out what external context the AI system needs to do its job, because an AI without the right knowledge will confidently produce nonsense. And they have to make architectural decisions about how that knowledge is incorporated into the system.
This is where some technical fluency becomes non-negotiable. The process designer needs to understand how to use MCP (the Model Context Protocol, which is becoming the standard for giving AI systems access to APIs and tools) to integrate the AI with the company’s existing systems. They need to understand how RAG (Retrieval-Augmented Generation, where an AI looks up relevant information from a knowledge base before answering) works, so they can decide when and how to give the AI retrieval capabilities. They need to know how agent skills (packaged instructions and resources that teach an AI how to handle a specific kind of task) can be used to capture domain knowledge and edge cases in a form the AI can actually use.
This work combines domain expertise with enough technical fluency to design alongside AI engineers. The domain expert brings the process knowledge; engineers help turn that knowledge into a dependable implementation.
What real upskilling looks like
There’s a temptation to think AI fluency is something employees can pick up by playing with ChatGPT for a few hours. It isn’t. That kind of casual exposure leaves people with half-hearted, superficial knowledge, the kind that produces statements like “the AI learns with every interaction” (it doesn’t, not in the way they mean). Half-knowledge is worse than no knowledge here, because it leads to confident, bad decisions about where AI fits and how to deploy it.
Real fluency means understanding how large language models actually work, what an agent is, and how it differs from a chatbot, how tool calling works, what MCP is, how RAG works, what document embeddings are, how prompting works, what context engineering means in practice, and how to design agent skills (and why they work so well when designed properly).
A focused training program can give domain experts a useful starting point. For example, six weekly sessions with protected practice time could take participants from basic concepts to a prototype of a familiar workflow. The result depends on prior knowledge, the task, and continued support. No-code tools and generative AI make experimentation more accessible; production use still requires engineering review and evaluation.
The objection worth addressing
One reason this approach can fail has little to do with employees’ ability to learn. It’s that companies launch half-hearted AI initiatives, push them onto already-overloaded teams, and then wonder why nothing changes. Employees in those situations rightly point out that the training is taking time away from their actual work without producing real efficiency gains. They’re not wrong. They’re responding to a bad strategy.
If you want this to work, you have to commit to it. That means real time blocked off for learning, real authority given to the people doing the upskilling, real budget for the tools and infrastructure they’ll need to experiment, and real patience while the first attempts produce mediocre results. The companies that treat this as a checkbox exercise will get checkbox results.
What this means for decision-makers
If you’re a decision-maker, team lead, or somewhere in middle management, the implication is concrete. The highest-leverage thing you can do is identify the people in your organization who already have deep domain expertise and the curiosity to learn new tools, and invest seriously in turning them into AI process designers, not by sending them to a half-day workshop, but by giving them real time, real training, and real ownership over the AI initiatives in their area.
Give the people who understand the work a meaningful role in changing it. External expertise is most useful when it helps those people build a capability the organization can sustain.