Written out in full, so you can judge whether it's worth a day of your team's time before you talk to me about it.
Most people who aren't using these tools well aren't missing an explanation. They're up against something more ordinary: the old way already works, and the new way costs something today for a benefit that's still a promise.
Which is why demonstrations don't change anything. Watching someone else do a thing has never once changed how anybody works.
A workshop wins where a demo loses, and not because of the material. It wins because for those hours, carrying on as usual isn't available. So the goal of the day isn't that your team understands a framework. It's that every person has done one real, useful thing themselves before they leave.
We start by working, not by listening. Your team asks for a small real change to something they've built, and then — this is the part that's new to most people — they use it before asking for the next thing. Almost everyone notices how many times they'd have carried on without checking.
Not a lecture about categories. An interrogation of your project: where are your keys right now, what comes back if this is deleted tonight, can anyone read the data without logging in, what did last month cost. We fill in the map on screen as we go.
We pick two or three gaps — always starting with the ones where the damage lands on someone other than you — and your team fixes them, live, with their own agent. Leaving with something actually repaired is the difference between a workshop and a presentation.
We build one mechanism together, aimed at whatever scares you most: a test described in plain words, watched failing on purpose so it means something, and the habit of asking for evidence rather than for reassurance. "It's done" and "here's a screenshot of it working" are different claims.
We close the map with the two columns that matter: who checks each box, and what happens in the next four weeks. Three actions with names and dates, not thirteen.
I don't touch your project — not when it's slower, not when the fix is obvious, not when something urgent turns up. If I fix it, you leave with the problem solved and without knowing how to solve it, which is the worse of the two outcomes. When someone asks me how to do something, my answer is usually "ask the agent and let's see what it says", because learning to do that is most of what you're paying for.
If the room goes quiet at "where are your API keys?", I don't rescue it with a generic answer. We write the box down as empty and move on. Knowing a box is empty is the point of the exercise, and it's worth more than a tidy session.
A production key sitting in the open, customer data readable by anyone — we stop the agenda and it gets fixed then and there. Discovering a leak and carrying on with the plan would be absurd.
A short document, within 48 hours. Not a deck.
A short follow-up session is included. It's where we see what got tried, what failed and why — and it exists because a plan without a checkpoint quietly evaporates. It's also the honest moment to work out whether you want anything else from me, which is a better question after you've tried things on your own than at the end of a long day.
A short call is enough to tell whether this fits your team. If it doesn't, I'll say so.