What an AI Workshop for Executive Teams Actually Looks Like (From Someone Who Runs Them)

If you are considering an AI workshop for executive teams, the question you probably have is whether two hours in a room with your leadership actually changes anything. Most AI training gets delivered as a tour of tools and everyone leaves impressed and nothing changes on Monday. A workshop earns its keep when it takes one expensive process your team already runs and cuts the time it takes to do it.

I ran one of these this week with an agency founder and his full leadership team. Five people in the room. His lead strategist, his delivery lead, his senior analyst, and his EA. We had a single target going in. Their client audit took 20 to 30 hours to produce. He wanted it closer to three. By the end of the session he said the line himself. Thirty to three, in about an hour.

Here is how a session like that actually runs.

What is an AI workshop for executive teams?

An AI workshop for executive teams is a working session where a leadership group takes one real process from their business and rebuilds it with AI while everyone is in the room together.

The distinguishing feature is that nobody is learning about AI in the abstract. The team brings a process they already own, with all its messiness and institutional knowledge, and the session is spent applying AI to that specific thing until something moves.

The reason it goes to the executive team rather than one person is that the process usually crosses roles. In this case the analytical section belonged to the senior analyst, the delivery structure belonged to the delivery lead, and the strategic framing belonged to the founder. Any one of them alone would have rebuilt their slice and missed the actual opportunity.

What actually happens in an AI workshop for executive teams?

We spent the first stretch on the current state, in detail. What are the sections, who owns each one, how long does each take, where does it stall. Their audit had five sections. Some already had rough AI skills built, some had none. The founder had built his working backwards, on the model's own suggestion, and they were still heavy on manual cleanup.

That mapping is the unglamorous part and it is where the real information lives. Along the way we found that a lot of their existing AI work was saved locally on individual machines instead of somewhere the team could reach. That turned into a team-wide fix on the spot.

The middle of the session is where we ran the process against a few frameworks. The one that does the most work is 92/8. AI does 92 percent, the human does the 8 percent that only they can do. I put it as a sandwich. You go first, AI does the middle, you come back at the end. The question the team has to answer is what their 8 percent actually is. For this team the answer was clean. The 8 percent is the source data and the IP. The analysis and the judgment are theirs. Everything downstream of that, the writing, the formatting, the assembly, is the 92. That framing is the same 92-8 method I use to build any AI system and it decides where the effort goes.

Why does the deliverable get redesigned instead of automated?

This is the part that surprised the room, and it happened in the last thirty minutes.

The instinct with any process is to have AI produce the same thing faster. Their audit was a 46-page document, heavy on copy, that mostly functioned as a credibility builder and rarely got read again after delivery. We could have gotten AI to write those 46 pages in an hour. That would have been a faster version of something that was already the wrong shape.

What we landed on instead was a different output. The analytical section became an interactive dashboard rather than pages of prose, and because it is built on live data it also becomes the foundation for their ongoing monthly and quarterly client reviews. The analysis stops being consumed once and thrown away. The prioritization plan became the forward-looking part of the audit, built as a checklist and rating system where each item opens into a reusable container holding the templated answer plus links to reference examples from other brands.

His words afterward were that seeing those other versions was the unlock. Not the speed. The shape.

Who from the team needs to be in the room?

The people who touch the process, and the person who can decide.

Send one enthusiastic person to learn AI and bring it back and you get a translation problem. The person who learned it does not own the process, and the person who owns the process did not hear the reasoning. Getting a group to adopt something new has more to do with ownership than with training, and having everyone hear the same session is most of that battle.

In this session the analyst had already built skills for his section. The delivery lead knew exactly which parts of the audit clients ignored. The EA became the natural partner for the buildout because she has the time and the disposition for setup work. None of that comes out if only the founder is in the room.

What does a team walk out with?

Homework that is specific enough to finish. Ours came out as six items.

1. Install and populate the shared knowledge base as a team, structured by client folders plus a team folder, with one central inbox for transcripts.
2. Move every existing AI skill off local machines and into the cloud where the team can reach them.
3. Rebuild the audit skills from scratch in the coding environment rather than the lighter tool they had been using.
4. Build the AI-first version of the audit before the next session.
5. Map the post-audit operating system one skill at a time as phase two.
6. Pair people up. The founder and the EA take the ramp-up together rather than one person carrying it.

The thing I would flag for any team doing this is the skill-building nuance, because it is where most people lose quality. Do not accept the first version the model writes. Spell out the process step by step, exactly what you want at each check, and only then have it build the skill. Building the process is the actual work. Letting the model assume the process is how you end up with something that almost works and needs a human every time.

How do you pick the right first use case?

Ask whether the juice is worth the squeeze.

We used that question repeatedly during the session and it killed two ideas that sounded good. Some things are technically possible and cost more effort than the time they return. A good first use case has three properties. It happens often, it takes real hours, and the output has a clear definition of done.

That last one matters more than people expect. Every loop needs a clear close. Agentic AI breaks when the finish line is fuzzy, because the system has no way to know it succeeded. If you cannot say precisely what done looks like, the process is not ready to hand over and the workflow will add complexity instead of saving time.

Is an AI workshop worth it for a small executive team?

It is often worth more for a small team, because a small team can turn a decision into a change the same week.

One question I ask leadership groups reframes the whole conversation. Imagine a brand new AI-driven company enters your industry doing exactly what you do, with no attachment to how any of it has always been done. What does that company look like? Most teams answer that question with a knot in their stomach.

Then comes the flip. That company is you. You have the client relationships, the data, and the judgment that took years to build. Building the AI-first version of your own process is available to you right now, and it is the same question every CEO is going to have to answer.

How long does it take to see results?

The shift in thinking happens inside the session. The time savings show up over the following weeks as the team builds what they designed.

We went from a 20 to 30 hour process to a credible three-hour path in a single two-hour block. The design was done that day. The build takes longer, and the first pass will have gaps. Those gaps become the agenda for the next session, which is why I run these in a series rather than as a one-off. The places where the data is wrong, where the process hits a wall, where something cannot be done at all, those are the most valuable inputs you can bring back.

How to run this yourself

1. Pick the single process that costs your team the most hours per month.
2. Map it section by section with the people who own each part.
3. Name your 8 percent honestly. What genuinely requires your team's judgment?
4. Ask what this deliverable would look like if you designed it today from scratch.
5. Write the definition of done for every step before you automate anything.
6. Assign paired homework with a deadline before the next session.

The teams that get the most out of a session like this share one trait. They come in with a real number they want to move and a real process they are tired of. Everything else follows from that.

One, one, one, one. Run your process. Build the plan before you build the thing.