The whole unified AI platform pitch, the thing vendors sell as a workflow layer, fits in one WordPress function call:
<?php
$response = wp_remote_post(
'https://api.openai.com/v1/chat/completions',
array(
'timeout' => 30,
'headers' => array(
'Authorization' => 'Bearer ' . BBIOON_AI_KEY,
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array(
'model' => 'gpt-4o-mini',
'messages' => array(
array(
'role' => 'system',
'content' => 'Write a plain 40 word product summary for a shop listing.',
),
array(
'role' => 'user',
'content' => $product->get_description(),
),
),
) ),
)
);That’s wp_remote_post() sending a product description to a model endpoint and getting JSON back over the same HTTP API every WordPress site already has (the function docs are worth a read). No tab switching, no prompt rewritten three times for three tools. The model name is a string in my code, so I can route it, cache it and price it. That’s where AI workflows in WordPress should start.
The article that got me thinking about this is a sponsored piece on Towards Data Science, which argues that teams stitching ChatGPT, Claude and Canva together by hand should move to one platform that keeps context across every step, with Abacus.AI as the sponsor. I agree with the diagnosis. I disagree with the fix for a WordPress or WooCommerce site, because the workflow layer the article wants is the layer the site already runs on.
The fragmentation complaint is real
The example in the source, drafting in one tool, refining in another, visuals in a third, matches the shape of most content workflows I run into. The cost hides in the seams between tools: you rewrite the same prompt to fit each app’s conventions, reformat output for the next step, and lose whatever context didn’t copy over. The author points to APA research on multitasking suggesting context switching can cut efficiency by up to 40 percent. I can’t verify that figure for AI tool stacks specifically, but the direction feels right. An hour of writing turns into an hour of clipboard management, and the hour gets eaten by handoffs that no single tool records.
The second complaint, cost, is newer and I’d argue bigger. As the source notes, top-end models are more expensive than the small ones, and the vendors price by token (OpenAI publishes its lineup and pricing per tier). Reprocessing the same text across several tools compounds that quietly. When prompts live in browser tabs, nobody is counting tokens, and the bill shows up as a surprise at the end of the month.
Why I won’t put a platform between a store and its data
I part ways with the recommendation on the fix. A unified platform means one more vendor sits between the site and every model call. For a personal blog, that trade is fine. For a store, the payload is product data, order notes, support text, sometimes customer names. Every request becomes a data export you have to explain to the client, and “read the vendor’s policy” is not an answer a client accepts for long. If the call comes from the client’s own plugin and goes straight to the model vendor, the data path is one hop, and when the client asks where their data went, you can answer in one sentence.
There’s a maintenance side too. Platforms rotate model lineups, change pricing and redesign interfaces, and every change becomes your workflow’s problem. A WordPress stack already leans on enough outside services for mail, search and payments. I’m reluctant to add one that owns the logic as well. When the workflow is a function in the client’s plugin, I can read it, diff it, and turn it off in an afternoon. That’s the standard I hold any automation to, and my list of things I don’t let AI tooling run on client sites keeps growing.
The glue the article wants, one step’s output feeding the next with context kept, isn’t new machinery either. WordPress passes state in options, post meta and transients, runs steps on cron or Action Scheduler, and speaks HTTP to anything. The REST API handbook puts it plainly: any language that can make HTTP requests and interpret JSON can work with WordPress. Model endpoints live on the same web. Writing that glue is a day or two of PHP.
Building AI workflows in WordPress
Start with one step that repeats. Product short descriptions are the usual first candidate on a WooCommerce store: same format, same length, no judgment calls. Run it as a WP-CLI command rather than on save_post_product, because you want a human to eyeball the output before it lands anywhere, and because bulk runs inside the editor are the wrong place for 30 second network calls. If you’re writing more of these commands, I have notes on structuring them so they stay testable.
wp ai descriptions --post_type=product --only=missingThe routing the source describes, small models for simple tasks, big ones only where the copy needs them, is a few lines in your own plugin:
<?php
function bbioon_model_for( string $task ): string {
return 'short_description' === $task ? 'gpt-4o-mini' : 'gpt-4o';
}
$summary = get_transient( 'bbioon_desc_' . $product->get_id() );
if ( false === $summary ) {
// call the model with bbioon_model_for( 'short_description' ), then:
set_transient( 'bbioon_desc_' . $product->get_id(), $summary, WEEK_IN_SECONDS );
}That’s the source’s whole “economical intelligence” argument, except you decide the threshold instead of a vendor. Keep the transient key tied to a hash of the description, or you’ll serve stale copy after an edit. Keep the API key in wp-config.php as a constant, never in the options table, because options travel with database exports.
One failure mode to avoid is calling the model inline for every product in a big catalog. A long external call inside save_post makes the admin feel broken, and hosts tend to kill slow PHP workers. Queue the work with Action Scheduler, which WooCommerce ships with, and process in batches of ten or twenty. If agents or CLI jobs will touch production at all, run them against a copy first; the failures here are quiet ones like stale transients rather than thrown exceptions.
If you’d rather not build this yourself, I do this kind of work for client stores: take the most repeated AI step, wire it into their own plugin with routing and caching, and leave the publishing decision with a human.
Where the platform side has a point
I don’t want to pretend the homegrown answer is free. If nobody on the team writes PHP, a routing layer becomes one more thing that rots, and prompt tweaks that should take a minute become a deploy. People will quietly route around you and go back to browser tabs, and then you have the old fragmentation plus a dead plugin. Platforms also give you a place to compare models on the same task, which my version doesn’t unless you add logging.
So the split, for me, is about data. Internal content work that never touches customer data can go on a unified platform; that’s a tool choice like any other. Anything that runs inside a client’s WordPress install should be code the client owns, with calls that go from their server straight to the model.
What I’d do this week
On the next client site I’d list every place a person currently pastes prompts by hand, take the single most repeated one, and replace it with one CLI command, a small model and a transient cache. The output would go to drafts for review, and I’d watch the token spend for a month before adding a second step. That’s the shift the article describes, done with pieces the site already has.
