The Workshop

An AI training workshop has exactly one job: move a room from hearing about a capability to performing it. Which makes the unit of work much larger than a deck. It's the room diagnosis, the learning sequence, the software attendees touch, the operating plan for the live hour, and whatever support follows it.

This drawing documents the system I use to get that result, built out of work I've actually shipped: conference labs, an internal training, a Claude Cowork session, and a private glossary application for a mixed corporate audience. The details change with every room. The circuit stays recognizable. Define what people should be able to do. Build the artifacts that let them do it. Rehearse the path. Capture where they struggle. Keep helping after the chairs are stacked.

The standard I hold it to is observable capability. A workshop worked if attendees leave with a working result they can inspect, rerun, and extend. Everything else — the curriculum, the run of show, the engagement around it — falls out of that one commitment.

A talk transfers a point of view, and a good one is worth a lot: it changes what a room notices, gives people language for a problem, and creates enough energy to act on it. A workshop takes a harder assignment. It has to transfer enough capability that people perform the work while the facilitator is still standing there.

That difference changes what you build. Slides become one interface in a small product. Setup is onboarding. Exercises are the core interaction. A visible finish line is the acceptance test. Questions are user research. The repo, glossary, and recap are retention mechanisms. The session itself is one scheduled release.

At the 2026 AI Engineer World's Fair in San Francisco, conference founder swyx told Nick Nisi and me that our workshops were "the gold standard" for AI Engineer content, and asked for help raising the bar across the rest of the event. Nice to hear, and the work under it is the part worth describing: a hand-built deck served to phones, a real-time room board, a glossary with chat, a local coach, and exercises with failing checks. The hour onstage sat on top of shipped software. The original account describes the five principles and artifacts^[1].

Thinking of it as a product also hands the facilitator a sharper completion test. "The audience understood agents" is impossible to inspect. "Each attendee ran a typed workflow, saw structured output, and knows where to change one step" is something you can watch happen in the room. The second sentence tells you what to build and, more usefully, what to cut.

The first design material is the room itself: roles, prior exposure, devices, permissions, terminology, and the work people are hoping to change. You need to know who's going to be there and what access they'll have long before you pick an example. An engineering conference where everyone brought a personal laptop supports a completely different lab from an internal session with managed machines and mixed functions.

For a GHX Collaboration Week workshop, the audience ran from leaders who had never opened a terminal all the way to advanced engineers. The glossary said so out loud: four out of five people in that room had never opened one. A single middle-of-the-road track would have made the opening hostile to the beginners and the ending boring for the experts. So the path started at basic computer vocabulary, walked through AI terms, and climbed toward agents, verification loops, and orchestration.

The design contract is one sentence: After this workshop, the room can _____. Fill it with a verb somebody can demonstrate — run, build, inspect, compare, schedule, publish. "Understand AI" gets you a survey. "Build and rerun one approved workflow against a real team task" gets you a curriculum.

Then go inventory the constraints. Can people install packages? Will API keys be there? Is the network dependable? Which source material is safe to use? Does the room share one baseline task, or do departments need their own examples? Those answers decide whether the lab runs locally, in a browser, through a prepared repository, or as a facilitator-led build with parallel non-coding work.

A discovery call is more useful when you ask for examples instead of adjectives. "Mixed experience" might mean one team has used chat while another ships agents, or it might mean everyone uses the same tool with wildly different confidence. Ask what people do today, where the work stops, what's already been tried, and which result would matter to their manager. Then ask for the operating constraints in plain terms: device policy, identity provider, model access, repository host, browser restrictions, approval boundaries. Skip that and you'll build a curriculum around access the attendees are never going to get.

The core product is a circuit of artifacts, each one assigned to a moment before, during, or after delivery. The deck carries the teaching sequence, and serving it as an application lets attendees open the same frame on a phone from a QR code instead of photographing a screen forty feet away. The live board turns room check-ins into shared evidence. The glossary gives an unfamiliar term a quiet path to resolution. The repository supplies executable work. The recap puts the whole system back together after the event.

Every element has to earn its maintenance cost. The live board earns its place when the session needs the room to see its own before-and-after movement. A glossary earns its place when terminology is what's blocking participation. A repo earns its place when installing, modifying, or rerunning matters to the outcome. Nobody has to build all of them every time. What can't be skipped is that each artifact you do build solves a named part of the learning path.

