Every pattern in this lesson already exists elsewhere in this track. Course 22 built a
duplicate-and-approve workflow so an AI agent never edits a live page builder post
directly, and a production guardrail using the real wp_get_environment_type()
function so destructive abilities refuse to run outside staging or development. What’s
new here is the context: a client’s site is not your own test environment, and a
mistake on it has a client watching, a real customer-facing site affected, and a
relationship at stake. This lesson is about applying those exact same technical
patterns as a non-negotiable part of how you deliver AI work to clients, not a new
pattern to learn.
Course 22’s duplicate-and-approve workflow and production guardrail lessons, and Course 4’s permission_callback patterns. This lesson doesn’t repeat that code in detail, it applies it to a client-delivery process.
Step 1: Why this matters more, not differently, for clients
The technical risk of an AI agent making an unreviewed, destructive change is the same whether the site is yours or a client’s. What differs is the blast radius of getting it wrong: your own test site produces an annoying rollback, a client’s live site produces a client who watched something break in front of their own customers, and who now questions every future AI-driven change you propose. That asymmetry is the reason staging-first delivery belongs in this course as a firm rule, not a best practice you apply when convenient.
A client asking for a same-day fix is exactly the situation where skipping staging feels most tempting, and exactly the situation where a mistake is most visible and most damaging. Treat “we’re in a hurry” as a reason to move faster inside the staging-first process, not a reason to skip it.
Step 2: Every client engagement gets its own staging environment
Course 22’s guardrail depends on wp_get_environment_type() correctly reporting
'staging' or 'development' on a non-live copy of the site. That only works if every
client site actually has a staging environment in the first place, and if its
WP_ENVIRONMENT_TYPE constant is set correctly, both of which are onboarding steps,
not assumptions to make later.
// File: wp-config.php (client staging environment)
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Step 3: The same guardrail code, reused across every client
The reusable ability library pattern from Course 8 (covered in this course’s Lesson 6 for scaling delivery generally) is exactly where this guardrail belongs: written once, shipped inside every client-facing plugin your agency deploys, rather than re-implemented per engagement.
// File: src/Guardrails.php (part of a shared agency ability library)
namespace MyAgency\ClientAbilities;
class Guardrails {
public static function is_safe_for_ai_write_actions(): bool {
return in_array(
wp_get_environment_type(),
array( 'local', 'development', 'staging' ),
true
);
}
}Every destructive ability registered for any client reuses the same check, inside its
own permission_callback, exactly the way Course 22 wired it into the page builder
editing abilities:
// File: src/Abilities/ClientContentAbilities.php
'permission_callback' => function ( $input ) {
if ( ! \MyAgency\ClientAbilities\Guardrails::is_safe_for_ai_write_actions() ) {
return new WP_Error(
'production_environment_blocked',
__( 'This action is disabled outside staging and development for this client site.', 'my-agency' )
);
}
return current_user_can( 'edit_posts' );
},Because this lives in a shared library (Course 8’s pattern), a new client engagement doesn’t mean writing this check again, it means depending on the library and getting the same guardrail automatically, on day one, without anyone having to remember to add it.
Step 4: A delivery checklist that makes this a process, not a hope
Recap
Staging-first delivery for client work is Course 22’s duplicate-and-approve workflow
and wp_get_environment_type() production guardrail, applied without exception to
every client engagement, because the cost of skipping it is a client relationship, not
just a rollback. Every client needs a real, correctly-configured staging environment
established during onboarding, and the guardrail code itself belongs in a shared
library (Course 8’s pattern, covered next in Lesson 6) so it ships automatically with
every new client’s plugin rather than being re-added by hand each time. A short,
concrete delivery checklist, not a general intention to “be careful,” is what actually
keeps an AI-driven change off a client’s live site until it’s been reviewed and
approved.
Resources & further reading
- The Duplicate-and-Approve Workflow, Course 22, Lesson 5
- Production Guardrails: Auto-Deactivating on Live URLs, Course 22, Lesson 6
- wp_get_environment_type() function reference, developer.wordpress.org