Context Is the Curriculum: Notes From Teaching AI 101 to Business Teams

On the side of my day job, I built and teach an AI 101 class for growing businesses. Twenty-five slides. I did not build it from theory or from anyone else's framework. I built it from my own postmortems, and the people in the room can tell, because when someone asks "what happens when it's wrong?" I don't have to reach for a hypothetical. I have a database that held 1,320 guests while my agent confidently reported 5,121.

The class opens on the gap that generates almost every disappointment I get called into. Personal AI use looks like this: one-shot prompts, one question, vague phrasing, search-engine habits, low probability of success. Commercial AI use looks like this: robust instructions, documentation, worked examples, negative examples, the actual schema, the actual procedure, the standards that define acceptable output, and memory of what came before. Same model in both columns. The entire difference in outcome is what the system was given to work with.

There is a slide early in the deck that says, in full: "Trust requires context." Everything after it is elaboration. Executives are being told from every direction that their jobs depend on getting AI right, and half the room arrives convinced the answer is picking the right model. The class exists to move them off that idea in ninety minutes. Models are the most interchangeable part of the stack I run. Context is the part I have rebuilt three times and still spend most of my engineering budget on.

The most useful demystification I have found fits in four nouns: an agent, a model, memory, and tools. One slide says exactly that, followed by "This is AI. That's it." People photograph frameworks and forget them. Nobody forgets a four-noun definition, and once the mystique is gone, business people start reasoning about AI the way they reason about any other system with inputs and failure modes, which is the actual goal of the class.

The metaphor that carries the probabilistic part: AI is a ball rolling on a net, and context shapes the net. Pull the net taut in the right places, with data, instructions, examples, constraints, and the ball lands where you need it, most of the time. Leave the net slack and the ball still rolls somewhere. It always rolls somewhere. That is the property that surprises people who grew up on deterministic software: the system does not refuse to answer when it lacks what it needs. It answers anyway, fluently.

I have shipped the counterexample I use here. During one platform migration, four context fields drifted silently out of the runtime, and one of them, a location-name map, arrived in production as an empty dictionary. The agent kept answering. Nothing crashed. The net was slack in exactly one region and the ball kept rolling through it. No amount of prompt phrasing fixes that class of failure, because the failure happened before the prompt was ever assembled.

The core of the curriculum is that context is not one thing. It is four, and each one answers a different question. Data is what the system knows. Tools are what the system can do. Governance is what the system must not do. Processes are how the system operates. In the classroom these are definitions. On my platform they are code, and the class works because I can show the room where each pillar physically lives.

The governance row deserves its receipt, because "fail-closed" is the kind of phrase that sounds like posture until you see it written down where it executes. This comment sits at the top of my tool catalog:

# Fail-closed migration safety (Gate-2). Unknown (uncataloged) tool names
# are DENIED by default. A comma-separated allowlist lets specific
# uncataloged tool names through during migration -- every such
# pass-through is logged at WARNING so it is observable and reversible.

On the origin product, the most recent agent manifest ran 133 lines and declared all four pillars in one file: the domains it may read, the tool groups it may call, the permissions that gate them, and the strategy it runs under. That is what I mean when I tell the class that context engineering is an artifact discipline. If your four pillars live in a slide deck instead of a reviewable file, you have a philosophy, and philosophies do not fail closed.

The sentence people quote back to me weeks later is six words: probabilism for novelty, determinism for consistency. It resolves the argument the room walked in with, the one between the camp that wants AI everywhere and the camp that trusts nothing that cannot be replayed. Both camps are right about different workloads, and the taxonomy settles which is which.

The class splits computation into three types of logic. Human-defined rules: same input, same output, fully auditable. Machine learning: trained on data, but deterministic at inference, a distinction most executives have never been offered and visibly enjoy receiving. Generative AI: probabilistic, same prompt, different outputs, which is precisely the property that makes it creative and precisely the property that makes it unfit to be a password reset flow. Novelty is a feature you buy with variance. Consistency is a feature you buy with rigidity. Pretending one kind of logic gives you both is how AI programs end up on the failed-pilot pile.

Production is where the two kinds of logic interlock, in both directions. My nightly insight runs are deterministic schedules that invoke probabilistic analysis: the workflow engine decides when and against what, the model decides what is interesting. My cost controls are deterministic walls around probabilistic spend: five dollars a session, twenty-five a day, and a hard stop that does not negotiate with an agent mid-task. Agent calls process, process calls agent. The architecture question is never which paradigm wins. It is which one owns the boundary.

The taxonomy also tells you where to look when things break, which is worth real money. When my agent reported 5,121 guests against a database holding 1,320, the instinctive diagnosis was "the model hallucinated." It had not. The deterministic tool layer was running the wrong aggregation, the same wrong aggregation, every single time. Fixing prompts when the SQL is broken wastes weeks, and I have watched teams without this vocabulary do exactly that. The three-logic taxonomy is not academic. It is a debugging triage protocol wearing a lecture slide.

The second half of the class is a ladder with four rungs. Human only: the person does all of it. Human-in-the-loop: the agent proposes, the person clicks approve on every action. Human-on-the-loop: the person audits by exception. Autonomous and accountable: the person sets goals and monitors intent. Risk climbs with every rung. So does reward. The mistake I see most is organizations that talk rung four and operate rung two, permanently.

They stall there for a structural reason: nothing in their system generates the evidence that would justify climbing. Advancing a rung is not a courage decision. It is an evidence decision. You move from approving every action to auditing by exception when you can show the audit trail, the eval results, and the boundaries that catch the failures you already know about. I wrote up the strongest version of this argument as Verification-Gated Orchestration, and I run it in my autonomous delivery system, where autonomy is earned per lane of work, backed by per-gate evidence, and revoked the same way. Trust is established at some level, as the slide puts it, and the level is a number you measure, not a feeling you develop.

Here is the board-language version. Rung two caps your return at assistant economics: every agent action still consumes a human click, so headcount math barely moves. The returns everyone is budgeting for live on rungs three and four. The bridge between them is not a bigger model. It is the four pillars, built well enough to produce evidence, because evidence is the only currency the ladder accepts.

The class closes with a loop, not a list: describe the problem in plain language, scaffold the process with the agent, build with deterministic control, calibrate from real execution logs. Then one assignment: get clear on your use cases, and know what done looks like before you automate anything. Every stalled pilot I have audited failed that assignment first. The tooling gets blamed later.

And I give them the conclusion the whole deck has been walking toward. Prompt engineering was an individual skill, and 2023 was its peak. Context engineering is an organizational capability: pipelines that supply data, catalogs that govern tools, gates that fail closed, processes that produce evidence. An individual can get better at phrasing in an afternoon. An organization gets better at context by building things, and by teaching everyone in the building what the four pillars are, because the person who knows where the data lives is now part of the context pipeline whether they report to engineering or not.

So here is the position, and I will take the disagreement: if your company runs an AI literacy program that teaches prompt phrasing instead of context supply, cancel it and rebuild it. You are training people for a version of this technology that stopped being the bottleneck two years ago. Teach the four pillars, teach the ladder, and teach people to ask "what was the system given?" before they ask "why did the model lie?" That question, asked by a room of business people who will never write a line of code, is worth more to an AI program than the next model upgrade. I have the guest counts to prove it.