Introduction to Model Context Protocol: teaching notes

Side-by-side notes for 07-praxis-introduction-to-model-context-protocol.html (14 slides). This is the most technical course in the set: it is built for engineers wiring MCP servers, clients, tools, resources and prompts. Our job is to teach the idea to the nine non-technical archetypes without selling them the plumbing. Keep the framing on "what this means for your data and your tools", not the JSON-RPC. Course 01 slide 10 (Connectors / MCP) and course 02 slide 13 (MCP) already pitch MCP to these learners. Match that framing; this is the longer version. The deck is what the room looks at; this is what you say, where you stop, and how each idea lands for the person in front of you. Written from the deck and the Praxis teaching library. Method: teaching-notes-method.md.

How to use these notes

Blocks marked Back to your card, Brief it like a new hire and Run it live are the three moves from T0, how we teach Praxis. Use the names and tasks on the group's Use Case Cards wherever you see [name].
These are guidance, not a script. Teach the person, not the slides.
Each teaching slide has a Pause, then ask block. Put the question, then stop. Do not fill the silence. If they freeze, one line: "Take your time, type anything when you're ready, including 'I don't know'." Then wait again.
By background gives you a line per archetype (from tutor/scenarios.md). Reach for the one that matches whoever is in the room and ignore the rest. They are a palette, not a checklist to read out.
This course is heavy on protocol mechanics (servers, clients, transports, decorators). Several slides do not vary by professional domain. Where that is true, the note says so and gives one shared example rather than nine contrived ones. Don't read code aloud (framings.md: voice); the point of every slide is the outcome, not the syntax.
The one thing every non-technical learner must leave with: MCP is the single standard that plugs Claude into the tools you already use; it sees only what you can see; it is scoped and revocable. Data-safety is the spine of this course for these rooms. It comes up earliest and hardest on slides 3, 8 and 13, so slow down there.
Hold the voice (train-the-trainer.md Part 4): no "great question", no emoji, one term only: Claude Code. Underclaim. Cost is "about twenty dollars a month" and stop.
Run the intake first (train-the-trainer.md) so you know which background you're teaching to. If the room hasn't done courses 01 and 02, plant the bridge: the connectors and MCP they met there are what this course opens up.

Title

One protocol, so any AI app can reach any tool or data source

The idea

Set the frame: eleven ideas, one per screen, and the watching is the lesson. This course explains the wiring under "connect your tools", but for these learners the takeaway is not how to build it, it's what it is and why it's safe.

Say it like this

"Eleven ideas, one screen each. In Claude 101 we said Claude can plug into the tools you already use. This is the one standard that makes that work: what it is, and the part everyone actually worries about, what it can and can't see. I'll show you each piece, then stop and ask where it touches your work."

Open with

The intake answer: the tool or system where their real work lives: the case store, the inbox, the CRM, the drive. Name it, and promise you'll come back to it: by the end they'll know exactly what connecting it does and doesn't expose.

Spine

The whole course on one screen

The idea

Four moves: grasp what MCP is, then its three primitives (tools, resources, prompts) one at a time, server side and client side. Show the shape so the terms don't feel like a pile-up later.

Say it like this

"Here's the whole thing on one screen. First, what MCP is and why it exists. Then its three pieces (tools, resources, prompts), each twice: how it's built, and how you'd use it. If a word lands and you've lost where it sits, this slide is the map back."

Cue

Don't teach the spine, just orient. The centrepiece is slide 13, three primitives and three owners; everything else serves it. For a non-technical room, say plainly that the middle slides are the engineering and you'll keep them light. Twenty seconds, then move.

Lesson 1 · Foundation

M×N integrations become M+N

The idea

Without a standard, every app wires up to every tool by hand, and the tangle grows with both sides. MCP is the standard connector ("USB-C for AI"): build to it once and every compliant tool just works. M×N custom integrations become M+N.

Say it like this

"Before this, every AI app had to be wired by hand to every tool (your email, your drive, your tracker) over and over, a tangle that grows with both sides. MCP is one standard, like USB-C for AI: build to it once and every tool that speaks it just works. That's why connecting things to Claude stopped being a custom job." (Mirrors course 01 slide 10: connectors, the one standard behind them.)

Pause, then ask

"Think of the tools you use that don't talk to each other today? Where do you do the carrying by hand between them?"
"If those tools all spoke one language, which connection would you want first?"

