How the catalog works: prepared talks across three audience levels, plus conference and event speaking; a company selects a session and it’s delivered remotely or on-site. Each session draws on real engineering work: architecture decisions with their rationale, failure modes met in practice, and evaluation data from systems actually built and measured. The material takes positions; it is not a neutral survey.
Executive / Leadership Sessions
For leadership teams weighing what to spend on AI.
“The Four Ways Companies Use AI”
…and why the one that pays the most is the one nobody’s selling you
You have an AI budget, and four genuinely different things competing for it. Most organizations put their money in the two that pay least and have barely touched the one that pays most — not by choice, but because the valuable one can’t be demonstrated in a meeting, so no vendor ever shows it to you. This session maps the four in plain terms, shows where the money actually is and what it costs to get, and leaves you with one question to ask of any process before you spend a dollar on it. No hype, and a straight answer on where AI is the wrong tool.
Key takeaway: one question to sort high-return AI work from low-return AI work: can this process be boxed? Format: 60 min. Diagram-driven; one-page leave-behind.
The 90-minute version adds
- The specification lens — why AI landed with your developers and not with everyone else.
- What the build actually takes — comparing models, finding the cheapest one that still clears your bar, and measuring run-to-run variance, each with what the naive version does, what breaks, and what the disciplined version does instead.
- A mapping exercise on one of your own processes — you name it, we place it against the four modes, and we open it up into the handful of steps it actually contains.
- Q&A — the rest of the extra time is yours, not more material from the stage.
Same eight beats either way.
“Why is your company not using AI more?”
analysts and your shareholders are asking, and unfortunately “usage,” the one number you have, can’t answer them whichever way it points
You are being asked that question and you did not choose the number you have to answer it with. It arrived from outside and came down the building as a usage report that isn’t going up fast enough. The trap is that it fails in both directions — succeed at the adoption push and you have a bigger number, a larger bill, and the same unanswerable question. This session is about why that number can’t tell you what anything was worth, three ways to actually find out, and the reason measurability is decided when you choose how to deploy rather than afterwards when somebody asks.
Key takeaway: three usable evidence designs, and the reason measurability is decided when you choose how to deploy rather than afterwards when somebody asks. Format: 60 min. No demo.
Business / Operations Sessions
For the leaders whose teams use AI for their daily work.
“The Four Ways Your Team Can Use AI”
…and why the one that reduces grind is the one nobody’s built for you
There are four fundamentally different ways a team can put AI to work, and they do not do the same thing to your work. Most teams only ever use one of them: the chat window on every desk. The mode that would actually clear your backlog is one your team probably does not have, and has never been shown, because it does not perform on a screen. Aimed at the operations and department leaders who receive AI in their daily work, this session maps the four in plain terms, draws on examples from the kind of work your team handles, and spends most of its time on what an operations leader needs to know: what you can trust the system to do on its own, what still needs a person, and why the AI your team was handed last year did not move your numbers. The aim is capacity and relief for the team you already have, with a clear line on where a person still has to sign off.
Key takeaway: a way to look at your team’s own workload and see which parts a system can take and which stay with your people, plus the one question to bring to whoever builds your systems: can this be boxed? Format: 90 min. More interactive than the executive cut.
The half-day workshop adds
- A process-mapping exercise — your team’s own work, sorted against the four modes, and the top candidate broken apart on the board into the handful of tasks it actually is.
- A worked case from real systems — a document with no such clause in it, and a tool that invented one: the same invented answer, every run. Why it happens, and what the disciplined version does instead.
Same beats either way, plus a longer discussion.
Engineering / Technical Sessions
For the engineers and architects who have to build reliable AI systems.
“AI Is a Component, Not a Product”
Architecture patterns for building systems where the model is one fallible part
Most AI systems fail in the same place: a team treats the language model as the product, ships a demo that worked on their laptop, and watches it break the first time the model is wrong at scale. This is the opposite discipline. It treats the LLM as one fallible component inside a deterministic system and walks (drawing throughout on systems actually built and measured) through everything that surrounds it: designing around how the model actually behaves, splitting the model’s job from the code’s, decomposing a task so it runs cheaper and more accurately, measuring confidence when there’s no answer key, routing for cost, building an evaluation harness whose green result means something, and knowing when an agent is the wrong tool. Built from systems designed, built, and measured end to end, until the open question was no longer whether they worked but whether they could be trusted.
Key takeaway: the deterministic-first, decomposed, measured pipeline pattern (applicable Monday) plus a checklist of the ways these systems fool the people building them.
Two ways to take it
- 90-minute overview — the whole argument, no exercises. The session leadership books for their engineers after the executive talk.
- Full-day intensive — everything, including the modules the overview leaves out.
Each is built for the commitment it asks for.
“Evaluating AI: How to Know If Your System Actually Works”
Most teams evaluate an AI system against their own test set, watch it go green, and ship. Then it fails in production on exactly the cases the harness never really tested. This deep-dive is about building an evaluation harness whose green result means something: walling the answer key off from the system, planting your own errors and scoring blind, treating variance as a first-class metric, and using LLM-as-judge without letting it grade its own work. Built from real evaluation work, where a trusted-but-wrong harness was worse than no harness at all.
Key takeaway: an evaluation harness you can trust, and a catalog of the specific ways harnesses lie. Format: 90-min or half-day.
“You Can’t Ask a Model How Sure It Is”
Measuring confidence without ground truth
The single output your system just produced, in production, with no answer key: how much do you trust it? You cannot ask the model; its self-reported confidence reflects fluency, not accuracy. This deep-dive is about where trustworthy confidence actually comes from: agreement across independent readers, computed from behavior rather than elicited from the model. It covers the traps that manufacture confident, meaningless answers, and makes the case that a confident wrong answer is the failure the whole system exists to prevent. Built from systems that had to grade their own output with no key to check against.
Key takeaway: a method for computing per-output confidence from behavior, and a catalog of the ways teams fool themselves into trusting output they never verified. Format: 90-min or half-day.
Conference & Event Speaking
For programme chairs and event organizers.
Stage versions rather than shorter products. A conference room holds executives, operators and engineers at once, and none of them picked the session for their role — so these are built for one thesis worth repeating to a colleague, one piece of evidence that there is depth behind it, and a next step. The two are deliberate complements, and the track tags below say which room each belongs in: the four-modes cut is remedial in an AI/ML room, and the confidence cut is wrong for a business track. Between them they cover most of the landscape.
“The Four Ways Companies Use AI”
the stage cut — four ways to use AI, and why the one that pays the most is the one nobody demos
The four-modes argument compressed for a stage: four fundamentally different ways a company puts AI to work, why the highest-return one is the one that can’t be demonstrated in a meeting, what it costs to capture, and the one question worth carrying back to the office. Two delivery variants — one pitched at industry and business tracks, one at engineering tracks. Same argument and the same diagram sequence; the emphasis and the language move.
“Stop Asking the Model How Sure It Is”
what it reports is fluency, not accuracy — trustworthy confidence is computed from behaviour, never elicited
One output, in production, no answer key — how much do you trust it? Not by asking: self-reported confidence tracks fluency, and generic confidence prompts across eight of our own tests produced zero escalations while the model stayed cheerfully wrong. What works is computed from behaviour. This cut covers what a model can legitimately assess about its own task and what it will invent if you ask past that line; why the strength of agreement is bounded by how uncorrelated two readers’ errors are rather than by how many you run; the four ways to actually buy independence, including crossing modalities so the second reader fails differently by construction; and routing into three bands that fail toward review instead of toward a default. No live system required, which is why it can be delivered now.
Not in the catalog?
Custom sessions, built to order
Bring me the problem your teams are actually arguing about and I’ll build the session for it. Same source material and the same discipline as everything above — aimed at your situation instead of the general case.
Priced on development time and complexity. A custom session may later join the catalog for other clients, in its generalized form.