The fastest way to choose is to name what must be true when the room empties: leadership aligned, a team with new skill, or a system up and running. Who is in the room and how much time you have confirm the call, and the choice is usually clear before you pick a date. The three formats are not interchangeable. Each one leaves a room in a different state, and each carries a hard limit that no amount of good delivery can push past.
When should you book a keynote?
You book a keynote when one slot on a crowded agenda has to bring a room of mixed roles to the same page: what AI does well, and where people stay in charge of it. It suits leadership offsites, kickoffs, an all-hands, or a conference slot. The talk pulls a whole room out of the abstract argument about AI and into a concrete one about the work in front of them.
Our keynotes and corporate talks are built for that job, and Dexter gives them himself. The examples come from systems he has built, and the framing stays human-first: AI as a tool the team runs, with zero people replaced. A room braced for a layoff pitch listens differently once that is off the table, and the spark you want comes easier when nobody is quietly wondering about their own job.
A keynote cannot teach a skill. Nobody walks out of a talk able to build something they could not build walking in, the good ones included. A keynote produces direction and appetite, nothing more.
What is a workshop for?
A role-based workshop gives people reps on their own tasks. Each person works AI into the job they already do instead of watching a walkthrough on someone else’s screen: marketing on marketing problems, ops on ops problems. They build the prompts and habits themselves, and those go home with them.
Group size cuts the opposite way from a keynote. A workshop wants a group small enough that everyone gets attention when they hit a wall, and someone always hits a wall. Those stuck moments are where the learning happens, so the small group is the point.
A workshop cannot ship a production system. It produces skill and momentum. A system that survives contact with your processes is a project of its own, and workshops that pretend otherwise are the ones that earn bad reputations. A strong workshop makes the eventual build faster and calmer, since the team arrives fluent. For teams that want backup while the new habits settle, 30 days of support is available as a paid add-on.
Who needs a bootcamp?
A team that has to leave with something built. The bootcamp is our flagship because it ends with a working system. Teams pick from a preset catalog of seven builds, and each team takes one all the way through in their own AI accounts. A fast team sometimes finishes a second. Because there are no demo environments anywhere in the build, the system is sitting in your accounts when we pack up, and the people who will run it are the ones who put every piece in.
The preset catalog exists so nobody burns the room’s hours on scoping. Custom scoping is settled before anyone books a room, so the session goes to building. The aim is one system, finished.
Thirty days of support comes included, because the first strange edge case tends to surface after everyone has gone home. A built system with nobody to call loses momentum fast.
A bootcamp cannot be light. It asks a team for sustained attention and hands-on work inside their own accounts, which is the wrong ask for a conference crowd or an all-hands. It builds one system, and only one. A tour of everything AI might someday do for your organization belongs in a keynote.
Do you demo live at events?
No. Every demo we show, in any format, is recorded from real builds and cut into the slides. Nothing about them is staged beyond the screen capture itself.
Live demos fail for reasons that have nothing to do with whether the system works. Venue wifi drops. Rate limits throttle without warning, and a model update can shift behavior you counted on. None of that says anything about the build. It is what the room remembers. Anyone promising your event live building should have an answer for what happens when the venue network misbehaves, and ours is that we never put the room in a position to find out. The room sees the system as it ran, and the session does not depend on anybody’s status page.
What if two formats both fit?
Most torn cases sit between a workshop and a bootcamp, and ownership settles it. Point to the bootcamp when one team owns a specific process and wants a system running inside it. Broader capability across a group, with the builds coming later, is a workshop. If you cannot name who runs the system in month two, it is not a bootcamp yet.
Room size breaks the keynote-versus-workshop tie. For a small, hands-on group, book the workshop. A room too large for everyone to work at a keyboard belongs in a keynote, where alignment earns its agenda slot. You can also combine the two: a keynote for the whole room, then a workshop for the team that carries the work forward.
Timeline is the quiet third factor. A keynote can land on shorter notice, since most of the preparation sits on our side. A bootcamp needs more runway, because the build happens in your accounts: access has to be sorted and the team’s calendar genuinely cleared before the session starts. Workshops fall between the two. Your date narrows the options without deciding the format.
What happens on the first call?
The call runs 30 minutes, it is free, and most of it is us asking questions. Come with four things ready:
- The goal in one sentence. What has to be true when the session ends?
- A rough headcount and the mix of roles in the room.
- Your date, or the window you are working inside.
- The person who will carry the result, alignment or a running system, into the months after.
All three formats are fixed scope, and the numbers come on that call. Based in Chicago, traveling wherever your team is. Once we hear the goal and the room, we will name the format we would book, including when it is the cheaper one.