Cost is a design constraint

Agent work costs money every time it runs, which ordinary software mostly did not. That makes cost a design input, not a procurement conversation. A flow that is fine at ten items and unaffordable at a hundred thousand was designed wrong, not scaled wrong. And the bill is driven by retries and context far more than by which model you picked.

Decision rights

Somebody owns the per-item cost and they own it before the design, not after the pilot. It is an input like latency. A team that does not know what one item costs is choosing an architecture blind and will discover the number at the worst possible moment.

The decision that follows is a comparison: this item is worth roughly this much to us, so the flow has to cost less than that. Sometimes the answer comes back "then not this way". That is the process working, not the project failing. Cheapest at design time, most expensive after launch.

Memory and context

What drives the bill is not what gets discussed. Model choice is visible, comparable, and argued about in meetings. The actual drivers are how much context you send, how many times you send it, and how often the thing tries again. Sending an entire corpus with every item when it could be read once and indexed is the standard version of this mistake, and it does not look like a mistake because it works perfectly at the volume you tested it at.

Execution

Failure has a price now. In deterministic software a failed call costs nothing worth counting. An agent retry costs full price, usually more than the first attempt, because the retry carries a longer context: the error, the previous output, another instruction on top.

So error handling is an economic decision. Cap attempts, fail fast, and make the failure loud instead of looping in hope. The hopeful loop (try again, slightly differently, until it works) is the most expensive pattern in these systems and the easiest one to write, because it is what a person would do and it usually succeeds in testing.

Measure at the volume you will actually run at. Ten items proves it works. It proves nothing about whether you can afford it.

Governance

Every autonomous flow gets a budget with a hard stop that fails loudly. The failure mode of an unbounded agent loop is not a crash you notice. It is an invoice at the end of the month, weeks after the thing that caused it.

Cost gets reviewed when the flow changes, not on a monthly cycle. A prompt edit can move the bill by a multiple while touching nothing that looks like infrastructure. A monthly review finds it four weeks late.

Observability

Track cost per unit of useful output, not cost per call. They diverge exactly where it matters: calls that produced nothing usable are the interesting number, and most billing dashboards cannot separate them from the ones that worked.

The leading signal is cost per item creeping while volume stays flat. That is retries or context growth, and both are invisible in a total that is also moving for ordinary reasons.