New Goals

The learning industry has a dubious history of trotting out buzzwords and declaring how learning will never be the same: “performance consulting”, “gamification”, “just in time learning”, and so on.

But while these buzzwords attempted to redefine or rebrand workplace learning, none of them changed the nature of work the way AI already has. In terms of impact, modern AI is less akin to “mobile learning” than to the invention of smartphones or the internet.

So, at the risk of sounding like another jargon peddler, here is the thesis, reduced to two Mad Libs substitutions:

• The learning experience gets replaced by the human + AI work system. The deliverable is no longer a course that prepares someone to do the work; it’s the configured system (people, AI agents, workflows, data) which gets the work done.
• The learning objective gets replaced by the systemic capability. We stop writing “by the end of this module, the learner will be able to…” and start writing “this system will reliably produce…” The intermediate step of training is largely cut out.

If that sounds abstract or superficial, consider how it fundamentally changes a familiar scenario:

A client comes to you saying their case managers need training on a complex intake process. The old move is to ask what the case managers need to do, identify the gaps preventing them from doing it, then design a learning intervention to close that gap. The new move is to ask which parts of this process should be performed entirely by humans, which can be automated by an AI system (or a traditional software application), and which parts should involve interaction and co-work between humans and AI. 

Only after answering those questions do you know whether any human needs “training” at all. And even if they do, it will likely be smaller and more targeted than we’re accustomed to: perhaps just a quick video to get the human user onboarded with the AI system, or handing a checklist to the AI system itself. 

New Tools and Frameworks

Much of the current discussion about AI in L&D centers on using AI technology to develop traditional learning experiences faster and cheaper: prompting a chatbot to write a course outline, using an image generator to create illustrations, or having an authoring tool produce an e-learning module from source material.

There is nothing wrong with doing any of that, but it amounts to using a new technology to accelerate an old production model. Increasingly, the more important work will require us to leave our L&D bubble and master the AI tools used for accomplishing actual work, not just familiar chatbots like ChatGPT and Claude but agentic platforms such as Microsoft Copilot Studio, n8n, or our own Parrotbox platform, where designers can combine AI models, instructions, data sources, software tools, routing logic, user interfaces, and human approval steps into an operational system.

For an instructional designer, this requires learning a new design vocabulary. Instead of thinking primarily in terms of slides, activities, and courses, we have to think in terms of agents, context, tools, retrieval systems, orchestration, guardrails and escalation paths.

Some practitioners will learn to build these systems directly, the way I can edit video in Premiere and used to be able to code in Flash Action Script. Others will work more like traditional architects, specifying the intended behavior and collaborating with developers who handle the implementation. Either approach can work, depending on the scale and nature of a project. What matters is learning the technical aspects of AI well enough to make meaningful design decisions rather than abdicating those to the technical team.

We also need new frameworks that can bridge the cognitive / behavioral and technical aspects of AI system design. For instance, our team developed a framework for designing AI coaches that we call A-S-K: “Attributes, Scripts, and Knowledge.”

• Attributes: The professional standards and personality traits that shape how human coaches interact with users – when to be patient, when to push people out of their comfort zone, where to set boundaries. In humans, you develop these through a combination of hiring for aptitude and training. In AI agents, you have to specify them.
• Scripts: The procedural layer, not necessarily verbatim scripts for the AI agent to read aloud, but the sequences, decision rules, and specifications that constitute doing the job.  One of the architect’s most important jobs is deciding which parts of the script the model may improvise, which it should regard as non-negotiable, and which parts get enforced deterministically by the AI platform, outside the model’s vote.
• Knowledge: The data referenced by the AI system: facts, policies, product details, user profiles. In humans, this is the stuff of traditional training. In AI systems, it’s the stuff of curated knowledge bases and data integrations, and it’s the layer where the artifact-production skills of classical L&D transfer most directly.

The point of A-S-K is not to contribute one more acronym to the learning industry’s lexicon. It is to provide a way of representing competence that applies whether the actor performing the work is human, machine, or some combination of the two.

New Roles

All of this raises an obvious question: what does a learning professional do all day inside an AI-enabled organization?

At our company we call our upskilled instructional designers AI Solutions Architects, but the title matters less than the function: designing how competence gets distributed across humans, AI systems, and processes to produce an outcome. That doesn’t mean writing every line of code – like a UX designer shaping a product without touching the backend, an architect can build agents directly or hand specifications to developers. Roughly, AI Solutions Architect : AI dev team / UX designer : software dev team. But the remit is broader than UX, because the question isn’t just how a person interacts with an AI system – it’s how work itself should be divided across humans and machines.

A capable practitioner brings skills already familiar to serious instructional designers:

