Cut the workload, not the programme.
Nearly half of enterprise leaders scaled back an agent deployment last quarter because costs outran value, and the wording of that finding — scaled back, narrowed, delayed or paused — is four names for one blunt instrument applied to the whole deployment. The unit you should be cutting is the task class, because within any real deployment some workflows clear their manual baseline by 50× while others lose money on every run, and cutting the deployment cuts both.
The granularity of your response is set by the granularity of your data.
A team whose finest-grained cost fact is a monthly invoice has exactly one lever, and it is the deployment. A team with cost per completed task, split by task class, has four — and three of them keep the value. The choice of lever is not a matter of judgement or nerve; it is downstream of attribution, and no amount of executive resolve substitutes for it.
This is worth saying plainly because the pullback usually gets narrated as discipline. It is more often the absence of an option. The question to ask when someone proposes scaling back is not "is this the right call" but "what is the smallest thing we could cut instead, and why can't we?" The answer to the second half is the actual problem.
Task classes inside one deployment differ by orders of magnitude.
An agent deployment is never one economic object. It is a portfolio, and portfolio averages hide everything that matters. A support deployment handling three workflows might look like this:
# cost per COMPLETED task vs the human baseline it replaced ticket_triage $0.11 baseline $6.00 # 55x — expand this refund_processing $0.640 baseline $2.40 # 3.8x — healthy doc_reconciliation $4.10 baseline $1.80 # 0.44x — this is the loss # Blended: $1.62 vs $3.40 baseline. The deployment "works". # Cut doc_reconciliation alone: blended drops to $0.38.
The blended number says the deployment is profitable, which is true and useless. Scaling back by 30% across the board removes a third of the triage volume — the best economics in the portfolio — to reduce a loss that lives entirely in one workflow. Cutting that one workflow removes the loss and none of the gain.
Cost per completed task is the metric that makes this visible; cost per run does not. A workflow that fails 40% of the time pays full price for the failures and then pays again for the retry or the human cleanup, and only the completed-task denominator prices that honestly. See agent unit economics.
Carve the tail out before you condemn the class.
A losing task class is often not losing uniformly. Look at the distribution before you kill it: in most deployments a small fraction of runs — the ones with pathological inputs, missing data, or a loop that never converged — consume a wildly disproportionate share of the spend. Document reconciliation at $4.10 per completed task may be $0.90 at the median and $38 at p99.
- Route the tail out, keep the head. A pre-flight check that sends the 8% of hardest cases straight to a human often converts a losing class into a winning one, without touching the 92% that already worked.
- Cap before you cut. A per-task step and token ceiling turns an unbounded tail into a bounded one. If the class becomes profitable with a cap, the problem was never the workflow.
- Check what the failures cost downstream. A cheap run that produces work for a reviewer has moved cost rather than removed it; human review is the line that does not shrink on its own.
Only after the tail is bounded and the class still loses is it genuinely a losing class. Condemning it before that is condemning your step limit.
Four moves, ranked — and three of them keep the value.
When a class is genuinely unprofitable, the response ladder runs from precise to blunt. Take the highest rung you have data for.
- Retune the class. Cache the stable prefix, drop a smaller model onto the classification hop, stop returning whole documents into the transcript, cap the steps. In most systems these move the bill more than any model swap and cost no capability — see agent cost control.
- Narrow the class. Keep the workflow for the segment where it clears the baseline and route the rest to the old path. Narrowing by input type, tenant, or complexity band is nearly always available and nearly never tried.
- Retire the class. Turn off one workflow, keep the deployment, redeploy the freed budget into the class with the best ratio. This is the move the survey data suggests almost nobody makes.
- Pause the deployment. The only rung reachable without per-class data, and the only one that destroys value indiscriminately. Legitimate as a response to a runaway — that is what a kill switch is for — and rarely the right response to an economics problem.
A pause is not a neutral hold, and the bill for it is invisible.
Pausing reads on a spreadsheet as spend going to zero while the option stays open. Three things are wrong with that.
- The baseline dies. Once the human process resumes, the comparison you would need to justify restarting has to be rebuilt — and the version people remember will be the one that flattered whichever side won the argument.
- The re-ramp is not free. Prompts drift out of sync with a changed product, the models available have moved, evaluation sets go stale, and the people who held the context are on other work. Restarting costs a meaningful fraction of the original build, and nobody budgets for it because the pause was framed as reversible.
- The learning stops. The production signal is the only thing that was going to tell you which class was salvageable. A paused deployment generates no evidence, so the restart decision six months later is made on the same information that produced the pause.
If you must pause, keep one task class alive at low volume — the one with the best economics, not the one under suspicion. It costs little, preserves the baseline and the evaluation loop, and means the restart is a scale-up rather than a rebuild.
Write the resume condition down at the same time as the cut.
Every scale-back should ship with its inverse: the specific, checkable condition under which this comes back. Without it the cut is permanent by default, because nobody re-opens a settled question without a trigger.
- Name a number, not a sentiment. "Revisit when cost per completed task for this class is under the $1.80 manual baseline for four consecutive weeks", not "revisit when the technology matures".
- Name a date to check it, and put it on someone's calendar. Model prices, caching behaviour and context limits all move; the condition may be met without anyone noticing.
- Record what you cut and why, in enough detail that a successor can tell a measured retirement from a budget flinch. These read identically six months later and mean opposite things.
Before agreeing to any across-the-board reduction, spend the two days it takes to split spend by task class and join it to task outcome. In every portfolio we have seen, the distribution is lopsided enough that this single cut — retire the worst class, expand the best — beats a proportional reduction on both cost and value. If the two days are genuinely unavailable, cut the single workflow with the highest known cost per completed task rather than a percentage of everything: a guess at the right granularity outperforms precision at the wrong one.
Related: measuring agent ROI for the denominator this all depends on, where the economics breaks for the patterns that produce a losing class, and when to use an agent for the workflows that should never have been in scope.