Give each one an owner and an acceptance check. The phone deck has to load on venue Wi-Fi and stay legible with no presenter narrating it. The glossary has to answer from approved material and offer a human route when it can't. The repo has to install from a clean machine, state its prerequisites, and carry a known-good result. The live board has to degrade gracefully when someone skips check-in. The recap has to point back at canonical artifacts instead of copying fragments that will drift out of date. Those are product requirements, because a workshop audience meets them as users.

Durability is what should drive the design decisions. A screenshot records the presenter's success. A repository lets the attendee reproduce it. A PDF freezes a deck in place. A deployed glossary can still take a question three weeks later. The test I keep coming back to: what will this person open on Monday, when the facilitator is gone?

Mixed rooms usually fail before the exercise even starts. Someone hears three unfamiliar terms in the first minute, concludes everyone else already knows them, and stops asking questions for the rest of the hour. Psychological safety needs an interface. Saying "no dumb questions" from the stage is not an interface.

The GHX workshop made it structural instead. Attendees could ask out loud or use an ask-anything chat built into the glossary. The chat answered from the glossary's own contents, in plain language, and logged the question. Anyone who didn't want to reveal a gap in front of colleagues still had a way into the material. The room got a question channel; we got a record of exactly which language was causing friction.

From there the curriculum moved in a deliberate order: ground rules, a de-jargonification walk, guided practice, independent construction, and an advanced extension. Each stage clears a different obstacle. Ground rules cut social risk. Vocabulary cuts semantic risk. A guided block proves the environment works. Independent work creates ownership. Extension work keeps the experienced engineers busy without making beginners skip the foundations they need.

De-jargonification is precise technical work, not a warm-up. Swap the dense term for a plain definition, show the object it names, then use the formal name consistently from that point on. Don't hide the language people will run into at work — hand them a grip on it before asking them to reason with it.

Check comprehension through use rather than recital. Ask an attendee which tool should handle a given task, or what evidence the agent just returned, or where this workflow could fail. A correct choice tells you the term went operational. The same wrong choice showing up repeatedly tells you which definition or demonstration needs another pass. Keep the glossary open through the whole lab, so looking something up reads as competent work instead of proof that somebody missed the lesson.

A lab needs a real input, real state changes, and an output worth keeping. Lorem ipsum can prove a button renders. It can't teach the judgment you need to use a system at work. So the workshop repository should hold the smallest honest version of the production pattern, with setup instructions and completion checks you can see pass or fail.

At the 2025 AI Engineer World Fair, more than 70 engineers spent two hours building an agentic meme generator in TypeScript with Mastra^[2]. The subject was a joke; the system wasn't. One step used structured generation and Zod schemas to pull out workplace frustrations. Another fetched meme templates from Imgflip. A generation step produced typed captions. The last step called Imgflip's caption API and handed back a stable image URL. Modular steps, schemas, model output, external API behavior, and failure paths, all inside a result attendees could run again on the train home.

The Cowork workshop used a different lab shape entirely^[3]. In one hour, attendees built a go-to-market pipeline across seven modules: prospect identification, competitive intelligence, positioning, personalized outreach, blog content, a four-week calendar, and a scheduled publishing task. All seven lived in a single Cowork session. The prospect data fed the competitive work, both of those informed positioning, and that accumulated context fed outreach and content. The session history was itself the architecture lesson.

Those two labs look nothing alike and share three properties. The output is recognizable — a shareable meme, a working GTM pipeline. Each step exposes a transferable pattern instead of touring a product. And the attendee keeps the implementation and can run it again. Internal training follows the same rule: the Claude skills session^[4] handed out a version-controlled skill with plain-language instructions, code, configuration, and setup notes, so colleagues could install and adapt the workflow after the training ended.

Design the repository so it reveals the learning boundary. Put the finished infrastructure and the irrelevant plumbing on the starting branch. Leave the target decision visible — a schema to complete, a step to connect, a prompt to constrain, a verification rule to add. Drop a checkpoint after each block so an attendee can confirm their state before carrying an error forward into the next one. Keep the final code available on a separate branch or tag, and make sure the normal path still runs through the work you intended. The attendee should be able to say what changed and why. Watching npm install finish teaches nobody anything.

The run of show is an operating document, not a rehearsal aid. Every block needs a start, a stop, an owner, an attendee action, and a recovery route. Put the promised outcome at the top of the page. Mark the sections you can compress without breaking the learning chain. Keep a known-good branch, prepared outputs, and direct links within reach. And decide in advance who's watching the room while the other facilitator drives the screen.

