Token spend on agent features has a habit of outgrowing the plan that approved it. One assistant answers product questions, then comes an order status lookup, then a review summarizer, and two months in nobody can say what each costs per useful answer. AI agent cost optimization is the unglamorous version of that problem: which agents exist, which one handles which job, what the monthly ceiling is. Most of that gets settled with math, well before anyone touches a prompt.
Destin Gong wrote a detailed walkthrough on Towards Data Science that frames agent planning as four standard operations research models, each solved in Python with Gurobi. It’s aimed at data science teams, but the decisions are the same ones a store owner faces when the budget tightens.
The four models behind AI agent cost optimization
Each pattern maps to an argument you’ve probably already had. The numbers below come from Gong’s synthetic tables, so read them as the shape of the gap rather than benchmarks.
- Set covering finds the fewest agents that still cover every skill area. The example covers nine areas with four agents at $80k, against a $134.6k average for random picks across 500 simulations.
- Assignment matches one primary agent to each project to maximize a suitability score, scoring 77 versus a 63.16 random mean.
- Knapsack picks the best bundle of agents under a fixed budget, $4,000 a month buying 215 million tokens versus a 151.61 million random average.
- Network flow routes requests through shared hubs instead of direct calls, landing at $5,630 a month versus $8,425.98 on average.
The gaps, roughly 22 to 42 percent by the article’s own math, are what you report to whoever signs the invoices, synthetic caveat attached. My read is that most of the saving shows up before the solver runs, the moment someone has to write down variables, constraints and one objective. Put a monthly cost next to every agent and a budget line under the list, and the redundant builds get cut by eye.
Where this runs when the client is on WordPress
Not in PHP, and not in a request. There’s no mixed integer solver in PHP I’d put my name on, and even a small model has no business inside a page load. These are tiny problems in solver terms, a few dozen variables, so the shape I’d ship is a Python script on a schedule with WordPress consuming its output. That fits how agent features usually end up anyway, scheduled jobs that read context and write results.
The scheduling part is ordinary WordPress hygiene. Disable WP-Cron and let the system task scheduler call wp-cron.php, as the plugin handbook describes, or keep the script fully outside WordPress and write the plan into an option or custom table that your dispatch code reads. Agents keep running per request; routing weights and on/off flags just change once a night.
One detail in the source deserves a flag: the knapsack objective as printed sums cost rather than tokens, and it references GRD.MAXIMIZE, a typo. That snippet can’t have produced the published output, since maximizing cost would pick the most expensive bundle that fits. It reads like generated code that was never run. This is the same model in PuLP with the bundled CBC solver, which avoids any license question for client work:
import pulp
# name: (monthly cost, monthly output value)
agents = {
"intent_classifier": (800, 50),
"inventory_checker": (1200, 70),
"review_analyzer": (900, 45),
"analytics_reporter": (1100, 50),
}
prob = pulp.LpProblem("agent_budget", pulp.LpMaximize)
pick = pulp.LpVariable.dicts("pick", agents, cat="Binary")
# maximize output value, not cost
prob += pulp.lpSum(value * pick[name] for name, (_, value) in agents.items())
prob += pulp.lpSum(cost * pick[name] for name, (cost, _) in agents.items()) <= 4000
prob.solve(pulp.PULP_CBC_CMD(msg=0))
for name in agents:
if pick[name].value() == 1:
print(name)Install with pip install pulp. Look at what the objective maximizes, though. Tokens measure consumption, so an agent that pads its answers wins that objective every time. Resolve rate or completed tasks per dollar is the number that means something on a store, and token counts belong on the cost side. Since most agent features are thin wrappers around provider APIs, the usage endpoints give you both columns.
The coefficients matter more than the solver
A solver returns an optimum for whatever table you hand it, and it’s equally confident about guessed numbers and measured ones. A suitability score per agent and project doesn’t exist until you produce it, and neither does per-agent output. That part is WordPress work: request logs per feature, background job records with outcomes (I’m assuming Action Scheduler here, since that’s what most WooCommerce plugins use), provider usage reports. Glue them together and the model’s inputs fall out of one query.
That also tells you how big the job really is. An afternoon for the model, weeks for the logging, and the logging pays off even if you never run a solver, because the first real table of per-agent monthly cost usually ends the argument about what to keep.
If you want that loop on a WooCommerce store, per-feature usage logging plus a monthly optimization pass, it’s the kind of work I do, and I’d start with the logging.
Skip all of it if you run two or three agents on one workflow. Write the table by hand: each agent, its monthly cost, one measurable outcome. If the outcome column stays blank, fix logging first and skip the model entirely. The solver earns its setup cost only once the table holds real numbers, and by then the answer is often obvious from the table itself.
