Hey folks 👋
Two years ago, almost every AI-related conversation I had started with the same question: which tools should we buy? Today, the question I’m asked most, by Bootcamp participants and by the organisations I advise, is different: how do we build our own?
The build-or-buy question is one of the oldest decisions in business and IT: do we develop this capability ourselves, or pay someone who already has it? The standard answer is: buy what’s generic, build what makes you different and valuable.
If a capability is the same for everyone (payroll, email, an LMS), buying is cheaper, faster and someone else carries the maintenance. If it’s the thing that sets you apart, you build it, because a vendor’s version is by definition available to your competitors and runs on the vendor’s idea of how the work should be done. This is the logic of Prahalad and Hamel’s “core competence” argument (1990): keep in-house what’s core to your advantage, outsource the rest.
For most of its history, L&D has answered the question the same way: buy buy buy. This wasn’t a strategic choice so much as a practical one; L&D teams rarely had access to engineers, so building anything meant commissioning a bespoke e-learning agency, which was slow and expensive. The sensible move was to buy the stack off the shelf: an LMS, an authoring tool, a content library.
But this seems to be changing. More and more of my advisory work is no longer about helping organisations choose a vendor; it’s about helping their teams build their own AI tools, and build them well. Over the last couple of years I’ve watched several hundred L&D practitioners do it, and in this week’s post I share what they built, why, and what it tells us about what L&D actually needs from AI.
Let’s dive in.
Why L&D Teams Are Building Their Own
Looking across the build plans, four reasons come up again and again.
1. Building got cheap. A practitioner with no coding background can now build a useful tool in a custom GPT, a Gem or a Claude Project in about a week. Building no longer needs a budget line or an engineering team. It needs someone who knows the work and can write down how it should be done.
2. What’s for sale doesn’t cover most of the work. Most AI tools on the L&D market are course and content generators: upload a document, get a module, a video, a quiz. They make e-learning production faster, but e-learning production was only ever a small slice of the job. Nothing on the shelf challenges a training request before a course is commissioned, reads every piece of learner feedback rather than a sample, or gives learners practice that a course can’t. If you need those, you build them.
3. A bought tool runs the vendor’s method, not yours. Even where the market does sell the tool, it comes with one method and one quality bar for every customer. Practitioners want tools that follow their facilitation standards, their house style, their definition of a good objective, and that work from their own documents rather than the model’s general knowledge.
4. They want control over what the tool won’t do. A safety tool whose guardrails a user under pressure can’t strip out. A tool that stops and asks when a source is missing rather than filling the gap. A tool that drafts and hands back, rather than deciding. With a bought tool, those rules are the vendor’s, and you can’t see them.
So a new pattern is emerging. Teams are still buying the generic parts of the process: the LMS, translation, captions, video rendering. But they’re increasingly building the parts that make them good at their jobs.
A Tool of One’s Own
So, what do these tools look like in practice? I did some analysis and the tools that L&D teams are building first fall into three categories:
1. Tools that support the work before and after the course
This is the work the market barely touches, including deciding whether training, and specifically an e-learning course, is the answer in the first place, and finding out whether the learning experience achieved its goals.
Some real examples from my bootcamp:
Problem-definition bot: An AI assistant that takes a business problem or training request and rapidly assesses it: is this a learning problem at all? What's the most likely root cause, and what's the best solution, and why? It returns a one-page summary of what's known and what isn't, a recommendation with its rationale, and the questions to take back to the requester before anyone starts designing anything.
SME-interview prep bot: An AI assistant that reads the existing documents on a topic (procedures, old course materials, the brief) before a designer interviews a subject matter expert, and works out what's missing, unclear or contradictory. It returns a short, ordered list of questions for the SME, so the interview is spent on the gaps rather than on what's already written down.
Solution-design bot: An AI assistant that takes a defined problem and the goal it needs to achieve, and recommends how to get there: the right instructional strategy, the best mode of delivery (a course, a job aid, practice with feedback, coaching or a mix), and optimal assessments. It works from the team’s own research summary on what works and why, and cites it to justify every recommendation. It returns a recommended approach with an evidence-based rationale, the alternatives it considered and why it ruled them out, and the assumptions a designer should check before building anything.
Feedback-coding bot: An AI that sorts every learner feedback comment into themes, counts them, pulls quotes and returns an initial analysis for the designer to review and action.
2. Tools that make the learning experience more dynamic
While the market offers L&D tools to make more standard content + quiz courses faster, L&D teams are focusing on using AI to move beyond the standard course experience to make learning more dynamic, engaging and impactful.
Real examples from my bootcamp and consultancy include:
Role-play bot: An AI persona that plays a realistic character (on one programme, a sceptical community member in a water and sanitation project) so learners can practise a hard conversation as often as they need. It stays in character throughout and corrects the learner, in character, when they say something untrue. When the conversation ends, a second AI reads the transcript and returns a debrief the facilitator can use straight away.
Sales-simulation bot: An AI customer that sales reps practise with, built to respond to the sales methods their team is actually trained in rather than generic sales advice. It lets reps rehearse the approach they’ll be assessed on, and returns feedback on how closely they followed that method and what to try next time.
Safety-coach bot: An AI assistant that turns a site’s own safety procedures and equipment catalogues into step-by-step, voice-enabled coaching a worker can use at the equipment. It gives one step at a time, won’t skip ahead, and has its safety rules locked so no one working under pressure can remove them.
Practice-feedback bot: An AI that runs a practice conversation with a learner and gives feedback afterwards, keeping the coaching out of the conversation so the learner isn’t interrupted mid-scenario.
3. Tools that do L&D tasks to the team’s own methods, processes and standards
These are the tools closest to what vendors sell. The difference is what’s inside them: the team’s own sources, standards and way of working, rather than the vendor’s. Some real examples from my bootcamp:
Job-aid bot: An AI assistant that turns a site’s own manuals, spreadsheets and the relevant legislation into ready-to-use job aids for staff doing statutory building-safety checks. It works only from the documents it’s given, and when a source it needs is missing, it stops and asks for it rather than filling the gap. It returns a job aid with a disclaimer every time, with its safety rules locked so no one can edit them out.
Video-script bot: An AI assistant that turns rough notes or source material into an instructional video script for Colossyan, scene by scene, applying Mayer's principles of multimedia learning as it writes: one idea per scene, nothing that doesn't serve the objective, on-screen text that highlights rather than repeats the narration, key terms introduced before they're used. It returns narration, on-screen text and visual notes for each scene, plus a list of anything it cut from the notes and why.
An AI assistant that turns notes into instructional scripts & Mayer-aligned multimedia design instructions to upload to Colossyan Assessment-design bot: An AI assistant that takes a module’s learning objectives and designs the assessment each one actually needs, instead of defaulting to multiple choice: a scenario for a decision, an observed task for a procedure, a role-play with a rubric for a conversation. It returns an assessment plan objective by objective, with the format, marking rubric and pass standard for each, and flags any objective that can’t be assessed as written.
Editorial-review bot: An AI that checks drafts against the team’s house style guide and returns every departure, with the line and the rule it breaks, for the editor to decide on.
Step back from these individual bots and a pattern appear. The tooling that L&D is building for itself exists throughout the end to end workflow, and especially in the parts of the process that off the shelf tools don’t operate: analysis, design & evaluation.
For me, there are three key gaps between what’s being built for L&D and what they’re building for themselves:
1. L&D builds for quality, not (just) speed.
The problem-definition bot, the SME-interview prep bot, the solution-design bot: none of these produce a single piece of training content. What they produce is a better-informed decision about whether to build anything at all.
That’s a strange thing to spend a week building a tool for, unless you’ve realised the real cost was never writing the course. It was accepting the wrong requests, then spending weeks confirming a training need that a day’s proper analysis would have ruled out or reshaped. These tools don’t make that work faster. They make the team harder to fool, including by itself.
2. L&D moves away from the traditional content-and-quiz course.
A role-play bot, a sales simulation, a safety coach at the point of work: these aren’t better courses. They’re not courses at all. They exist to give learners practice and support at the moment they need it, not a module they sat through weeks earlier and mostly forgot.
Where the market’s AI makes the traditional format faster to produce, these tools skip the format altogether.
3. L&D encodes its own standards and methods, instead of adopting a standardised approach.
The job-aid bot won’t guess when a source is missing; it stops and asks. The video-script bot writes to a named set of learning-design principles, not whatever sounds fluent. The assessment bot matches the format to the objective, rather than defaulting to multiple choice because that’s easiest to mark.
Zoom out and a single direction starts to appears. The effort isn’t going towards producing more stuff: it’s going towards deciding better, designing better, developing better and evaluating better.
Closing Thoughts
To go back to where we started: there’s a tradition of buying technology to automate what’s generic, and building technology that makes us different and valuable. That’s not a new rule. It’s simply one L&D has never had the skills or resources to follow.
Generative AI has changed that. With the right training and the confidence to use it, an L&D professional can now build a working tool in a week, with no engineering team behind them.
I don’t think that’s a small shift: being able to build means being able to decide, test and innovate, on your own terms, at your own pace, without waiting for a vendor’s roadmap to catch up with what you actually want and need.
What’s perhaps most striking in all of this is the vastness of the space between what L&D people are building and what they’re being sold:
What gets built. Vendors build the artefact: the module, the video, the quiz. L&D builds the decision around the artefact: whether to make it, what it should do, whether it worked.
Why it gets built. Vendors build for a problem every customer shares, so the solution can generalise. L&D builds for a problem that doesn’t generalise: this organisation’s evidence bar, this team’s themes, this team’s definition of “good”.
What counts as success. Vendors optimise for throughput: more courses, faster. L&D increasingly optimises for restraint: fewer courses, because a tool talked the team out of building one, or replaced it with something a course could never do.
What the tool is trusted to decide. Vendor tools are trusted with production decisions and reviewed on the output. L&D-built tools are trusted with almost nothing: they draft, flag, and hand back what they couldn’t decide. A vendor tool’s job is to decide well. An L&D-built tool’s job is to know what it can’t decide.
There’s a version of the AI story where L&D is the department that gets automated: content is the thing AI is obviously good at, and content was, for fifty years, most of what L&D was seen to produce. On that story, the safest place to stand was close to the vendors, learning to prompt their tools a little faster and better than the next person.
But there’s a second story already under way, and it points in the opposite direction. Increasingly, the L&D teams making the most progress aren’t the ones getting better at using the AI tools they’re sold; they’re the ones who decided - and were empowered - to build their own.
Happy innovating!
Phil 👋
PS: If you want to develop the skills to build and test AI tools, apply for a place on my bootcamp.