Read pacing off evidence, not presenter instinct. Completed commands, changed files, generated artifacts, hands that stay raised. Ask the room for a visible status signal instead of guessing. If a lot of people are blocked, stop and repair the shared dependency — that's a system failure, not a room failure. If a few are blocked, a circulating facilitator or a paired path keeps the main rail moving. Announce the time caps out loud so attendees know when to keep trying and when to take the recovery path.

Live failure is genuinely useful as long as it's bounded and narrated. Say what you expected, show the evidence you got instead, form one hypothesis, test it. That's professional debugging, performed. When the repair starts threatening the next learning block, switch to the known-good state and save the failure for the recap. The workshop is there for the room, not for the presenter's determination to win an argument with a dependency in front of 150 people.

That switch needs explicit authority behind it. Before delivery, decide who can call the fallback and what triggers it: a shared authentication failure, an external API outage, too few completed checkpoints to keep going. Name the transition out loud so attendees understand they didn't cause it. Show the prepared output, explain which work it's standing in for, and pick back up at the next decision point. A fallback preserves the causal chain of the lesson. Silently jumping ahead leaves the room unsure which state is even real.

Questions belong in the run of show too. Capture each one with its topic, where in the curriculum it landed, and whether it got answered live. The GHX chat wrote questions and answers to a durable log, which turned private uncertainty into usable post-event signal without anyone having to remember every exchange.

Follow-through starts during design, not after the event. Name the support window, the channel, the response expectation, and the artifact owner before delivery. Put all of that in the repository and the leave-behind, then say it again at the close. Attendees should know exactly where to ask when they take the pattern to a real task that fights back.

The GHX glossary promised asynchronous support from the June 17 workshop through July 1. The page stayed live, the chat stayed available, and new terms could go in during that window. A fixed deadline made the support concrete rather than vague and unbounded. It also gave us a period long enough to tell a one-off setup failure apart from a recurring gap in the curriculum.

Keep the post-event report plain: questions grouped by topic, steps where people got blocked, artifacts completed, items still unresolved, changes worth making. Then send the answers, patch the setup instructions, add the glossary term that was missing, and publish a recap linking the deck, the repo, the outputs, and the recording if there is one. The Cowork recap^[5] does that publicly; an internal engagement uses the same structure inside the client's systems.

Then test the outcome sentence. The evidence can come from completed repository checks, submitted artifacts, a rerun during the support window, or a short follow-up demonstration. Attendance and satisfaction scores describe reach and experience, which is worth knowing and is not the same thing. Neither one proves the room can perform the task you promised. Measure the action.

Report the evidence at the right level, too. An individual exercise can record whether its check passed. A team workflow can record whether a second person installed and ran it from the documentation alone. A leadership session can ask participants to compare two proposed uses and identify the access, verification, and ownership each would need. Leave names out when the purpose is curriculum repair rather than performance management. And keep environment failures separate from conceptual gaps in the report — they need different fixes and they mean different things for the next workshop.

An engagement follows the same sequence as this drawing. The scoping call identifies the room, the current workflow, the access constraints, and the business reason for teaching any of it. That conversation is what produces the outcome sentence. The outcome then determines the artifact plan — maybe a browser-based deck and a guided workflow for a mixed group, maybe a typed repository with verification gates for a room full of engineers.

Build proceeds around the riskiest attendee action. Setup gets tested on the devices and permissions people will actually have. Exercises get rehearsed against real services, or approved substitutes for them. The run of show names the timing, owners, checkpoints, and fallback states. Delivery alternates short teaching beats with room action. Follow-through ships the artifacts, supports application through an agreed window, and reports what the questions and the completed work revealed.

Plenty of it varies: room size, skill distribution, subject, security posture, venue, available time, artifact depth, support period. A conference session optimizes for fast onboarding and a shareable public repo. Corporate AI training may need approved data, a private deployment, multiple entry ramps, and an internal handoff at the end. The method holds across both because the outcome stays observable either way.

The final handoff names what the client owns and who maintains it — source repositories, deck source, prompts, schemas, setup instructions, recordings, question reports, recommended next exercises. It should also record the external dependencies and the date the material was last tested. Then a named internal owner can accept fixes during the support window and decide which artifacts graduate into normal team documentation. Skip that handoff and even a strong live session leaves behind an impressive folder nobody is responsible for running again.

See /workshops for current workshop formats and examples. To commission one for your team, file the RFP below with the room you have and what you want that room to be able to do. That's enough to start scoping.