Build the whole session around one real decision your agent held last week. Show what it read, which bound stopped it, and the choice a person then made. Ask the room to decide before revealing the answer. Forty-five minutes, one case, one record. People remember a decision they argued about far longer than a slide about autonomy.
What is this lunch-and-learn for, and who runs it?
A lunch-and-learn is an informal session over a meal, usually voluntary. On AI agents it has one job: give people who do not work with the agent every day an accurate picture of how it decides, where it stops, and what people still own. It is not certification and it is not a product demo.
The best presenter is someone who wrote or runs the process the agent works in, paired with a reviewer who handles its held items. That pairing matters, for the reason set out in why the people who wrote the process should teach the agent and the reviewers: they can explain why the rule exists, not just what it says. The sponsor is usually the operations lead or a learning and development partner.
How do you run the 45 minutes?
- Agent, depth 1: retrieves a candidate case. Before the session, the presenter asks the agent for held items from the last fortnight with their verdicts and the bound that decided each. Choose one that is ordinary, slightly ambiguous and safe to share once identifiers are removed.
- Presenter: sets the scene (5 minutes). What the agent does in this process, at what depth, and who reviews it. One sentence each.
- Presenter: shows the inputs (5 minutes). The request, the documents, the data, each labelled with where it came from: the system of record, a named party, the customer's own statement, or an outside email.
- Room: decides (10 minutes). Everyone writes down what they would do and why, then shares in pairs. No answer yet.
- Presenter: reveals the agent's verdict (5 minutes). Allowed, held, refused or withheld, and which of the five bounds decided it: role scope, certificate, sources, the customer's limits, or the platform floor.
- Reviewer: explains the human decision (10 minutes). What they checked, what they decided, and what the record shows now.
- Presenter: closes (10 minutes). Two takeaways, questions, and where people go next if they want more.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Find the case | Lists held items and verdicts | 1 | Presenter chooses and anonymises |
| Scene and inputs | Nothing live | none | Presenter |
| Room decides | Nothing | none | Attendees |
| Reveal verdict | Shown from the record | none | Presenter |
| Human decision | Nothing | none | Reviewer |
| Close | Nothing | none | Presenter |
Which case makes a session memorable?
Choose a case where the room's instinct and the right answer differ a little. A supplier email asking to change bank details works well in almost any organisation: most people would just update it, and the agent held it because an outside email cannot authorise a payment. A refund just over the customer's limit works too, because people see that the limit, not the agent's confidence, decided.
Avoid three kinds of case. Cases where the agent got it badly wrong, which turn the session into a blame exercise. Cases that need specialist knowledge to follow. And anything with personal data you cannot fully remove.
A withheld action can make a strong second example if time allows. Showing that some actions are refused for every agent at every depth, by the platform rather than by your settings, answers the question people most often carry into these sessions: "What stops it doing something terrible?"
Which controls keep it accurate and safe?
- Identifiers removed. Evidence: the presenter's checklist, signed before the session.
- Verdict shown from the record, not retold from memory. Evidence: the record reference on the slide.
- No live actions. The agent is not asked to do anything during the session. Evidence: none needed, but say so.
- Questions you cannot answer are logged. Evidence: a follow-up note circulated within a week.
How do you know people remembered it?
Ask three questions a fortnight later, by short message: what made the agent stop, who decided, and where the decision is recorded. If most people can answer, the session worked. Track who asks to join review or champion work afterwards, and how many sign up for structured training. Look too at whether questions from that team to the agent's owner become more precise.
Where do lunch-and-learns usually go wrong?
Too many slides. Ten slides on agent theory and no case. Cut to the decision.
A demo instead of a decision. Watching the agent draft something impressive teaches nothing about governance.
No reviewer present. Without them, nobody can explain what a person actually did.
Treated as training. A lunch-and-learn builds interest and accurate expectations. It does not make anyone competent to review. Be clear about that, and point to the next step. For how many people need deeper training per agent, see how many people need to be trained to run one AI agent; for what happens after, can staff learn to supervise AI agents on the job. A ready plan is in the lunch-and-learn session plan template, and the wider programme is in training teams for AI agents.
Where the Academy fits
A lunch-and-learn is a good doorway into Pryme Intelligence Academy's Foundations track: about four hours, free, open to anyone, ending in a Foundations badge that does not expire. Attendees who want more can start the module on the decision chain the same afternoon. People who will review agents every day need the Operator track instead.
Questions people ask
Should attendance be compulsory?
No. Voluntary sessions draw people who are curious, and they spread what they learned. Make the structured training compulsory for those who will review, not the lunch.
Can it be run remotely?
Yes. Use a poll for the room's decision and breakout pairs for discussion. Keep cameras optional while people eat.
How often should we run one?
Once per new agent, and again when an agent's depth changes. Each new case keeps it fresh.