Every ability built in the AI-Powered WooCommerce course either read data or produced text a person reviewed before it went anywhere: a query, a flag, a generated description, a recommendation phrased from real order data. Nothing in that course moved money or committed to a change a person hadn’t already decided to make. This course is different on purpose, and that difference deserves to be stated in plain language before a single line of code: the abilities from here on can change an order’s status, issue a refund, request a payment action, and recommend products in ways that shape real purchasing decisions. Some of that is reversible. Some of it is not. This lesson draws the line clearly, so every lesson after it can build on a shared understanding of exactly what’s at stake.
AI-Powered WooCommerce completed, especially the official abilities lesson and the order-management automation project. You’ll also want Course 3’s confirmation-gate lesson and Course 4’s permission-gated tools lesson fresh in mind, this course leans on both directly rather than re-teaching them.
Step 1: What Course 7 actually gave you
Look back at what that course’s order-facing abilities actually did. woocommerce/orders-query
reads. woocommerce/order-add-note writes a comment, not a state change. The one lesson
that came closest to “acting,” the fraud-risk scan, had a hard rule built into its own
recap: automation flags, it never cancels, refunds, or fulfills. Even
woocommerce/order-update-status, an official ability that clearly changes state, was
only ever wired to move an order to on-hold, a deliberately conservative, reviewable
target. Every one of those choices was intentional. That course built trust in an
agent’s judgment about your store’s data before ever letting it change what that data
says.
Step 2: What changes when an agent acts
An ability that queries orders can be wrong and nothing happens, the worst case is a bad
answer a person can double-check. An ability that sets an order to completed can
trigger wc_maybe_reduce_stock_levels(), which WooCommerce hooks to the
woocommerce_order_status_completed, woocommerce_order_status_processing,
woocommerce_order_status_on-hold, and woocommerce_payment_complete actions, silently
reducing real stock the moment that status is set. An ability that issues a refund moves
real money out of a real payment gateway. An ability that requests a payment action sits
one careless design decision away from initiating a charge nobody explicitly approved.
None of this is hypothetical or exaggerated for effect, it’s the literal behavior of the
functions this course builds on.
Not because the code in this course is careless, but because any system that touches money and inventory, run by humans or agents, eventually hits an edge case: a misclassified order, a race between two requests, a model that misreads an ambiguous instruction. The entire design posture of this course is “when that happens, what’s the blast radius,” not “let’s assume it won’t happen.” Every lesson that follows answers that question explicitly.
Step 3: A risk tier for every ability in this course
Use this tier model to judge any commerce ability you build, in this course or beyond it.
| Tier | What it covers | Default posture |
|---|---|---|
| 1: Informational | Reading orders, products, carts, generating text a human reviews before it’s used | Can run without per-call confirmation, still permission-gated |
| 2: Reversible-but-consequential | Order-status changes that trigger stock movement, adding notes that change what staff see and act on | Confirmation-gated, tightly scoped permission_callback, no silent execution |
| 3: Financial or destructive | Refunds, exchanges, anything that could initiate a real payment | Confirmation-gated with no override, thresholds enforced in code, never bypassable by configuration alone |
Lessons 2 and beyond will tell you explicitly which tier each ability sits in, and the tier determines how much confirmation machinery that ability is required to carry.
Step 4: The default posture, confirm first, always
Every action-taking ability in this course is built confirm-first: it either uses the
propose-then-confirm pattern from Course 3’s
Designing Confirmation-Gated Agent Actions
lesson directly, or a lighter variant justified explicitly by its tier. None of this
course’s abilities rely on an MCP client’s own “are you sure” prompt as the actual safety
mechanism, since that behavior lives in the client, not your server, and you don’t
control what a different client, or a future version of an existing one, chooses to
show its user. Combined with that, every ability’s permission_callback follows Course
4’s pattern of checking the actual object and its actual state, not just a role, before
allowing anything through.
Test it: audit an ability by its own annotations
Before writing anything new, practice classifying an ability you already have. Pull one of Course 7’s abilities and inspect its metadata:
wp-env run cli wp eval '
$ability = wp_get_ability( "woocommerce/order-update-status" );
echo wp_json_encode( $ability->get_meta(), JSON_PRETTY_PRINT );
'Decide, honestly, which tier it belongs in given what it can actually do to a real
order, not just its label. order-update-status alone, with no wrapper, is a Tier 2
ability at minimum, since any status target is possible unless you scope it, exactly
the gap Lesson 2 closes.
An ability being official and well-tested says nothing about whether the specific
capability it exposes is safe to hand an agent unscoped. woocommerce/order-update-status
will happily set any status you pass it, including ones with real financial and
inventory consequences. WooCommerce shipping the ability is not the same as WooCommerce
deciding it’s safe for your agent to call it without a wrapper. That decision, and the
scoping it requires, is yours.
Recap
Course 7 built trust in an agent’s judgment about your store’s data. This course spends that trust carefully, on abilities that can change an order’s status, move real money, and shape what customers see and buy. Every one of them gets classified into one of three risk tiers, and every tier above the lowest carries confirmation machinery built directly on Course 3’s propose-then-confirm pattern and Course 4’s object-aware permission checks. Nothing in the lessons ahead treats that machinery as optional polish, it’s the actual subject of the course.
Resources & further reading
- AI-Powered WooCommerce course, this site
- Designing Confirmation-Gated Agent Actions, this site
- Building Permission-Gated Tools, this site
- MCP tool annotations, modelcontextprotocol.io
- Abilities API reference, developer.wordpress.org