What we mean by "workshop" here
The word workshop gets used loosely in most consulting catalogs, often as a euphemism for a slide deck delivered live to a room that would rather be doing something else. That is not what happens under this pillar. Every format listed below produces a specific, named artifact by the end of the session: a memo, a shortlist, a set of working prompts, a team that has actually built something. If a session cannot point to an output that outlives the room, it does not belong in this practice, and we would not call it a workshop.
The distinction matters because AI transformation work has a structural problem that generic training does not solve. Executives can align on a vision in a boardroom, and a strategy consulting engagement (see the Beratung / Strategy Consulting hub) can produce a defensible roadmap on paper, but neither of those activities forces anyone to sit with the actual friction of adopting large language models, agents, and automation inside a specific organization. That friction only shows up when people from different functions are in a room together, working on a real process, with a real dataset, in front of a real deadline. Workshops are where that friction gets surfaced deliberately, on a schedule the organization controls, rather than being discovered accidentally three months into a pilot that was scoped without it.
This is also why workshops are not "AI literacy training." Literacy training teaches concepts in the abstract: what a large language model is, what a token is, what an agent can and cannot do. Useful, but not what commissions this pillar. The four formats here are commissioned because a specific decision needs to get made, a specific list needs to get produced, or a specific team needs to leave the room able to do something they could not do when they walked in. The content is generic in the sense that the same four formats apply across industries; the output is never generic, because it is built from the client's own processes, data, and constraints during the session itself.
Why workshops sit between strategy and piloting
Picture the practice as three pillars, because that is how it is actually structured: Strategy Consulting, Workshops, and Pilot Projects. Strategy work answers the question of where an organization should be pointing its AI effort and why, at the level of business units, budget, and governance. Piloting answers the question of whether a specific solution works in production conditions, with real users and real data, over a defined test period. Workshops sit in the gap between those two, and the gap is wider than it looks from either end.
A strategy document can recommend "prioritize AI use cases in claims processing" without specifying which of the fourteen different sub-processes inside claims processing is worth automating first, who owns the data quality problem that will sink the pilot if it is not named up front, or whether the team that would operate the resulting tool even trusts the recommendation. A pilot, meanwhile, needs a scoped use case, a committed sponsor, and a working team before it can start, none of which strategy documents reliably deliver on their own. Skipping the middle step is the single most common reason AI initiatives stall after a promising strategy phase: the organization has a direction but no specific, de-risked starting point, and no one below the executive layer has been brought into the reasoning behind the priority.
Workshops close that gap by doing three things that neither a strategy engagement nor a pilot is built to do well. First, they force explicit tradeoffs between candidate use cases in a room where the people who will live with the tradeoff are present, rather than leaving prioritization to a spreadsheet scored by people who will not run the resulting tool. Second, they surface disagreement early and cheaply, before a vendor contract or an engineering sprint has made the disagreement expensive to resolve. Third, they build capability and muscle memory in the people who will need it for the pilot to succeed, which a strategy report cannot do and a pilot's kickoff meeting arrives too late to do properly.
Because of this position, workshops are frequently the first paid engagement for organizations that already have a rough sense of direction (sometimes from work they did with someone else, sometimes informally inside their own leadership team) but have not yet turned that direction into anything executable. They are equally common as the second engagement, commissioned right after a strategy consulting phase concludes, to convert the roadmap into the specific decisions and the specific people needed to act on it. Either entry point is normal. What is not normal, in this practice, is going straight from a strategy slide to a pilot kickoff with nothing in between; that is the sequence most likely to produce a pilot that technically ships but never gets adopted, because no one below the sponsor level was ever brought along.
The four formats and how they relate to each other
The four cards on this page are not four unrelated products picked off a menu. They map to four different failure points that show up at four different moments in an AI transformation effort, and in a typical multi-stage engagement they run in roughly the order listed, though none of them requires the others as a prerequisite.
Executive Alignment Workshop comes first when it is needed at all, and it is needed more often than leadership teams expect. Its job is to get the people who control budget and headcount into the same room and confront the fact that they are frequently not as aligned as their public statements suggest. One executive is thinking about AI as a cost-reduction program, another is thinking about it as a competitive differentiation program, a third is quietly worried about the reputational risk of getting it wrong, and none of these framings has been said out loud in the same meeting. This workshop does not try to talk everyone into a shared enthusiasm; it tries to get the disagreement on the table, name the actual constraints (budget, risk appetite, regulatory exposure, board patience), and produce a short alignment memo that becomes the reference document for everything that follows. Without that memo, later workshops tend to relitigate the same basic questions of ambition and risk tolerance, which is expensive and demoralizing for the working teams involved.
Use-Case Discovery Workshop is where most organizations spend the bulk of their workshop budget, and for good reason: it is the format that produces the artifact everyone actually needs to start building, which is a ranked, scoped shortlist of use cases. This is not a brainstorming session in the unstructured sense. It runs through the organization's actual processes, function by function, with the people who own those processes in the room, and applies a consistent set of filters (data availability, process volume, error tolerance, integration complexity, and the political reality of who would need to sponsor the change) to every candidate. It is common, and healthy, for this workshop to conclude that the use case leadership was most excited about is not the right one to start with, and that a less glamorous process is a far better first bet because the data is cleaner and the stakes of an early mistake are lower. The output, a prioritized shortlist with rough sizing on each item, is what typically becomes the starting brief for a Pilot Projects conversation.
Team Enablement Workshop answers a different question: not which use case to pursue, but whether the people who will operate the resulting tool are actually ready to. This format is commissioned by whoever owns the team that will be closest to the new workflow, which is often a different person than whoever commissioned the Use-Case Discovery session. It is hands-on by design. Participants work with the actual tools, on the actual tasks, under supervision, until the gap between "we discussed AI in a meeting" and "our team can operate this" has visibly closed. Where generic AI literacy training stops at concepts, this format stops only once people have produced real work with the tool in the room, which is also why it tends to surface concrete blockers (access permissions, data formatting quirks, workflow steps nobody had documented) that no amount of conceptual training would have caught.
Agent & Prompt Design Workshop is the most technical of the four and is usually commissioned once a use case has already been identified and a team is already committed to building or operating something specific, most often right before or during the early stage of a pilot. Its output is not conceptual; it is working prompt libraries, agent configurations, and evaluation criteria built against the client's own documents, tone, and edge cases, not generic templates pulled from a vendor's demo. Because it is the most concrete of the four formats, it is also the one most often revisited later, once a pilot has been running long enough to expose gaps in the original prompt or agent design that only real usage could reveal.
Read in sequence, the four formats trace a narrowing funnel: from "are we aligned as leadership" to "what should we actually do" to "can our team do it" to "how exactly does the tool work." An organization rarely needs to book all four in one continuous stretch. Many arrive already aligned at the executive level and only need Use-Case Discovery; others have a clear use case already but need their operating team brought up to speed before a vendor-led rollout, which is Team Enablement without the earlier two steps; others show up mid-pilot needing Agent & Prompt Design specifically because the first version of their agent is not performing well in production. The four cards exist as a menu precisely because organizations enter this stage of the practice from different starting points, and forcing everyone through a fixed four-step sequence would waste time for the ones who arrive already partway there.
Who typically commissions which format
The commissioning pattern tends to track organizational altitude fairly closely, which is worth naming because it affects how each workshop should be scoped and staffed on the client side.
Executive Alignment Workshops are commissioned from the top: a CEO, a COO, or occasionally a board-level sponsor who senses that the leadership team's public agreement on "we need to do something with AI" is thinner than it looks once budget gets discussed. The right participants are the people who actually control resourcing decisions, not their delegates, because the entire value of the session depends on the real decision-makers confronting each other's assumptions directly.
Use-Case Discovery Workshops are usually commissioned by a layer below that: a Chief Digital Officer, a transformation lead, or a business unit head who has been handed a mandate (frequently the output of an Executive Alignment session or a prior strategy consulting engagement) and now needs to turn it into something concrete enough to fund. The right participants are process owners and operational leads across the functions under consideration, because the shortlist that comes out of the room is only as good as the process knowledge that went into ranking it.
Team Enablement Workshops are commissioned closer to the ground: a department head, an operations manager, or an IT lead who owns the team that will be living with the new tool day to day. This is also the format most likely to be commissioned reactively, after a rollout has already stumbled because the operating team was never properly brought along, rather than proactively as part of a planned sequence.
Agent & Prompt Design Workshops are commissioned by whoever is technically accountable for the build, which might be an internal engineering or data lead, a product owner attached to a specific pilot, or occasionally an external vendor's counterpart who needs the client side of the room to define what "good" looks like for their specific documents and edge cases. This is the format where the client's domain experts (not just technologists) need to be in the room, because evaluation criteria for an agent are only meaningful if they are set by the people who can actually judge a wrong answer when they see one.
How workshop outputs feed the next stage
Every format on this hub produces something that is meant to travel forward, not something that stays in the room. That is the operating discipline behind the whole pillar, and it is worth being specific about what travels where.
The alignment memo from an Executive Alignment Workshop becomes the reference document that later workshops and any subsequent pilot get checked against, so that a use case someone objects to eight weeks later can be traced back to a tradeoff the leadership team explicitly signed off on, rather than relitigated from scratch. The use-case shortlist from a Discovery Workshop becomes the starting brief for scoping conversations, whether that means moving directly into a pilot, commissioning an Agent & Prompt Design Workshop against the top-ranked item, or, in some cases, going back into a strategy conversation if the discovery process revealed that the organization's priorities need revisiting before it commits resources. The trained team from a Team Enablement Workshop becomes the operating core of whatever gets built next: pilots run by people who have already handled the tool under supervision fail less often for operational reasons, simply because the operational reasons were already surfaced and worked through during the workshop rather than during the pilot itself. The prompt libraries, agent configurations, and evaluation criteria from an Agent & Prompt Design Workshop become the working assets that a pilot team actually deploys, refines, and measures against, rather than starting from a blank page or a generic template that has never been tested against the client's own material.
None of these outputs are meant to be filed away. If a workshop produces a document that no one opens again, something went wrong in how it was scoped, and the honest fix is to revisit the scope, not to schedule another workshop hoping for a different result.
Choosing where to start
If your leadership team has not recently had a direct conversation about what "AI transformation" actually means for your specific budget, risk tolerance, and competitive position, an Executive Alignment Workshop is worth doing before anything else on this page, even if it feels like the slowest option. If leadership is already aligned and the open question is which process to tackle first, Use-Case Discovery Workshop is the right starting point, and it pairs naturally with a prior or parallel strategy consulting engagement. If a use case is already chosen and the risk is that the operating team will not be ready when the tool arrives, Team Enablement Workshop closes that gap directly. If a build is already underway and the problem is quality, consistency, or trust in the outputs, Agent & Prompt Design Workshop is the format built for that specific failure mode.
For organizations unsure which of the four fits, or unsure whether workshops are the right entry point at all compared to a broader strategy engagement or a direct pilot, the practical next step is a short conversation rather than a guess. You can also use the AI Readiness Check as a lightweight, self-serve way to get a first read on where your organization sits before committing to a specific format. Explore the four formats in detail below, or get in touch to talk through which one matches where your organization actually is right now, not where a generic maturity model assumes it should be.
