PREreview of Total Cost of Agency: Exact Attribution of Memory Injection Cost in Multi-Agent LLM Workflows

The authors split the cost of a multi-agent workflow into five parts and measure the memory-injection part exactly, with a two-pass token count that isn't billed. On 200 enterprise tasks at depths two to six, injection is 13.6% of the variable cost an optimizer can act on (about 12% of the full bill), its share rises to 27.6% at depth six, and injected tokens grow linearly with depth over the measured range (Section VI). Prompt caching is not evaluated, and every figure is for the uncached case.

I read it as a practitioner who runs coding agents every day, not as a benchmark author. In our company the software development is done by AI agents and I measure what they cost me, so maybe my practical side is useful here. My comments are about caching, long runs, the window sweep and the grader.

1. Regarding caching - Section VIII argues that injected memory is a poor caching candidate and says plainly that hit rates were not measured. In my own logs the cached case looked different. I measured 722 agent sessions (150,902 model calls, 34.6 billion tokens) and more than 85% of the modeled spend was work with context - cache reads plus cache writes - not generation (DOI 10.5281/zenodo.22759216, technical report, not peer-reviewed; these are logs of sessions I ran myself, with cost modeled from list prices). On a separate 168-session run, 94.4% of paid tokens were re-reads of context already sent (DOI 10.5281/zenodo.22712985). That's a share of tokens, not of the bill. So with caching on, context didn't go away in my case - it became most of the spend. Your fourth point in Section VIII (a cache write that is never read costs more than no caching) fits this (I count writes as context cost too). Reporting cache reads, cache writes and fresh input as separate lines would make TCA usable for cached deployments.

2. About long runs - my numbers agree with the expectation you state for loops. Section VIII expects injection to be a larger share when agent loops run past the depth of your deepest workflow (as an expectation, not a measurement). In the same 722 sessions about 3% of sessions gave 80% of the spend, and sessions longer than 200 calls (8% of sessions) gave more than 90% of the money. A run with iteration counts in the hundreds would test your expectation directly, since Table I stops at depth six.

3. The Kopt sweep you propose in Section VIII - I wouldn't assume the curve is a straight line. Table IV has two points (32 and 2 entries, 28.7% fewer injected tokens, and accuracy inside seed-level variation). I ran something close in spirit, on a different lever: how often to clear an agent's context between tasks - 36 runs, six session-length policies, six repeats each. The curve was U-shaped, the minimum sat at three tasks per session, three to six were a plateau, and clearing after every task came out about a third more expensive (+33.5%, p = 0.002, 0.011 after Holm correction; DOI 10.5281/zenodo.22759217). Two caveats on my number - the comparison point was picked after the runs, and in the clear-every-task arm the agent wrote more tests, so part of the gap may be extra work. So I'd expect a knee, and the three-seed sweep over seven settings you describe is the right way to find it.

4. About the grader - I agree with treating accuracy as a guard. Section V grades every node except query generation by required-topic recall at 0.6, and you already say it can credit an answer that mentions the right terms without being correct. In my work every task needs a check the agent can run itself, because otherwise "looks done" is the only signal it has (and the model sounds the same when it's right and when it's wrong). Your query nodes already have such a check - the SQL must execute and return a non-empty, error-free result. If the answers for reconciliation and policy nodes can be computed from the seeded SQLite databases, an executable check there would make the 0.600 against 0.570 comparison in Table IV easier to read.

Competing interests

Yes: the text cites the author's own technical reports (DOI 10.5281/zenodo.22759216, 10.5281/zenodo.22759217, 10.5281/zenodo.22712985); no connection to the article's authors.

Use of Artificial Intelligence (AI)

The author declares that they used generative AI to come up with new ideas for their review.