Your AI agent should not have the final say. Here is why.

Costs are climbing while the gains flatten. The answer is not a smarter model. It is being deliberate about which decisions an agent is allowed to make on its own.

What happened

O'Reilly published a piece on the economics of agentic AI that lands on something a lot of teams have felt but not named. Early AI deployments looked efficient. Then costs climbed sharply while the productivity gains levelled off.

The diagnosis is uncomfortable and worth sitting with. A large share of what companies handed to AI was never a reasoning problem. Billing corrections, account recovery, routine eligibility checks: these are rule-bound tasks that ordinary software already did cheaply and predictably. Handing them to a probabilistic model means paying inference prices for work a decision table used to do for free.

It gets worse under load. Agents that lack the data to finish a job retry instead of stopping. Multi-agent setups drift toward the same wrong answer together, because they are reading each other rather than the evidence. The bill rises. The accuracy does not.

Why this matters to your business

The number that should worry you is not your monthly AI spend. It is your cost per decision, and whether you can predict it next quarter.

When an agent has authority to act, every failure has a price beyond compute: a wrong refund, a mistaken account unlock, a customer told something untrue with total confidence. The article's example of account hijacking is a security story, but the shape is general. A system that sounds certain and lacks a check will eventually be certain and wrong, in front of a customer.

Why this is a CX-Builder use case

The article's proposal is an architecture, not a model upgrade: separate the thinking from the authority. Let the model reason, propose, and draft. Do not let it be the thing that executes. Put a deterministic gate between the two, cap the retries, and check the answer against a source that is not the model.

That separation is the shape of a flow, and it is what CX-Builder is for. An agent reads the ticket, retrieves the customer's actual record, and proposes an action. A structured output step forces that proposal into a fixed shape rather than free text. A human-in-the-loop gate holds anything above a threshold for one-click review. Everything else executes automatically and is logged.

The result is a tunable dial rather than a leap of faith. Route more to the model and pay less per decision with more risk. Route more to a person and pay more with less. You can move that dial deliberately, by policy, instead of discovering where it sat when an invoice arrives.

What this looks like if you build it

In practice it is one agentflow with a few deliberate constraints. Retrieval grounds the agent in the customer's real record rather than its own recollection, so the check happens against evidence instead of another model. A structured output step makes the proposal machine-readable, which is what lets a downstream condition evaluate it at all. An approval node holds high-value or low-confidence cases for a person. Iteration limits stop the retry spiral that quietly runs up the bill.

None of that requires a smarter model. It requires deciding, once and explicitly, which actions a machine may take without asking.