Scaling Delivery Without Scaling Headcount

An agency that rebuilds its ability registration, MCP server setup, and safety guardrails from scratch for every new client hits a hard ceiling: revenue can only grow as fast as billable hours can be added, since every new client is roughly as expensive to deliver as the last one. The way out isn’t hiring faster, it’s the same answer software engineering has always had for repeated work: standardize the reusable parts into a shared library once, so that a new client engagement means configuring and depending on that library rather than rewriting it. Course 8 already built the real technical pattern for this. This lesson applies it specifically to running a multi-client delivery practice.

Step 1: The trap of rebuilding per client

Imagine a small agency managing twelve client sites, each with its own hand-written ability registration copied and lightly modified from the last client’s code. A security fix to one client’s permission_callback logic, discovered after an incident, has to be manually reapplied to eleven other codebases, and there’s no reliable way to confirm all eleven actually got it. That’s the exact problem a shared, versioned library is built to remove.

Step 2: The same library pattern, now shared across clients

Course 8 covered structuring an ability library as a Composer package with PSR-4 autoloading and a guard against being loaded twice. For an agency, that package becomes a genuine internal product: the set of abilities, permission patterns, and guardrails (including Lesson 5’s environment check) that show up in most client engagements, versioned and improved centrally instead of copy-pasted.

What does not belong in the shared library is anything genuinely client-specific: a client’s own custom post types, their particular brand voice for a chatbot (Lesson 3), or a one-off integration with a system only that client uses. The library’s job is to cover the eighty percent that repeats, the same split Lesson 1 drew between what productizes and what doesn’t.

Step 3: A templated client setup, not a blank plugin

With the library in place, standing up a new client becomes a scaffolding exercise rather than a coding exercise. A minimal, real shape for that scaffold:

my-agency/client-scaffold/
├── composer.json          (requires my-agency/wp-client-abilities: ^2.0)
├── client-config.php      (this client's specific post types, capabilities, branding)
└── my-agency-client.php   (plugin bootstrap, loads the library and this client's config)

// File: my-agency-client.php
require_once __DIR__ . '/vendor/autoload.php';

add_action( 'plugins_loaded', function () {
	// The shared library: common abilities, MCP server helper, guardrails, audit log.
	\MyAgency\ClientAbilities\Registrar::init();

	// This client's own configuration: which post types, which custom abilities.
	require __DIR__ . '/client-config.php';
} );

// File: client-config.php (the only file that changes meaningfully per client)
add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'client-acme/list-service-listings', array(
		'label'               => __( 'List Acme service listings', 'my-agency' ),
		'category'            => 'client-acme',
		'input_schema'        => array( 'type' => 'object', 'properties' => array() ),
		'permission_callback' => array( \MyAgency\ClientAbilities\Guardrails::class, 'is_safe_for_ai_write_actions' ),
		'execute_callback'    => function () {
			return get_posts( array( 'post_type' => 'service_listing', 'numberposts' => 20 ) );
		},
	) );
} );

New client onboarding now means filling in client-config.php with that client’s own post types and any genuinely custom abilities, while the shared library keeps providing the guardrails, common abilities, and MCP server setup identically for every client on the same version.

Step 4: What still genuinely needs a human

Standardizing the repeatable parts of delivery isn’t the same as removing judgment from the engagement entirely. Discovery (understanding a specific client’s content model and business rules), the data-handling conversation from Lesson 4, and reviewing what an AI-driven change actually did before approving it (Lesson 5) all still require a person paying attention. Scaling delivery means spending more of your team’s time on those judgment-heavy parts and less on rewriting boilerplate, not eliminating the need for people entirely.

Recap

Rebuilding ability registration, MCP server setup, and safety guardrails for every new client caps how fast an agency can grow, since delivery cost stays roughly constant per client. Course 8’s reusable ability library pattern, packaged as an internal Composer package and depended on by every client’s plugin through a thin scaffold, turns the repeatable eighty percent of delivery into configuration instead of new code, while bug fixes and guardrail improvements apply to every client at once instead of client-by-client. What doesn’t scale away, and shouldn’t, is the judgment-heavy work: understanding a specific client’s needs and reviewing AI-driven changes before they reach a live site.

Resources & further reading

• Building Reusable Ability Libraries, Course 8
• Safe, Staging-First Delivery, this course, Lesson 5, the guardrail this library ships