• Performance and competence analysis. What outcome is the organization after, what does good performance look like, and what’s blocking it? Then, which piece should the human know, which should the AI be instructed to do, which should be enforced by software, and which needs both to check?
• Audience analysis. A novice needs explanation and structure; a veteran needs only exceptions and concise decision support. AI can build that adaptation into the work itself – in one of our systems, the same agent gives different instructions depending on whether it’s paired with a rookie or a 20-year veteran advisor.
• Feedback and evaluation design. Before asking whether an agent “works,” someone has to define what working means, how closely it must match expert judgment, which errors matter most, and when a human should review or override it.
• Human factors and behavioral design. A technically correct system still fails if users don’t trust it, misread what it’s doing, or get buried in unnecessary approvals. Motivation, confidence, cognitive load, and resistance don’t disappear with AI – they become part of the architecture.
• Allocation of agency. Where should the AI advise versus act? Where is human approval essential, and where is it just ceremony? Which decisions can migrate toward automation as evidence builds, and which should stay under human authority?

These aren’t just technical questions: they’re questions about the design of work, and a rigorous L&D background is good preparation for answering them.

New Challenges

To show how this comes together in practice, our company developed an AI solution to help employment services staff find suitable jobs for autistic adults. The work system connected job sites (as a data source), social workers, and an AI agent.

Under the old paradigm, we might have produced a video, e-learning, or job aid with tips and tricks for searching job sites more efficiently. Under the new paradigm, we produced a system. The social worker drafts a profile of the job seeker based on their conversations with the person, then enters it into the AI system’s knowledge base.  The social worker and AI agent navigate relevant job listings sites together, but the agent does all the reading at light speed, then describes which jobs it would recommend and why (plus a one-line rationale for any jobs it rejected.)

Building this system exercised every muscle the AI Solutions Architect role requires:

• Benchmarking: Before trusting the agent with anything, we had to define what good performance looked like and measure the system against it. This included speed (calculating how long it took an unassisted social worker to find a suitable job posting for an average client) and quality (comparing how a top performing social worker and the AI system would evaluate the same set of job listings against the same client profile). It’s exactly the kind of analysis instructional designers are trained to do, but rarely get a budget for.
• Attributes: To shape the AI system’s decision making criteria, we consulted social workers and had them walk through their process of evaluating a job opportunity.  While our original assumption was that job requirements would be the most important factor (e.g. lifting, expectations for customer interaction), the social workers told us that jobs were more often disqualified because of transportation. We then spent some time testing the AI system’s ability to estimate how long it took to reach specific destinations in a given metro area based on a zip code and mode of transportation (e.g. car, bus or bicycle) at a given time of day, then compared that to our own knowledge of different commute routes.
• Scripts: We outlined the interaction between the human user and the AI system: how the AI would direct the human (open a tab, navigate to a job site, activate the screen reader, next page…) and where the human would direct the AI (“look at these job postings for warehouse associates and find ones that are suitable for Client X.”)  We eliminated user actions (typing, mouse clicks) where they didn’t add value and required them where human review and approval was essential. 
• Knowledge: Initially, our clients assumed the AI system would automatically pull in data from one or two job sites. However, after observing how the social workers actually sourced jobs for clients, we found that suitable jobs could come from anywhere (Indeed, LinkedIn, a government database, a company website) and we decided to have the system extract information via a browser extension that could scan any site a social worker found promising.
• Work Design: Perhaps the most radical aspect of the work system design was deciding who should use the AI system. Initially we assumed it would be the social workers, however – once we encoded their decision making process into the system and had them draft a client’s profile – it turned out an administrative assistant could operate the system, which was a good thing as our ultimate goal was to free up the social workers’ time for direct client interaction.
• Iteration and Maintenance: During the first deployment, we spoke with users and reviewed the session logs to identify where the system encountered friction (users not knowing what to type, the AI model recording incorrect links to job posts) then made small improvements to address them. At one point, after updating an AI model, the system started interpreting our evaluation criteria incorrectly and rejected any job that wasn’t conclusively a 100% perfect match. However, after tweaking its instructions, we were able to get even better performance from the new model. 

Conclusion

AI doesn’t change our agenda as learning professionals. We are still designing interventions to improve performance – breaking down tasks, clearly explaining them, incorporating feedback loops, measuring results – but instead of delivering a workshop and waving goodbye, we are now following our audience into the workplace and providing support at the moment of need. This was always our discipline’s founding ambition: AI just eliminated the excuse.

The “learning experience” had a good run: it encouraged us to think one step beyond content artifacts and consider how each touch point with a learning intervention would affect the learner. It was the right deliverable for an era when cognitive work could only be done by a human, and the only way to “program” humans at scale was to have them participate in a workshop or watch a video and hope the forgetting curve doesn’t set in before they are called upon to apply the knowledge. 

That era is ending, and the new era demands more from us. Practitioners who treat that as a threat will spend the next decade defending artifacts. The ones who treat it as the field finally getting the tools its ambitions always required will spend the next decade doing the most interesting work of their careers.