The advice going around about production-grade AI agents is to push every decision into a prompt, however trivial the decision is. I see it in “smart” weather alerts and in inventory bots, and it costs both performance and reliability.
I thought we were past the “AI-first” phase where every step is a black box. Then I started reading codebases that fetch forecast data, hand it to an LLM and ask “Did the weather change significantly?” That is vibe-based logic, and in production it buys you a 3 AM debugging session.
The problem with probabilistic interpreters
Asking an LLM whether a value changed “significantly” asks a stochastic process to approximate a deterministic rule. Language models handle language; they do not enforce numeric boundaries. A model can call a 2°C drop significant on Tuesday and skip a 3°C drop on Wednesday because the prompt was worded a little differently. Production-grade AI agents need the same answer every time.
It is slow and expensive as well. Every poll turns into a paid API call with network latency attached, for work a PHP if statement finishes in microseconds. Those judgments are also close to untestable, since you cannot assert a fixed result against a probabilistic output.
I have written about technical debt in AI development before, and the vibe-based decision boundary is a messier case than most. If you can write an assert() for it, it does not belong in a prompt.
Designing for stability
Split the job. A deterministic gatekeeper does the arithmetic, and the LLM narrates the result. That split is part of why developers are moving beyond LangChain toward native architectures they can control.
What the gatekeeper handles:
- Compares validated snapshots with PHP comparison operators.
- Checks the delta against a threshold stored in a WordPress option.
- Weighs how reliable the data is (forecast horizons) before any AI hook runs.
The pattern in practice
Rather than shipping raw data to an LLM every 6 hours, keep the last state in a Transient and call the narrator only when a threshold is crossed. That cuts the API bill and the noise.
<?php
/**
* Evaluates weather change deterministically before calling the LLM.
*/
function bbioon_should_notify_weather_change( $new_data ) {
$last_check = get_transient( 'bbioon_last_weather_state' );
// If we have no previous data, just store and exit.
if ( ! $last_check ) {
set_transient( 'bbioon_last_weather_state', $new_data, 6 * HOUR_IN_SECONDS );
return false;
}
$threshold = apply_filters( 'bbioon_weather_alert_threshold', 20.0 ); // 20% change
$delta = abs( $new_data['rain_prob'] - $last_check['rain_prob'] );
// Deterministic Boundary: No LLM needed for this check.
if ( $delta < $threshold ) {
return false;
}
return true;
}Where the LLM belongs
Once your own logic has decided that an alert should fire, then you call the OpenAI API. You are not asking it to judge anything. You hand it the structured result, the from value, the to value and the delta, and ask for a sentence that reads naturally.
That is what makes production-grade AI agents explainable. When a client asks why an alert fired, you point at the variable and the threshold sitting in the database instead of saying the model felt like it.
If this kind of agent work is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
The legacy code gotcha
One last thing: watch for race conditions when you poll high-frequency data through WP-Cron. I once watched an agent send three notifications for the same weather event because the Transient was not locked while the server was under load. Handle concurrent runs in your evaluator, and when the state looks wrong, step through it with WP-CLI to see where it drifts.
