The enrichment run finished clean. Every product came back as valid JSON, the importer wrote all 800 rows, and the error log stayed empty. The problems showed up weeks later: descriptions had dropped the conditional sizing rules and mentioned a fabric blend that appears nowhere in the supplier feed.
Clara Chong ran into the same kind of problem turning 100 messy compliance PDFs into structured rules, and wrote it up in Stop Using LLMs Like Giant Problem Solvers on Towards Data Science. Her conclusion was that output which looks fine is the dangerous kind. You only catch it by hand-sampling a large corpus, and nobody keeps doing that forever.
I agree with her fix, and for WordPress work I’d go one step further. The deterministic loop she had to build herself (one document at a time, single-item retries, cached progress, an orchestrator watching the run) already ships with WooCommerce. It’s Action Scheduler, and most AI plugins I open don’t use it. That’s the first thing I’d change.
What breaks when the agent owns the batch
The brute-force version puts the whole job in one prompt: here’s the data, the schema, the business rules, go. The output passes validation, because JSON validity says nothing about content. In her sample some rules came out too broad, some were missed entirely, and nuance got flattened. On a store that means product data that’s plausible and wrong, and it survives review precisely because it reads well.
The other cost is operational. A job that size has one retry unit: the entire run. If it dies at item 700 of 800, you rerun and pay for all of it, and you can’t pull out item 412 on its own to see why it came out wrong.
AI batch processing on the queue you already have
Action Scheduler is the job queue bundled with WooCommerce. It already runs subscription renewals and webhook deliveries on stores you manage, and it handles batching, retries, failure logging and an admin screen under WooCommerce > Status > Scheduled Actions. Schedule one action per item, and the model call becomes a small unit you can retry and inspect:
<?php
add_action( 'bbioon_enrich_product', 'bbioon_run_enrichment' );
function bbioon_schedule_batch( array $product_ids ) {
foreach ( $product_ids as $id ) {
as_enqueue_async_action(
'bbioon_enrich_product',
array( 'product_id' => $id ),
'bbioon-enrichment'
);
}
}
function bbioon_run_enrichment( int $product_id ) {
$source = get_post( $product_id );
// checkpoint: skip items a previous run already finished
if ( ! $source || get_post_meta( $product_id, '_bbioon_enriched', true ) ) {
return;
}
$result = bbioon_call_model( $source->post_content );
$decoded = json_decode( $result, true );
if ( json_last_error() !== JSON_ERROR_NONE ) {
throw new Exception( 'Bad enrichment JSON for product ' . $product_id );
}
update_post_meta( $product_id, '_bbioon_enrichment', $decoded );
update_post_meta( $product_id, '_bbioon_enriched', 1 );
}Throwing the exception marks that single action as failed, and you can retry it from the admin screen or with wp action-scheduler run, without touching the other 799. The checkpoint meta is the cached progress from her article: a rerun only processes the items that didn’t finish. If you’re splitting bigger jobs, this earlier post on splitting background jobs covers the mechanics.
What the model still owns
Shrinking the job means taking away the work that code does better. The model reads messy source content and decides what matters; that part needs semantic judgement, as Chong says, because the documents don’t follow one pattern. Code enforces the schema, generates IDs, writes the rows and checks traceability. Prepare the input too: strip shortcodes, footers and boilerplate before the call, since irrelevant context is where the model latches onto the wrong detail. I wrote more about that in why agent context starts outside the transcript. (Chong settled on five parallel workers; with a hosted API your rate limit will set the number.)
Make the output checkable
Store a reference with every generated field: the source post ID plus the exact snippet it came from, in post meta. Then auditing is a script that checks whether the post exists and whether the quoted text is in it. Her lightweight eval idea fits here too: run ten documents through the workflow before the batch and review those by hand. It’s a boring hour, but it beats rerunning 800 rows.
If you’re wiring an AI feature into a store and the runs keep dying halfway, or you can’t prove what the model changed, that’s the kind of build I take on. Happy to look at the pipeline.
Start with a site that already does AI work. Open WooCommerce > Status > Scheduled Actions, filter for failed, and see how many model calls are waiting. Then run a ten-item batch on staging and let one item fail on purpose. If the retry button fixes just that item, the loop works.
