How to decide what AI should actually be doing in your business, where it goes wrong, and how to explain any of it to the people who have to use it.
The pitch is an AI employee: connect it to your inbox, calendar and accounts, and the admin handles itself. The best public evidence on agents doing real work says something narrower, and more useful, about how much of a job to give one.
Most advice on using AI safely ends with “always have a person review it.” When you work alone, that person is you, at nine in the evening, on the fortieth draft. The research on what happens to that review is not encouraging, and it points to a different kind of check.
Build-versus-buy is usually argued on features and price on the day you switch it on. For anything built on a language model, the cost that decides it arrives later, on a schedule set by someone else.
The usual explanation is that you were not prompting it properly. The evidence points somewhere else: the chat window moved the work onto checking and fitting, and when there is only you, the moved work lands back on the person it was meant to free.
The usual advice is to automate whatever eats the most hours. That tells you what a working system would be worth. It tells you nothing about whether it will work, or how you would find out when it doesn't.
A leadership briefing is not a shorter version of the staff session. The audience has a different question, a different failure mode, and about forty minutes.
Most AI curricula are organised around tools, which is why they expire. Organising around mechanisms instead gives you material with a much longer half-life — and a defensible order to teach it in.
Most people asked to teach this were not trained in it. That is a smaller problem than it feels, as long as the session is built around demonstration rather than explanation.