Emma sent James a file the night before. "Read this before our session tomorrow. It is a transcript of a real TutorClaw tutoring session. Your job: figure out what is happening behind the scenes at every turn."
James opened the file on his phone during the commute. It looked like a WhatsApp conversation between a learner named Aisha and an AI tutor. But someone had annotated the right side of every message with tool names and data flows. By the third exchange, James was hooked. He could see the machinery behind the conversation: one tool checking who Aisha was, another pulling chapter content, a third generating a question tailored to her exact stage in the lesson. Nine tools in total, firing in a sequence that felt invisible to the learner but obvious to anyone reading the annotations.
"I could see the whole product," James told Emma the next morning. "Every tool, every data lookup, every decision. It was like reading the stage directions while watching the play."
You are doing exactly what James is doing. Below is a transcript of a tutoring session. Your job is to trace which tools fire and when, then map the architecture that makes it work.
No code in this chapter. The goal is the mental model. Code starts in Module 9.3, Chapter 3.
Aisha is a new learner. She has never used TutorClaw before. She messages the tutor on WhatsApp.
Twelve turns. Nine tools. One continuous conversation that felt natural to Aisha. She never knew tools were firing. She just had a tutor.
Read the transcript again. Group the tools by what they do, not when they fire.
State tools manage who Aisha is and where she stands:
Content tools deliver the course material:
Pedagogy tools make the conversation a teaching session, not a chatbot:
Code tool lets her practice:
Monetization tool powers the business:
Nine tools. Three groups handle the learning (state, content, pedagogy). One handles practice (code). One handles the business (monetization). That is the entire product.
TutorClaw has two components. Not three, not five. Two.
Component 1: The MCP Server. This is where the 9 tools live. It runs locally during development. JSON files in a data/ directory store learner state. Markdown files in a content/ directory hold the course material. The mcp-builder skill from Module 9.2 helps Claude Code build each tool. No database server, no cloud storage, no deployment scripts.
Component 2: The Shim Skill. A small skill file (roughly 50 lines) that provides a PRIMM-Lite offline fallback for Chapters 1 through 5. When the MCP server is unreachable (network down, server stopped, maintenance), the agent still follows the teaching methodology instead of falling back to generic conversation. The shim covers the free-tier content only. Paid content requires the live server.
That is the entire product. Everything else, the compute, the messaging, the agent loop, the WhatsApp connection, belongs to the learner's OpenClaw.
James stared at the architecture diagram. Something felt backwards.
"At the shipping company, we owned the port. The cranes, the berths, the fuel depot, the customs office. Shipping lines came to us. We charged them for using our infrastructure."
Emma nodded. "And who owns the infrastructure here?"
"The learner does." James traced the flow on his napkin. "Their OpenClaw handles compute. Their WhatsApp connection handles messaging. Their agent loop handles the conversation. We just... provide the content and the teaching logic."
"The learner's OpenClaw IS your infrastructure. You do not pay for servers. You do not manage uptime. You do not handle WhatsApp API credentials. The learner already has all of that. Your product plugs into their platform."
James sat with that for a moment. "So it is like... an app on their phone. The phone provides the screen, the processor, the network connection. The app provides the experience."
"Exactly. Your phone manufacturer does not charge Spotify for using the screen. The learner's OpenClaw does not charge you for using the agent loop. You focus entirely on the product: the tools, the content, the teaching methodology, the brand."
This is platform inversion. In traditional software, the product builder provides and pays for all infrastructure. In an OpenClaw app, the learner's platform provides infrastructure. The product builder provides content, pedagogy, and brand. Zero servers to manage. Zero hosting costs during development. The economics shift entirely: your costs are content creation and Stripe transaction fees, not AWS bills.
James had a follow-up. "If the learner's OpenClaw runs my tools, can they see my course content? My teaching algorithms?"
"What does the learner's agent actually see?"
James thought back to the transcript. "Tool results. When get_chapter_content fires, the agent gets back the chapter text for that specific request. When generate_guidance fires, the agent gets back a teaching prompt for that specific stage."
"Does the agent get the entire content library?"
"No. It gets one chapter at a time, on demand."
"Does the agent get the PRIMM-Lite algorithm?"
"No. It gets the output of the algorithm for the current learner at the current stage."
"That is the boundary." Emma drew a vertical line on the napkin. "The MCP server sits on your side. The raw content files, the teaching logic, the learner state, the tier-gating rules: all of that stays on the server. The learner's OpenClaw calls tools across the MCP boundary and gets results back. It never sees the source files. It never downloads the content library. It never inspects your pedagogical algorithms."
The MCP boundary is the intellectual property boundary. The learner's agent is a client that calls functions and receives responses. The implementation behind those functions, the content, the teaching methodology, the business logic, stays on your side. This is the same model as any API: the client knows what it can ask for, not how the answer is computed.
James closed his laptop and leaned back. "Nine tools. JSON files for state. Markdown files for content. A shim for when the server is down. That is the entire thing."
"That is the entire thing."
"At the shipping company, we had a saying: 'If you can fit the ops manual in one binder, you can run the warehouse.' My first MCP project, I thought I needed a database, a cloud bucket, a VPS, load balancers. I spent three weeks on infrastructure before I wrote a single tool." Emma paused. "The product needed four tools and a folder of JSON files. I had built a warehouse for a lemonade stand."
James grinned. "So next chapter, we design the nine tools?"
"Next lesson, we write job descriptions for nine functions. Input, output, access rules, dependencies. Every tool gets a specification before Claude Code writes a line of code. You learned that pattern in Module 9.2 with one tool. Now you scale it to nine."
"The blueprint before the build."
You have not started building yet. That is Module 9.3, Chapter 3. Use these prompts in ChatGPT, Claude, Gemini, or your preferred AI assistant.
What you are learning: Tracing tool sequences is the core skill of this lesson. A well-designed tool surface means each tool has a clear trigger. This exercise tests whether you can predict the system's behavior from a learner message, the same way an operations manager predicts warehouse flow from an incoming shipment manifest.
What you are learning: Platform inversion is not TutorClaw-specific. Any OpenClaw app follows the same pattern: the learner provides the platform, you provide the product. Designing for your own domain forces you to separate infrastructure concerns (which you do not own) from product concerns (which you do). The tools you list here will inform your thinking for the rest of Module 9.