By Greg Nowak. Updated 19 August 2026.
WordPress 7.0 removed a frustrating piece of work from AI-enabled plugin development. Instead of building a separate integration for every model provider, a plugin can use a WordPress-native PHP client and let the site’s configured providers handle the connection.
That is useful infrastructure. It is not an AI product strategy, a permission system or a cost-control policy.
For business owners, operations leads and agencies, the important question is therefore not “Can our plugin call AI?” It is “Which task should AI perform, for whom, using what data, at what cost, and what happens when it fails?” Those decisions still belong to the plugin and the team operating it.
The client solves plumbing, not product risk
The AI Client provides a common prompt builder, model selection, normalized responses, structured JSON options and familiar WP_Error handling. Provider credentials are managed through WordPress Connectors rather than copied into every feature plugin.
WordPress Core deliberately ships without a model provider. The site administrator chooses and configures provider plugins, so your feature cannot assume that a particular model, modality or option will be available. A model preference is a preference, not a guarantee.
Use the client’s support checks before presenting an AI action. If the configured providers cannot satisfy the request, hide or disable the control before someone spends time preparing input.
| Decision | Plugin responsibility | Safe default |
|---|---|---|
| Job | Define the one task AI may perform | Use a feature-specific endpoint |
| Access | Decide which users and records are eligible | Check the narrowest relevant capability |
| Input | Limit accepted content and request size | Validate against an explicit schema |
| Output | Decide what may be suggested or changed | Require approval before publishing |
| Consumption | Control requests, tokens and commercial exposure | Set per-request and per-user limits |
| Failure | Preserve the underlying workflow | Keep the original input and offer retry |
Put a business action behind every endpoint
The separately distributed JavaScript client can accept arbitrary browser-side prompts through REST endpoints. WordPress restricts that interface to a high-privilege capability by default and does not recommend it as the foundation for a distributed plugin.
A better contract describes the business action, not the prompt. For example, an endpoint might accept a post ID and return a proposed editorial summary, approved taxonomy terms or related internal content. It should not accept unrestricted instructions from the browser.
Prompt construction, model preferences and output schemas remain on the server. The endpoint should:
- authenticate the request and verify a nonce where appropriate;
- check a capability that matches the content and proposed action;
- confirm that the user may access the specific object;
- validate length, type and allowed values before creating a prompt;
- return a defined response shape rather than raw provider output.
This smaller contract is easier to explain, test and audit. It also lets you change prompts or providers later without breaking the interface used by the editor.
Use schemas as boundaries, not decoration
Structured output is valuable only when the surrounding workflow treats the schema as a hard boundary. Reject missing fields, unexpected values and malformed JSON instead of guessing what the model intended. A plausible response is not necessarily a valid one.
WordPress 7.1 improves schema preparation for AI function declarations and adds execution filters around the Abilities API. These filters can support additional authorization policy, rate limiting, maintenance mode, input transformation and controlled recovery. They are useful extension points, but they do not replace the ability’s own permission callback or input and output validation.
Provider differences still matter. Some providers accept a smaller JSON Schema vocabulary or interpret options differently. Test the actual provider combinations your customers use, including fallback models, rather than validating against one successful development setup.
Make consumption and failure visible
using_max_tokens() can limit an individual generation, while the full result methods expose token usage plus provider and model metadata. Capture those details where they are available. They help answer operational questions: Which feature is consuming requests? Did a fallback model respond? Is usage growing faster than the value delivered?
Token limits alone are not a budget. Add application-level rules such as requests per user, maximum input size, daily or monthly allowances and a site-wide disable switch. The wp_ai_client_prevent_prompt filter can stop selected calls before they reach a provider, returning WP_Error and allowing the interface to fail cleanly.
Design the non-AI path at the same time as the successful path. Timeouts, unavailable credentials, unsupported providers and invalid structured output should never erase a draft or block the ordinary editorial workflow. Show a useful error, preserve the input and let the user continue manually.
New capabilities create new operating work
The underlying PHP client now documents embedding generation for meaning-based retrieval. That makes related-content discovery and semantic search more approachable, but an embedding call is only one step. A production feature still needs rules for chunking, storage, re-indexing, deletion, access filtering and provider changes.
The same principle applies to streamed generation: faster visual feedback does not alter authorization, data handling or cost exposure. Hosting timeouts and interrupted requests also need to be tested before streaming becomes part of a promised user experience.
Existing integrations need a deliberate migration
The standalone wordpress/wp-ai-client package is deprecated in favor of the client built into WordPress 7.0. A plugin requiring WordPress 7.0 or later can normally remove redundant PHP client dependencies and replace direct client calls with wp_ai_client_prompt().
If older WordPress versions must remain supported, do not load a second copy of the SDK on 7.0 or later. The official migration guidance uses a conditional autoloader:
if ( ! function_exists( 'wp_get_wp_version' ) || version_compare( wp_get_wp_version(), '7.0', '<' ) ) {
require_once __DIR__ . '/vendor/autoload.php';
}Test this as a compatibility change, not a mechanical rename. Duplicate or mismatched client classes can interfere with provider discovery and credential validation.
Start with one controlled win
A sensible first release is narrow: one useful task, one endpoint, one permission model and one human approval point. Measure whether it saves time or improves a business outcome before widening the surface area.
If you are deciding where AI belongs in a WordPress workflow, Greg can help define the feature, map its data and permissions, implement the guarded endpoint and run a contained production rollout.
Related on GrN.dk
- When Google can call the business, your local data stops being cosmetic
- Agentic AI: What It Is, How It Works, and When to Use It
- AI Crawler Control for Business Websites: Protect Content Without Vanishing from Search
Need help with this kind of work?
Plan a guarded WordPress AI feature Get in touch with Greg.
