Learn AI by building things
that have to work afterwards
Two tracks — one for education, one for business — each in a one, two or three day format. Every hour is spent with laptops open on your own material. Below, each format is described by what you will be able to do at the end of it, so you can pick the one that gets you there.
Most groups take the single day, and it is a complete workshop in its own right — you leave with working tools, not an introduction to them. We can also build one day out of pieces of all three formats when that suits your group better.
What everyone learns, whichever format they take
The tracks differ in subject matter and the formats differ in depth, but four capabilities run through all of them. If you already have all four, you don't need us — the material below is free either way.
Predict where it will fail
Say in advance which parts of a task a model will get wrong, and explain why to someone who has only seen the marketing.
Make it do the same thing twice
Write instructions that hold their shape across a long session, and constraints that survive somebody trying to talk their way around them.
Run it on your own material
Ground answers in your syllabus or your policies so they can be cited — and, when the data can't leave the building, run the model on your own hardware.
Know what it costs and how it breaks
Price a request before you build on it, bring that price down deliberately, and find the holes in your own system before someone else does.
Same five skills, different material
The Intuition track works on syllabus documents, student answers and marking. The Ontology track works on invoices, contracts, logs and policies. Pick by the material you deal with, then by how many days you have.
Intuition
Students, tutors, teachers and academic operations
The central skill is making AI ask questions instead of supplying answers — and being able to show, with a rubric, that it worked.
What each format adds
Build a tutor that refuses to give answers, generate tiered practice from syllabus wording, and audit student work for invented sources.
Add: run a model offline on a school laptop, and write a marker that scores against criteria and names what to revise.
Add: restrict an assistant to official syllabus and past papers with citations, then build one in a team and demonstrate it live.
The Ontology
Founders, department heads, operations managers and engineers
The central skill is judgement: choosing the work worth automating, building it so the output can be checked, and knowing the annual cost before you commit.
What each format adds
Rank your processes by hours saved against risk, extract structured data from real documents, and stand up an assistant on your own procedures.
Add: batch processing from the command line, sensitive data handled on your own hardware, and the cost-per-request arithmetic.
Add: retrieval over your documents and databases with citations, routing between models, and a build that another team tries to break.
Five skills, taught at three depths
Every lab in both tracks belongs to one of these. A one-day format touches the first two properly; three days reaches all five. Each is written as a capability, not a topic.
Read a model honestly
Know what happened between your question and the answer — and where that process reliably goes wrong.
Direct it in the apps
Write instructions that hold across a long session, and constraints that survive being argued with.
Run it from the terminal
Handle four hundred files instead of one, and keep the sensitive ones on your own machine.
Ground it in your own work
Messy documents into checkable structure, answers tied to sources, output scored against a rubric.
Account for cost and risk
The arithmetic and the adversarial thinking that decide whether it survives a real budget and a real user.
One day, two, or three?
These are three complete workshops, not a small, medium and large. The single day is the one most groups take and the one we run most often; the longer formats exist because a few specific skills — running models yourself, grounding them in your own library — genuinely cannot be reached between morning tea and home time.
| One day 6–7 hours | Two days 12–14 hours | Three days 18–21 hours | |
|---|---|---|---|
| Come if you want to | Use the tools you already have far better, and decide what's worth pursuing | Automate something repetitive, privately, and know what running it costs | Build a grounded, cited system with a team and have it tested in the room |
| You need to arrive with | Nothing A laptop and a browser | Willingness A terminal helps; we start from a cold laptop either way | Some code Day three assumes you can build |
| What you work in | The major chat assistants, in a browser | A terminal, a local model on your laptop, and short scripts | APIs, retrieval over your own documents, and a shared repository |
| Pillars covered | 1 and 2 properly; 4 and 5 as ideas | All five, with 3 and 5 done hands-on | All five, plus putting them together as a system |
| You leave with | A configured assistant, a prompt pack and a checklist you can hand to colleagues | A working command-line tool, a local model set up, and a cost model | A running prototype, its repository, written judge feedback and a certificate |
| How it ends | A 45-minute build, demonstrated to the room | A 3-minute demo of your own tool | A full day building, then judges using what you built |
One day is a real workshop
It is the format we run most often, and the one most groups should take first. Nobody sits through an overview: you spend the day building on your own material and leave with a configured assistant, a set of templates and a checklist your colleagues can use on Monday.
The longer formats are for teams who already know they need to run models themselves or ground them in their own library. They are not a better version of the same day.
A single day drawn from all three
The formats are built from self-contained labs, so a day can be assembled across them — the one-day prompting work in the morning, a local model set up after lunch, and the cost arithmetic from day two to finish. We do this regularly for mixed-experience rooms.
Tell us who is in the room and what you want them able to do afterwards, and we will put the day together from these parts.
Ask for a custom dayWhich format fits you
Tell us the material you work with and the time you have, and we'll show you what that format teaches.
One day, browser only
Write a tutor prompt that refuses to give answers, turn a syllabus dot point into tiered practice with a marking key, and audit student work for invented citations.
Your tested tutor prompt, a scaffolding pack of templates, and an academic integrity checklist you can hand to a faculty.
The research the workshops are built on
The labs teach methods we use ourselves. These are the results of using them — published in full, free to read, and the fastest way to judge whether the teaching is worth your time.
Ontology Eval
Open and closed models scored on policy synthesis, messy PDFs, tool calls and code execution — the evaluation method taught in Pillar 4, run in public.
Where AI behaviour can be changed
The layers you can actually reach: skills, context and tools above the model; weights and sampling below it. Background reading for Pillars 2 and 4.
The best model is not the best product
From the MARK exam-marking system: task-specific evaluation, designed workflows and the cost arithmetic — Pillar 5, worked through on a real product.
Predicting the HSC
Six models predicting exam questions from syllabus evidence, backtested blind against the 2025 papers. Syllabus grounding, done at full scale.
Building a web app using AI
The full-screen deck from a live session: an application built end to end with coding agents, in front of the room.
The AI Octopus
Twelve models predicting World Cup results, scored against what actually happened. A cheap, public lesson in calibration and confidence.