(wait)

By background (the tool they'd plug in first: the connector that earns its place, mirroring course 01 slide 10)

Investigator: the document store where case files live, after the IT conversation.
Analyst: the warehouse or drive holding vendor responses.
Designer: the design tools, plus the drive for brand assets.
Knowledge worker: the email and drive where invoices land.
Reporter: the project tracker and chat where status updates live.
Content: the CMS or notes app holding the back catalogue.
Form-filler: the drive or email where receipts arrive.
Outreach: the CRM and email for customer context.
Exec: the drive, chat and email for the board-pack inputs.

Brief it like a new hire

On the map: connectors are the logins you give a new starter. MCP is the standard that means each login is set up once and works in every app.

Back to your card

Which two tools on your card do you carry things between by hand today?

Watch for

The data-safety fear surfaces the instant they picture connecting their email or their case store. Name it now, don't wait: a standard for connecting is not a standard for exposing. Promise you'll show exactly what it can see on slide 8 and again at the recap. (objections.md: IT/compliance/privacy; "where is the AI".)

Lesson 2 · Foundation

Host, client, server: one client per server

The idea

The app you use is the host (Claude Code, Desktop, Cursor). Inside it, each client holds one connection to one server, and the server wraps the real tool or data. Messages travel as JSON-RPC over a transport: stdio for local, HTTP for remote.

Say it like this

"Three words worth knowing, because the rest hangs off them. The host is the app you're in: Claude Code, the desktop app. The server is the thing that wraps a real tool or data source, your drive or your tracker. And a client is one private line between them, one client to one server. The host can hold many of these lines at once." (Don't dwell on JSON-RPC or transports. Name them once, on the caption, and move. They don't change anything for a non-technical learner.)

Pause, then ask

"How many separate systems would you want Claude to reach in a normal week: one, or several at once?"
"Which of those would you trust it to read, and which would you want to keep walled off?"

(wait)

By background (the systems that would each be a server, one line each)

Investigator: the case store, plus a sanctions/screening source, separate lines.
Analyst: the responses drive and the data warehouse, kept distinct.
Designer: the design tool and the brand-asset drive, two connections.
Knowledge worker: the inbox and the accounts drive.
Reporter: the project tracker and the team chat.
Content: the CMS and the analytics source.
Form-filler: the receipts drive and the filing system.
Outreach: the CRM and the mailbox.
Exec: the board drive, the chat and the finance source, several lines at once.

Watch for

"One client per server" is the seed of the safety point: each connection is separate and named, so you grant and revoke them one at a time. You don't open a floodgate, you run individual lines you control. (Sets up slide 13: scoped and revocable.) Keep the transport detail off the floor unless a technical person asks. (objections.md: server / "where does it live": a server is just a computer somewhere; the line is what you control.)

If asked: server vs client, the one-line difference (technical reference)

It's

provider vs consumer

. The server offers the capabilities. It's where the tools, resources and prompts live; it wraps a real system (a drive, a tracker) and waits for requests. The client is the communication bridge: a protocol connection that reaches one server, discovers what it offers, calls it on the model's behalf, and relays results back to the host. Two sharpenings on the plain version: the server "contains" the three primitives in the sense that it offers/serves them; and the bridge isn't one shared pipe; it's one client per server, so the host opens a separate, named line to each. The reason the protocol splits them: any compliant client can talk to any compliant server, so a server built once works in every MCP-aware host. Verification: matches the course spine (host/client/server, "one client per server") and the MCP architecture docs; course 07 is video-only in our capture, confirmed against primary docs (June 2026).

Lesson 3 · Foundation

A server is a few lines to start

The idea

The Python SDK's FastMCP does the protocol plumbing. You create a server, register capabilities with decorators, and run it over a transport (stdio local, HTTP remote). Same server code either way; the transport is just how messages travel.

Say it like this

"This slide is for the builders in the room: standing up a server is small. The SDK handles the protocol; you write a few ordinary functions and mark them as capabilities. For everyone else, the takeaway is only this: the people who make these connections do it in a handful of lines, which is why so many tools already have one." (One shared example below; this is a mechanics slide, it does not vary by domain.)

Pause, then ask

"When you hear 'someone could connect this in an afternoon', does that change which of your tools you'd ask about?"

(wait)

By background

This is a purely mechanical slide. Building a server does not vary by profession, so don't force nine. One shared framing for the room: "Whatever your tool, the connector is small to build and many already exist. Your job isn't to build it; it's to know which one you want and what it should be allowed to see." Then move on.

Watch for

Don't get drawn into uv, FastMCP, stdio vs HTTP with a non-technical room. It's noise to them and the slide is inferred from the course title, not captured prose (sanity-check against the video for a technical audience). Keep it to "small to build, many already exist" and move. For the IT-restricted: a local server (stdio) runs on your own machine, nothing leaves it. That's the privacy ceiling in miniature. (objections.md: IT/compliance, local model, nothing leaves your network.)

If asked: what "transport-agnostic" means (technical reference)

MCP separates what is communicated from how it's carried. The protocol layer (the JSON-RPC messages for discovering and calling capabilities) is fixed and identical; the transport layer (the pipe the bytes travel through) is swappable. So the same tools/call request looks the same whether it went over stdio (the client launches the server as a local subprocess, talking over stdin/stdout) or HTTP (Streamable HTTP, for remote/hosted servers). The payoff: you write the server's tools, resources and prompts once against the protocol and swap the transport, not the logic, to move from local to remote, and a client that speaks MCP can reach a server over any supported transport without special-casing each one. In a line: MCP fixes the language, not the channel. Verification: matches the course's "same server code either way, the transport is just how messages travel" and the MCP transports docs (stdio + Streamable HTTP, which replaced the older HTTP+SSE); course 07 is video-only in our capture, confirmed against primary docs (June 2026).

Lesson 4 · Tools

Actions the model can choose to call

The idea

A tool is a function the server exposes; its name, description and typed arguments become a schema the model reads, and the model decides when to call it. Tools are the verbs: they do things, they have side effects. Model-controlled: the model picks the moment, not the app or the user.

Say it like this

"The first of three pieces. A tool is an action Claude can take: send the email, run the search, update the record. The verbs. The key word is who decides: Claude does. It reads what each tool is for and chooses when to use it, the way a capable colleague decides which step to take next. That's why we call tools model-controlled." (Pairs with course 02 slide 3: an agent acts, it doesn't just hand you text. A tool is how it acts.)

Pause, then ask

"What's an action (not a lookup, an action) that you'd be comfortable letting it take on your behalf?"
"And what's one you'd want to keep your hand on, every time?"

(wait)

By background (the action they'd expose as a tool)

Investigator: run a sanctions/PEP screen on a named subject, read-only, low risk.
Analyst: pull a fresh figure from the warehouse into the comparison.
Designer: push an export to the asset library under the naming convention.
Knowledge worker: file an extracted invoice into the accounts system.
Reporter: post the finished briefing to the team channel.
Content: schedule a draft into the CMS as unpublished.
Form-filler: write an allocation back to the filing record.
Outreach: create a draft email per customer, drafted, never auto-sent.
Exec: log a renewal decision against the account.

Brief it like a new hire

On the map: a tool is something the new hire is allowed to do, like sending an email or updating a record. You decide the list. They decide when.

Back to your card

What's one action on your card you'd let Claude take, and one you'd keep for yourself?

Watch for

Tools do things and have side effects. This is exactly where "what if it does something I don't want?" lives. The answer is the permission model from course 02 slide 6 (Shift + Tab, approval first): the model can choose to call a tool, but you decide whether it's allowed to. Draft, don't auto-send, until trust is earned. (objections.md: permission / "scary to let it".)

Lesson 5 · Tools

Test the server before wiring it to an app

The idea

The Inspector connects straight to your server with no model involved. List what it exposes, call each tool by hand, read the raw response. Debug the server in isolation first; if it lists and calls cleanly, a later problem is in the client wiring.

Say it like this

"This is a builder's slide: before you let Claude near a new connection, you test it on its own: does it list its tools, does each one return cleanly. A plain quality check on the plumbing. For everyone else, the point is reassuring: connections get tested in isolation before they're trusted, the same way you'd test a new process on dummy data before you run it for real."

Pause, then ask

"Before you trust a new process at work, what's your version of testing it on dummy data first?"

(wait)

By background

A mechanics slide. Testing a server doesn't vary by profession. One shared framing: "Whatever the connection, it gets proven in isolation before it touches your real work, the discipline you'd want anyway." Tie it back to the Praxis habit they'll recognise from the demo: test on dummy data, then run for real. Don't force nine.

Watch for

Inferred slide (video-only source). The Inspector detail is from canonical MCP teaching, not captured prose; verify for a technical room. For non-technical learners, keep it to "connections are tested before they're trusted" and move. Resist the urge to demo the Inspector UI; it adds nothing for this audience.

Lesson 6 · Tools

The client feeds tools to the model, in a loop

The idea

The client lists the server's tools, hands their schemas to Claude, runs whatever Claude asks for, and feeds the result back, looping until there's an answer. This is the same agentic loop a plain chat window doesn't have; MCP is just how the tools reach it.

Say it like this

"Here's the loop you saw in Claude Code 101, now with MCP feeding it. Claude is offered the tools, asks for one, the server runs it, the result comes back, and it goes round again until the job's done. A chat window can't do that: it answers and waits. MCP is simply how the tools get into that loop." (Mirrors course 02 slide 4: the agentic loop; this is the loop reaching outside the folder.)

Pause, then ask

"Where in your week are you the courier, taking a result out of one tool, doing a step, carrying it into another?"
"What would change if that middle carrying just happened, across both tools at once?"

(wait)

By background (the carrying the loop removes)

Investigator: pull the filing, screen the name, drop both into the report, in one pass.
Analyst: read each response, fetch the matching warehouse figure, build the row.
Designer: read the brief, check the spec source, write the manifest line.
Knowledge worker: open the invoice, look up the supplier record, write the CSV row.
Reporter: gather each update, check the tracker, assemble the briefing.
Content: read the brief, pull the back catalogue, draft against house voice.
Form-filler: read the receipt, match it to the template section, file it.
Outreach: read the customer record, pull market context, draft the proposal.
Exec: gather the inputs across drive, chat and finance, write the one-page brief.

Run it live

Kick off: A task in Claude Desktop or Claude Code that needs a connected tool, with the tool calls visible.
Expect: Under a minute.
While it runs: Read each tool call out as it happens: listing, reading, writing. That's the loop on the slide.
When it lands: Count the trips it made that you'd have made by hand.

Watch for

Inferred slide (video-only source). Verify the loop detail for a technical room. The risk for non-technical learners is hearing "loops on its own" and picturing runaway autonomy. Anchor it: the loop still runs under the permission model (course 02 slide 6), and the tools it can reach are only the ones you connected. It loops within the fence you set. (objections.md: permission.)

Lesson 7 · Resources & prompts

Data to pull in, addressed by URI

The idea

A resource is read-only data the server exposes at an address (a URI like docs://documents). No side effects: think GET, not POST. Direct resources return a collection; templated ones take a parameter to fetch exactly one item.

Say it like this

"The second piece. Where a tool does something, a resource just provides something (a document, a record, a list) at a named address, read-only. Nothing changes when you load it; it's safe to read any time. The whole list, or one item by name. Think of it as the read-only side: fetching, never altering." (Contrast it explicitly with the tools slides: same server, but a resource only reads.)

Pause, then ask

"What's the reference material you'd want Claude to be able to read, but never change?"
"Is it usually the whole set you reach for, or one specific item at a time?"

(wait)

By background (the read-only data they'd expose as a resource)

Investigator: the case file set, and any one document by reference: read, never edit.
Analyst: the full set of vendor responses, or one provider's by name.
Designer: the brief set and the brand-token sheet, read-only.
Knowledge worker: the inbox of invoices, or one invoice by number.
Reporter: the week's updates, or one team member's note.
Content: the back catalogue, or one past post by title.
Form-filler: the receipts folder and the template, both read-only.
Outreach: the customer records and the knowledge base.
Exec: the board-pack inputs, or one retainer letter by client.

Brief it like a new hire

On the map: a resource is the reference binder you hand the new hire. They can read it. They can't change it.

Watch for

Read-only is a safety point worth naming: a resource cannot alter your data, only surface it. For regulated rooms this is the comfortable on-ramp: connect the read side first, before any tool that does things. Don't drown them in URI syntax; "a named address, read-only" is enough. (objections.md: IT/compliance, start with what only reads.)

Lesson 8 · Resources & prompts

The app decides which resources to load

The idea

Unlike tools, the model doesn't reach for resources. The application (often the user) chooses what context to bring in, usually surfaced as @-mentions you pick from. Application-controlled. Same server, two different control models: a tool is the model's to call, a resource is the app's to load.

Say it like this

"Here's the difference that matters for trust. A tool, Claude chooses to use. A resource, you choose to bring in, usually by picking it from a list, an @-mention. Claude doesn't go rummaging through your data; it sees a resource only when you, or the app, hand it over. Same connection, but you hold the gate on what's read." (This is the heart of the safety story; say it slowly.)

Pause, then ask

"How would you feel about deciding, each time, exactly which document Claude gets to see, rather than it deciding?"
"Which of your sources would you only ever hand over deliberately, one item at a time?"

(wait)

By background (what they'd hand over deliberately, never auto-loaded)

Investigator: the specific subject's file for this matter: chosen, not browsed.
Analyst: the one provider's response under review this session.
Designer: the brief for the campaign in hand.
Knowledge worker: the month's invoice folder, picked when they start the batch.
Reporter: this week's updates, selected for this briefing.
Content: the two past posts that set the voice for this draft.
Form-filler: this filing period's receipts and the template.
Outreach: the one customer's record for the proposal being written.
Exec: the inputs for this board cycle, chosen deliberately.

Watch for

This is the single most reassuring slide for an IT-restricted or regulated room: the model does not help itself to your data. You, or your app, decide what it sees, item by item. This is "it sees only what you can see" made concrete: it sees what you hand it. Pair with the floor/ceiling for banks and firms (web with no install at the floor, a local model at the ceiling) and frame connecting anything as the IT-discovery conversation, not a switch you flip alone. (objections.md: IT/compliance/privacy; train-the-trainer.md: module 2.)

Lesson 9 · Resources & prompts

Reusable templates the author ships

The idea

A prompt is a tested, parameterized template the server exposes, so the right wording is baked in instead of reinvented each time. The author tunes it once; everyone else just calls it and gets the good version. Hard-won phrasing moves out of people's heads and into the server.

Say it like this

"The third piece. A prompt here isn't what you type. It's a tested template someone wrote once and packaged, so the good wording is built in. The expert tunes it; everyone else just runs it and gets their standard. If that sounds familiar, it's the same idea as the skill file: the rules that lived in your best person's head, written down so the work comes out their way every time." (framings.md: skill file as institutional memory: "those rules lived in your senior person's head and walked out the door at six o'clock; this pulls them onto disk so a new joiner writes the same kind of work on day one." Adapt the role to the room.)

Pause, then ask

"What's a task you do the same way every time, where the 'right way' lives in someone's head?"
"If that wording were written down once and everyone could just run it, what would stop drifting?"

(wait: this lands hard in regulated and professional rooms.)

By background (the packaged prompt they'd ship)

Investigator: the subject-background-report wording, eight sections, cite-or-omit.
Analyst: the vendor-comparison instruction, fixed columns, "no data" rule.
Designer: the asset-manifest brief, every variant listed, "ask client" for gaps.
Knowledge worker: the invoice-to-CSV instruction, leave blanks blank.
Reporter: the five-section weekly-briefing template.
Content: the house-voice draft instruction with its banned constructions.
Form-filler: the receipt-allocation instruction, never drop a line.
Outreach: the five-section proposal template, no invented numbers.
Exec: the four-part exec-brief instruction, state risks factually.

Watch for

Don't conflate this MCP "prompt" with what they type in chat, and don't conflate it with the plain-English skill file from courses 01/02. They're cousins, not the same thing. The MCP prompt is a packaged template a server ships; the skill file is the rules file you write in Claude Code, which is the centre of our method. Name the kinship, then keep the skill file as the headline. (train-the-trainer.md: the skill file is the heart of what we teach.)

Lesson 10 · Resources & prompts

Prompts surface as slash commands

The idea

The client lists the server's prompts and offers them to the user; pick one, fill the arguments, and it expands into the full message. User-controlled: the user triggers it deliberately, not the model and not the app. If you've used a slash command in Claude Code, you've used an MCP prompt.

Say it like this

"And this is how you reach one: it shows up as a slash command. You type the slash, pick the one you want, answer a question or two, and it expands into the full expert wording, ready to run. You're in control: you trigger it, deliberately. If you've ever used a slash command in Claude Code, that's exactly this." (Tie to their own experience: the /plato they ran to get here is a prompt surfaced as a slash command.)

Pause, then ask

"If your team's best version of a task were one keystroke away (a slash and a name), which task would you want it to be?"
"Who on your team reinvents that wording every time today?"

(wait)

By background (the slash command they'd want first)

Investigator: /background-report: the eight-section report, on the named subject.
Analyst: /compare: the vendor table, fixed columns, on the responses in hand.
Designer: /manifest: the full asset list from the briefs.
Knowledge worker: /extract: the month's invoices into the CSV.
Reporter: /briefing: this week's five-section briefing.
Content: /draft: a post in house voice from the back catalogue.
Form-filler: /allocate: this period's receipts into the template.
Outreach: /proposal: one per customer, fixed sections.
Exec: /brief: the one-page board brief from the inputs.

Watch for

Three owners, made vivid across the last three slides: tools the model triggers, resources the app loads, prompts the user triggers with a slash command. This is the one that's most in the user's hands, so lean on it to reassure a control-anxious room. Keep it to the outcome (one keystroke to the standard version), not the mechanics of argument filling.

Lesson 11 · Recap

Three primitives, three owners

The centrepiece. If they take one thing away, it's this.

The idea

The whole protocol in one picture: tools (model-controlled, actions the model calls), resources (application-controlled, data the app loads), prompts (user-controlled, templates the user triggers), all exposed by a server, reached by a client inside your host, over JSON-RPC on stdio (local) or HTTP (remote). Get the owners straight and the rest follows.

Say it like this

"If you keep one thing today, keep this. MCP exposes three things, and the only thing you really need to remember is who controls each. Tools (actions) the model chooses to call. Resources (data) you or the app choose to load. Prompts (templates) you trigger, deliberately. One standard, three pieces, three owners. And the reassurance under all of it: every connection is one you grant, scoped to what you can already see, and you can revoke it." (Mirrors course 01 slide 10 and course 02 slide 13: the one standard, scoped and revocable, it sees only what you can see.)

Pause, then ask

"Of those three (actions Claude takes, data you hand it, templates you run), which feels most useful in your work, and which feels like the one to be careful with?"
"Knowing it sees only what you hand it and you can revoke any connection, does that change which tool you'd connect first?"

(wait: their answer is the use case you build the next conversation around.)

By background (which of the three owners they reach for first)

Investigator: resources first (read the file, change nothing), tools later, after IT.
Analyst: resources to read responses; a tool to pull a live figure once trusted.
Designer: prompts (the manifest command) over the brief set as resources.
Knowledge worker: resources (the inbox) plus the /extract prompt.
Reporter: resources (the updates) and the /briefing prompt.
Content: resources (back catalogue) and the house-voice /draft prompt.
Form-filler: resources (receipts, template) and the /allocate prompt.
Outreach: resources (customer records) and the /proposal prompt; tools last.
Exec: resources (board inputs) and the /brief prompt; a logging tool eventually.

Back to your card

[name], take your card. Give one example each of a tool, a resource and a prompt it would use.
Group, did they get the owners right? Who decides when each one is used?

Watch for

This is the data-safety gate for almost everyone: the slide where the whole worry resolves. Slow right down. Three sentences earn the room: it sees only what you can see, every connection is scoped, every connection is revocable. For banks and firms, frame it as the IT-discovery conversation with floor and ceiling (web at the floor, a local model at the ceiling), not a yes/no you decide alone. (objections.md: IT/compliance/privacy; train-the-trainer.md: module 2.)

One protocol. Three primitives. Any tool, any app.

The idea

The whole course in one line: tools, resources and prompts, exposed by a server and reached by a client inside your host, so context and capability plug in once instead of being rebuilt every time.

Say it like this

"If you keep one thing: MCP is the one standard that lets Claude reach the tools and data you already use, in three shapes (actions it takes, data you give it, templates you run), and it only ever sees what you hand it. Everything else today was the wiring under that. You don't build it; you choose what to connect and what it's allowed to see."

Close with

Their tool from intake, and the next concrete step: "Next time we look at connecting the one you named, and the discovery questions to put to your IT team before we do." Then the session-improvement habit: "at the end of any session, tell it to look back at what went badly and save how you fixed it." (patterns.md: close every session by teaching the system to improve. framings.md: cost, about twenty dollars a month, and stop.)