Agent loops that burn the budget

On September 22, Teradata announced that it was turning its assistant into what it calls an agentic coworker, and added three pieces underneath it: a context engine, an execution layer named Harness, and a set of reusable agent skills. The press release (opens in a new tab) leads with governed business knowledge. The more useful story is the plumbing.

An agent will happily spend your money

Per CIO's write-up (opens in a new tab), Harness builds an execution plan before sending work to a model, batches independent tasks, and drops model or tool calls that do not advance the task. It applies a library of execution patterns before inference and caps how many steps a workflow can run based on whether it is making progress.

Read that list again and notice what it implies. Left alone, agents do the opposite of all of it.

Ashish Chaturvedi at HFS Research said it about as clearly as it can be said. An agent left to reason its way through every step will happily burn tokens on loops that never move the task forward. Even a small reduction in calls per workflow becomes meaningful at scale.

We have watched this happen. An agent that cannot tell whether it is finished will keep checking. One with a vague goal will re-read the same context four times. None of that shows up in a demo, because a demo runs once.

The new version of an old tax

The first post on this blog made the case that automation should remove hours you can name. Unproductive agent loops are the same problem wearing a different outfit. Instead of a person spending Thursday afternoon reconciling a spreadsheet, you have a process spending tokens on reasoning that goes nowhere, and a bill that nobody can attribute to a specific outcome.

The forecasting problem makes it worse. Advait Patel, a site reliability engineer at Broadcom, told CIO that agentic costs are hard to forecast because the same task can take five calls one day and fifty the next. A layer that plans first makes the cost more consistent, which is what makes budgeting possible at all.

Consistency is the thing to want here, more than cheapness. A predictable cost per completed task is something you can make a decision about. A variable one is just risk.

Measure the task, not the token

Teradata published benchmark numbers alongside the launch. On SWE-bench Pro, running the same model, the company reports 73% fewer tokens than a comparison tool, 42% faster completion, and 58% lower total cost. Those are Teradata's own evaluations of its own product, and they are worth treating as a vendor claim rather than a finding.

Robert Kramer at KramerERP made that point in the CIO piece, and his framing is the one we would borrow. Benchmark results should not be treated as equivalent to total cost of ownership. What an enterprise should measure is the cost of completing a business task, including model usage, data compute, tool calls, retries, orchestration, and the human effort required to review the result.

That last item is the one that gets left out of every vendor comparison. If an agent halves its token spend and doubles the time a person spends checking its output, you have not saved anything. You have moved the cost somewhere that does not appear on the AI invoice.

Cutting calls is itself a judgment call

The honest caveat in the reporting is the best part of it. Patel noted that pruning inference calls is a judgment call, and if the layer drops a step that turns out to matter, you save money and get a worse answer.

That is the trade in one sentence. Efficiency controls are not free. They relocate the risk from your budget to your output quality, which means somebody still has to verify results.

Stephanie Walter at HyperFrame Research described how that changes the work. Developer effort shifts away from directing individual steps and toward defining what a correct outcome looks like and reviewing whether the agent achieved it.

We would put that even more simply. If you cannot say what correct looks like, no amount of cost control helps you, because you have no way to notice when the savings came out of the answer.

What this means for a mid-market team

Most of the teams we work with are not buying an enterprise data platform this quarter. The transferable part is smaller and cheaper.

Give the agent a narrow task with a checkable output. Cap how long it is allowed to work on it. Log what it actually did. Then compare the cost of the completed task against the hours it was supposed to remove, including review time.

That comparison is available to anyone, on any stack, this week. It is also the only number that settles the argument.

Tell us where the hours go

No pitch required. Name the team and what the work costs them in a week. That is enough to tell whether we are useful.

Contact