A model's stop reason says why one response ended. It is not proof that the task succeeded. These are the run's own outcomes.
- Accountable owner People and products
- The named person who owns the outcome and the refund policy. Someone signs for what the system is for and what wrong costs. The goal pinned on the agent's desk comes from them, not from the model. Where the analogy stops: Ownership is an organisational fact; the line in the drawing is a reminder, not a mechanism.
- Requester People and products
- The person who asks for something. Here, a customer whose lamp arrived cracked. The request starts the run. It is input, not authority: what the customer asks for and what the system may do are separate questions. Where the analogy stops: Drawn as a person because this one is a person. Solid figures in the scene are real people; outline figures are software.
- Skills Context
- A procedure card pulled from a binder when that kind of task comes up. A skill is a package of instructions, scripts and resources. A short description is visible; the full content loads when the task matches. It is know-how, not a worker. Where the analogy stops: A card is passive paper; a skill can include scripts that run with whatever permissions the runtime gives them.
- Memory Data
- A notebook kept between sessions, reopened to the page that matters now. Memory persists facts, preferences, summaries or task state outside the context window. It helps only when the application selects a relevant, permitted, fresh entry and puts it on the desk. Where the analogy stops: A notebook entry stays as written; stored memories can be wrong, stale or summarised badly.
- Retrieval (RAG) Context
- Relevant pages pulled from reference shelves and brought to the desk. Retrieval selects passages from governed sources for this request and adds them to the context, with where they came from. It is a pattern, not a product: search, filters and permissions matter as much as any vector index. Where the analogy stops: A shelf suggests a fixed book; indexes go stale and retrieval can pick the wrong page.
- Goal verification Control
- Checking the work against the goal before calling it done. The run succeeds when the application verifies the success criteria (refund recorded, amount within policy, customer told), not when the model says it has finished. Where the analogy stops: A tick looks final; verification is only as good as the criteria.
- Coordinator Agents and orchestration
- A dispatch board that issues bounded work orders and combines what comes back. An agent that delegates part of the work to specialists, giving each a specific task and selected material, then merges their structured results. Where the analogy stops: A dispatcher manages people; a coordinator is the same loop with delegation calls.
- Model (LLM) Models
- The engine that reads what is on the desk and writes a response. An autoregressive language model produces output one token at a time (tokens are word pieces). It can propose a tool call, but it does not execute anything itself. Where the analogy stops: An engine suggests mechanism; a model is learned statistics, and the same input can produce different output.
- Agent Agents and orchestration
- Software that works toward a goal in steps: it looks, decides, uses a tool, checks, and goes again. A bounded control loop. The application calls the model with the current context; the model either answers or proposes a tool call; the application runs permitted calls and feeds results back until the goal is verified or a limit, denial, cancellation or handoff ends the run. Where the analogy stops: The operator is a drawing of software behaviour. It does not understand, intend or want anything.
- Context Context
- The desk: only what is placed on it for this call is available. Context is the set of tokens sent with one model call: instructions, the request, loaded procedures, selected notes, retrieved passages and tool results. It is finite and assembled fresh for each call. Where the analogy stops: A desk keeps things between visits; context does not. Each call gets what the application sends.
- Tool Tools and protocols
- A specific instrument: a defined input goes in, a result comes back. The model proposes a call with arguments; the application validates, authorizes and executes it, then returns the result to the context. Where the analogy stops: An instrument does one thing; a tool is software that can fail, time out or change.
- MCP Tools and protocols
- Compatible connectors between the workstation and the service stations. A protocol with three roles: the host application, one MCP client per connection, and MCP servers that expose tools, resources and prompts. It standardises how context and calls are exchanged. Where the analogy stops: A plug fits or it doesn't. A protocol connection can be live while a specific call is still refused.
- Guardrails and hooks Control
- Checks in code that run before or after a tool call, outside the model. A pre-call check can compare the proposed arguments with the records (amount no more than the order total, money back to the original payment method) and block the call. Some hooks only log and some ask another model; only a check in code that can block the call is a rule. Where the analogy stops: A locked gate stops everyone. A check stops only what it was written to test; anything it does not test passes straight through.
- Authorization check Control
- An identity checked at a gate before an action goes through. Code outside the model decides whether this caller may perform this operation with these arguments: allow, deny, or require approval. In Claude Code, for example, a PreToolUse hook can return allow, deny or ask; other hooks only observe. Where the analogy stops: This is a teaching simulation. A gate in a drawing, or a toggle in a web page, enforces nothing.
- Connected service Tools and protocols
- The station that actually does the work: looks up the order, issues the refund, sends the message. Business systems behind the protocol. They keep their own records and should enforce their own permissions too. Where the analogy stops: Stations look independent; real services share failure modes and dependencies.
- Human approval People and products
- A person reviews a proposed action before it happens. The application pauses a specific operation and asks an accountable person. A second model reviewing the action is not the same thing. Where the analogy stops: The drawing shows one person; real approval needs identity, an audit record and a timeout path.
- Specialist Agents and orchestration
- A separate station that receives one work order, uses its own few tools and returns a compact result with evidence. A specialist runs with its own context: only the work order and what it fetches. Its tool set is whatever is configured; in Claude Code, subagents inherit the main tools unless restricted. Where the analogy stops: The station looks like a separate room. Unless you configure isolation, it is not one.
- Limits and budget Control
- A gauge of steps and spend with a hard stop. A run stops when its step, time or cost budget is used up. That is a legitimate bounded exit, but it is not success. Where the analogy stops: The gauge counts steps in this lesson; real budgets count tokens, time and money.
- Recovery Control
- What happens when something goes wrong: stop, undo where possible, or make it right another way. Prevention (deny before execution), cancellation (stop pending work), rollback (undo a reversible change) and compensation (a new action that offsets one that cannot be undone) are different tools. Where the analogy stops: Nothing in the drawing undoes a sent message.
- Event trail Control
- A trail of stamped events you can follow back. Recorded events: model calls with stop reasons, proposed and executed tool calls, authorization decisions, approvals, errors and the final outcome. Where the analogy stops: The trail shows what was recorded, not why the model produced what it did.
- Tokens Models
- The small pieces of text a model reads and writes: words, parts of words, characters or bytes. Text is encoded into tokens before the model processes it, and a response is produced token by token. For Claude a token is about 3.5 English characters on average, varying by language. Context windows are measured in tokens. Where the analogy stops: Building bricks have fixed shapes. Tokenizers differ between models, so the same text can be a different number of tokens.
- System prompt Context
- The standing brief at the top of every call: role, rules, tools and format. Instructions the application sends with every model call, separate from the user's message. It sets role, constraints and output format and shapes behaviour strongly, but it is still text the model reads. Nothing in it enforces itself. Where the analogy stops: A new colleague remembers a briefing and a manager can hold them to it. A system prompt is sent again on every call and holds nobody to anything; the checks and gates do that.
- Prompting Context
- How a request is written: what is needed, why, and what good looks like. The request, with any examples and constraints, is the part of the context people write. A clear, specific ask with the reason behind it and a few relevant examples steers format and quality more reliably than clever wording. Where the analogy stops: A colleague you brief can ask a follow-up question. A model answers whatever it was sent and fills gaps with likely text unless the design asks it to stop and ask.
- Hallucination Models
- A fluent, confident statement that nothing the model was given supports. Models produce likely text, and when evidence is missing likely text can still read as fact. Quoting sources, permission to say 'I don't know', restricting answers to provided documents and checking claims against records reduce it. They do not eliminate it. Where the analogy stops: A student who guesses usually knows it. A model has no separate signal that a sentence is unsupported unless the design creates one.
- Prompt injection Control
- Text inside content the system reads that tries to give the model instructions. Records, documents and tool results are data, but a model cannot always tell data from instructions. Labelling untrusted content and its source, screening tool outputs, narrow permissions and checks on consequential actions reduce the risk. None of them removes it. Where the analogy stops: A forged note fools one person once. Injected text can sit in a record and be read on every run until someone removes it.
The workshop metaphor, the scenario and its numbers are teaching devices written for this site. They are not quoted from the sources.
