Lesson 1 opened with a claim: the difference between Course 7 and this course is the difference between answering and acting, and acting carries real financial and operational risk. Seven lessons later, that claim has been built out into seven working abilities, and this closing lesson is the honest accounting: exactly what each one does, which tier it lives in, and where a human is structurally required, not just invited, to be in the loop before something real happens.
The whole of this course. This lesson introduces no new mechanics, it’s a deliberately honest retrospective on the seven lessons before it.
Step 1: Every ability this course built, and its real risk tier
| Ability (Lesson) | Tier | What actually guards it |
|---|---|---|
| Order status change and note (Lesson 2) | 2 | A status-transition whitelist checked against the order’s real current state, plus propose/confirm |
| Refund (Lesson 3) | 3 | Propose/confirm, a hard-coded threshold, and a second, distinct approving user above it |
| Exchange order creation (Lesson 3) | 2 to 3 | A pending-only new order, no payment or fulfillment, reviewed like any other order |
| Payment action request (Lesson 4) | 3, never executed by the ability itself | No gateway call anywhere in the ability, a human carries out the actual charge through WooCommerce or the gateway’s own trusted interface |
| Cart recovery draft (Lesson 5) | 1 to 2 | Draft-only, a human reads and sends, never an automatic email |
| Conversational product search (Lesson 6) | 1 | Read-only, phrased only from real query results, reasonably public |
| Hybrid recommendations (Lesson 7) | 1 | Read-only, phrased only from real candidates your own PHP ranked |
Notice the pattern: risk tier, not code complexity, decided how much confirmation machinery an ability carried. The two lowest-risk abilities in this course, search and recommendations, needed none of it. The two highest-risk, refunds and payment requests, needed the most, and payment requests needed something stronger than confirmation machinery entirely: a boundary the ability’s own code cannot cross no matter how it’s called.
Step 2: The one rule that held across every Tier 2 and Tier 3 ability
Every ability in this course that could meaningfully hurt something, an order, an inventory count, real money, used the same propose-then-confirm shape from Course 3: a short-lived, single-use, user-bound token issued by a step that only describes the effect, and a separate step that requires that exact token before anything executes. None of it relied on an MCP client’s own confirmation UI as the actual safety mechanism, because that behavior lives in the client, not in code you control. This wasn’t a stylistic choice repeated for consistency, it was the only pattern in this whole course that held up under the question Lesson 1 opened with: what happens the one time a model misreads the situation, or a client doesn’t ask “are you sure” at all.
Every propose/confirm pair in this course still sat behind a permission_callback
built on Course 4’s object-and-state pattern, checking the order’s real status, the
refund’s real amount against a real threshold, the requesting user’s real capability.
Confirmation answers “did a human actually agree to this specific action.” Permission
answers “should this account be able to request this kind of action at all.” This
course needed both, on every Tier 2 and Tier 3 ability, not one standing in for the
other.
Step 3: The one line this course refused to cross
Lesson 4 was explicit, and worth restating plainly here: no ability in this course calls
a payment gateway to initiate a charge, and this course does not teach that pattern at
any tier. That’s not a gap to close in a hypothetical Lesson 9, it’s a deliberate,
permanent boundary, because payment gateways sit inside PCI-DSS’s compliance scope and
because a mistaken charge is a fundamentally different kind of harm than a mistaken
status change or an over-cautious refund threshold. If a real product genuinely needs
AI-initiated payment automation beyond what a request-and-human-executes pattern
provides, that need belongs in front of a PCI-qualified security assessor, not in an
execute_callback.
Step 4: Where to go from here
Details that felt abstract on a first read through Course 3 or Course 4 usually click once you’ve seen them carrying real financial weight, which is exactly what this course asked them to do.
Recap
Every ability in this course earned its confirmation machinery, or the lack of it, from a real risk tier, not from habit. Order-status changes and refunds required propose/confirm built on Course 3, with a refund threshold and second-approver rule added on top for the highest-stakes case. Payment processing required something stronger than confirmation, a hard boundary the ability’s own code cannot cross. Search and recommendations, genuinely read-only and low-risk, needed neither. That’s the whole discipline this course asked you to practice: match the safeguard to the actual consequence, every time, and never let a lower-risk pattern quietly cover a higher-risk action because it was already built and convenient to reuse.
Resources & further reading
- Designing Confirmation-Gated Agent Actions, this site
- Building Permission-Gated Tools, this site
- WooCommerce’s Official MCP Abilities, this site
- Abilities API reference, developer.wordpress.org