A test tells an agent pass or fail. A measurement tells it how far it has to go. Give an agent a target, a load generator and the system’s telemetry, and it can find and remove its own bottlenecks.
In Agentic Loop Engineering, the agent climbs towards green tests. Here it climbs towards a number: throughput under load, tail latency, memory at peak.
Each turn is longer than a unit test run: write, build, deploy, put it under load, read the telemetry. The agent then forms a hypothesis about the bottleneck and the next turn tests it.
A pass/fail check can only say “not yet”. A number shows which way to go.
In July 2026, agents hunted the throughput ceiling of a three-node Nano BPM cluster on Google Cloud. Every step below is from the commit history. Step through the notebook.
Two of the turns in that notebook weren’t about the engine at all. One “pinned” thread was an artifact of how top reports a parked thread. And every cluster benchmark had run with replication switched off, because a script set the replication factor but never enabled Raft.
Both were caught the same way: a controlled A/B that disagreed with the story. A mis-wired measurement is a flaky test with better formatting. The loop is only as good as its instruments, so the instruments get tested too.
For the SDKs, a performance matrix runs workers for eight SDKs in seven languages across worker counts, process topologies, transports, handler types and cluster sizes: 1,280 scenarios. It also sweeps individual settings, so defaults are measured, not guessed. For what this changed in practice, see the case study.
A conformance harness generates a call for every operation in the API spec, sends it through all seven SDKs, and captures the HTTP request each one would send. Nobody writes the expected output: the SDKs are compared with each other.
Where they disagree, at least one of them is wrong, and whoever owns it gets a precise defect to fix. The signal comes from the system, not from a person predicting it.
Everything above runs against a load generator. The next step is to use the telemetry of the deployed system itself: real traffic, real payloads, real failure modes that no stress test thought to try.
It is the same signal from further out, and nothing about delivery has to change. The agent reads production, forms a hypothesis, tests it in the stress loop, and its change goes back through the usual loops and the merge gate like any other.
That moves part of the vision edge. No one predicted that the ceiling was a single exporter thread. A person set the goal; the loop found the work. The human part of the vision becomes choosing what to optimise, and what must not be traded for it.
Optimise a single number and an agent will find ways to move it that you didn’t intend (Goodhart’s law). The guardrails are what keep “faster” meaning faster.
Put agents in a loop with load and telemetry and they will hunt bottlenecks, disprove their own theories and write down what they learned. Check the instruments as carefully as the code. Then give them an objective and guardrails, and let them find the work.