End-to-end evidence · Run 2 · 17 August 2026

Scale the agent workflow: does the reduction survive larger customer tiers?

Run 2 moves from one deterministic customer to four workload tiers: 10, 100, 1,000 and 10,000 customers, combined with concurrency levels up to 64. The goal is to see whether the semantic reduction survives when the fixture and parallelism grow.

Inspect the matrix evidence →All five runs

Why this run existsA capability that looks efficient on a tiny fixture is not enough. Agents eventually operate against larger datasets and multiple simultaneous requests, so the benchmark needs to separate agent-work reduction from backend scaling behaviour.

What was comparedThe same customer-exposure-review business process through conventional and semantic agent flows, across customer tiers and concurrency.

What it meansRun 2 established an important distinction: fewer agent interactions do not automatically mean lower end-to-end latency. The benchmark needs to measure both dimensions independently.

Published finding

What the evidence says

The conventional path used 9 tool calls versus 6 for Foundgine, a one-third reduction, and estimated context load was about 26.5% lower. The published cells reported 100% request success. Latency was mixed: for example, at 10,000 customers/C64 the conventional path averaged 98.3 ms versus 131.2 ms for Foundgine. The run therefore shows that agent-work compression persisted, while execution speed remained workload-dependent.

Key measurements

toolCalls9 → 6

context~26.5% lower estimated context

success100% published success

example10k/C64: 98.3 → 131.2 ms

How to use this run

Read the finding first, then inspect the exact evidence.

This page tells the story of the experiment. The benchmark explorer contains the interactive workload/concurrency matrix and selected-cell comparison.

The benchmark distinguishes measured timings and tool calls from its estimated context-load heuristic.

← Benchmark landing page · How it works · Architecture