Agents burn 100x the tokens. Count the finished jobs.

A chatbot pilot and an agent workflow look similar on a slide and nothing alike on an invoice. The number worth managing is what one completed job costs.

What happened

Crusoe published a piece on tokenomics in the age of agentic inference, built around a metaphor NVIDIA has been pushing: the inference iceberg. The price per GPU hour is the visible tip. Underneath sits everything that decides how many usable tokens that hour actually produces.

One figure in it deserves attention. An agentic task consumes ten to a hundred times the tokens of a single chat turn. An agent plans, holds state across steps, calls a tool, reads what came back, and revises. Each of those is another round of input and output, and the context it carries grows as it goes.

The piece also names something most dashboards miss: goodput, meaning tokens that contributed to a correct finished answer. Tokens spent on retries, abandoned branches and context nobody read are still billed. They just did not produce anything.

Why this matters to your business

You may never rent a GPU. It reaches you anyway, through an API bill that grew faster than your ticket volume did.

The trap is the pilot. A question-and-answer bot answers in one turn, so a pilot on a thousand conversations gives you a cost figure that feels manageable. Then you give the thing authority to look up an order, check a policy, draft a credit and confirm it. Same customer, same outcome, forty steps instead of one. Nothing about your headcount changed, and the line item moved by an order of magnitude.

Which is why cost per token is the wrong number to manage. A cheap model that needs nine attempts costs more than a good one that needs a single pass, and it makes the customer wait three times longer to find out. What survives a budget review is cost per resolved case, measured on the cases you actually resolved.

Why this is a CX-Builder use case

Cost per finished job is only manageable if you can see where the tokens went, and most teams cannot, because the whole workflow sits behind one vendor endpoint that returns an answer and a total.

A visual flow changes that. When the steps are laid out as nodes, you can see which one is expensive and do something about it specifically. Classification and extraction go to a small fast model. The step that needs real judgement goes to the expensive one. Retrieval pulls the three paragraphs of policy that matter instead of pasting the handbook into every prompt. An iteration limit stops the retry loop that would otherwise run all afternoon on a job that was never going to close.

CX-Builder runs on your own hardware, which matters here for a dull reason rather than an ideological one: the run history is yours to query. You can tie spend to outcomes without asking a vendor for a report.

What this looks like if you build it

In practice it is one agentflow where the model is a per-node choice rather than a global setting. A small model triages the incoming request and routes it. A vector store over your documents grounds the answer, so retrieval does the work a longer prompt was doing badly. A structured output step forces the result into a fixed shape, which is what lets a condition downstream decide whether the job is done or needs a person.

Then you cap the loops, and you read the trace. Every run records what it spent and where. Point that at last month's volume and you have a real number for cost per closed ticket, per node, that you can defend and improve.