The invariant claimed here is that runner count and token count are unlinked [2]. Nothing in the framework enforces that. One callback does, and it has to have an answer on every invocation for the property to hold [3]. The model identifier stays in the agent constructor, because the LLM agent will not build without it [4], so the inference path remains wired the entire time the system is running. Any runner state the callback has no deterministic branch for falls through to a model round trip, which costs tokens and a network hop [6]. The upside is that the fallthrough is reviewable in ordinary code: the logic deciding a tick is plain Python, and plain Python is unit-testable [7].
State is where the author says the design first came under load. The project ran on 50 Cloud Run instances [14]. Ten thousand runners spread evenly over fifty instances is two hundred runners each [20], but the Global Load Balancer holds no affinity for the instance that owns a given runner's state [15], so any instance can be asked about any runner. ADK's in-memory session store leaves that state trapped where it was written and invisible to the other forty-nine instances [16], each unable to answer for a runner it does not hold [21]. AlloyDB and Cloud SQL were rejected on query, transaction and row-locking overhead [17]. The write-up breaks off mid-sentence at that point and never names the replacement [18], so the architecture's hardest-working component at 50 instances goes undocumented.
On transfer: the supplied text carries no measured figures. There is no tokens-per-tick number and no tick duration set against the per-decision design this replaced [22]. "Millisecond-level" describes the deterministic tool call, not the tick it serves [7]. What the piece does establish is structural, and the structure is correct. Token spend tracks model invocations, not agent objects, so a callback that always returns removes the invocations [6]. That only holds where the per-tick decision is computable before the run starts. Put a decision at the tick that genuinely needs judgment at runtime and the callback has nothing to return, and you are back to paying per entity. The author's stated position is that the model belongs in the design phase rather than the execution phase, and he reports that interview candidates who propose computing a route with an LLM at runtime usually do not get the job [19].
An LLM agent whose model is never called is an odd object to hand a reviewer. The author's justification is "scar tissue" [5]: the wrapper earns its place through telemetry, A2A messaging and a structured lifecycle, not through inference [5]. In a simulation with ten thousand identical entities and a fixed route, that is a defensible trade, though it turns into a bad one if what you wanted from the framework was the model.
