To find which AI agent in a team is pulling its weight, you test each one alone — but what does that cost?

This is about the price of isolating each agent's contribution to a multi-agent team. The collection has no note that puts a number on it, but several notes together show the outline of the answer. The clearest example of testing agents one at a time is Can sequential intervention pinpoint which agent caused a multi-agent failure?. It finds the agent responsible for a failure by intervening on one agent at a time. Its summary doesn't report the cost. But testing each agent separately implies roughly one extra intervention per agent, so the bill grows with team size, and every intervention re-runs part of a team whose cost is already high.

The cheaper alternative in the collection scores agents during the run instead of re-running the team. Can multi-agent teams automatically remove their weakest members? describes DyLAN, which scores each agent's importance through propagation, aggregation and selection while the team works. It then switches off the uninformative agents. Inferring from the description, this puts the measurement inside the run and doesn't need a separate experiment per agent. Dropping weak agents also cuts the tokens spent on later steps. The note doesn't compare this directly against one-at-a-time testing, so treat the savings as a likely benefit, not a measured one.

The less obvious cost is that removing an agent also removes its tokens. How does test-time scaling work at the agent level? reports that about 80% of multi-agent performance variance comes from token budget, not coordination intelligence. A test that drops an agent and sees a score fall may just be measuring the loss of compute. A fair test has to hold total tokens constant, and that means spending more on every variant. The same note points to LatentMAS and shared-KV-cache approaches as ways to separate performance gains from token cost. That could make repeated variant runs cheaper.

What counts as cost also depends on what you measure. Does agent efficiency really break down into three distinct components? says agent efficiency has separate cost profiles: tokens, latency and steps. Improving one axis doesn't improve the others. Testing agents sequentially adds latency and steps. Running the tests in parallel would trade that for more tokens at once. This is my inference from the framework, not a finding of the note. And per-token pricing may overstate the bill. In Do persistent agents really cost less per token?, a 115-day case study found 82.9% of tokens were cache reads. If test variants replay mostly shared context, the real marginal cost of each extra test could be much lower than the raw token count suggests.

In short, one-at-a-time testing costs about one extra run per agent, and getting a fair comparison makes each run pricier. In-run scoring like DyLAN's and cache reuse are the two routes the collection suggests for cutting that cost. The library has no head-to-head numbers on any of this.