Agent Capability Needs A Budget Curve, Not A Score
The durable product-builder skill is no longer treating agent capability as a single score detached from runtime budget. It is measuring capability as a curve over compute, with explicit visibility into how more tokens, retries, planning depth, and parallel attempts change the quality and reach of the work.
The strongest August 3 signal came from Digg AI surfacing the UK AI Security Institute’s warning that autonomous cyber task horizons have been doubling on the order of months, alongside AISI’s deeper writeup showing that fixed-budget evals systematically understate what newer agents can actually do. Their argument is operational, not academic: the measured frontier changes when you change the allowed budget. That aligns with earlier agent research on test-time scaling, which found that parallel sampling, reflection, and verifier-backed selection materially improve long-horizon outcomes. The useful synthesis for product builders is simple: a benchmark score without its budget is no longer a stable description of capability.
Many teams still compare models or agent workflows as if one pass rate at one budget tells the whole story. That breaks once the product can spend more time, fan out more attempts, or verify intermediate work. The risk is not just inaccurate benchmarking. It is bad product judgment: under-budgeting hard tasks, over-trusting weak scores, mispricing premium workflows, and missing failure modes that only appear when the loop is given room to operate. Builders who instrument budget curves will make better routing, safety, and unit-economics decisions than teams still optimizing to a single number.
Reframe one agent workflow as a budget-curve experiment. Trigger: a workflow has variable difficulty, open-ended execution, or a meaningful quality jump when the agent can retry, reflect, or branch. Context: define the task class, risk level, human-equivalent task horizon, and what counts as success before running the eval. Tools: run the same task set across multiple compute budgets with the same harness, while logging serial steps, parallel attempts, verifier outcomes, and cost. Verifier: use an external acceptance check such as tests, citation inspection, rubric scoring, or artifact review so the agent does not self-certify. Budget: define at least three budget tiers, a maximum token or runtime ceiling, and the escalation rule that unlocks a higher tier. Artifacts: save the budget ladder, task set, traces, verifier outputs, failure reasons, and cost-per-accepted-run table. Stop condition: the workflow design is only accepted when the team can name the cheapest budget tier that reliably clears the verifier for each task class.
Take one agent task your team calls “too unreliable” and rerun it at three budgets with the same verifier. If performance changes materially, the problem may be your measurement frame more than the model alone.
For short deterministic tasks where success saturates quickly and retries add no value, a single-budget score can still be a sufficient approximation.
AISI’s primary reporting and earlier test-time-scaling research support the same operational conclusion: for modern agents, capability is shaped by compute budget and should be measured that way.
Which workflows genuinely need a higher budget tier, and which only need a better verifier or routing rule?
Watch: pass rate by budget tier · cost per accepted run · retry concentration on harder tasks · verifier failure modesApply it now
Knowledge only counts when it changes the build.
Take one agent task your team calls “too unreliable” and rerun it at three budgets with the same verifier. If performance changes materially, the problem may be your measurement frame more than the model alone.
- Stage
- build
- Produce
- Budget-curve spec for one agent workflow
Full context at AISI. Bring back one decision, test, or workflow change.
Read the original ↗Keep Going