Five experiments. One question: what should the agent execution boundary do?
The problem is not giving an agent an API. It is giving the agent useful capabilities without making the API the execution model.
A conventional endpoint can solve one operation very well, but as agent-facing capabilities multiply, the application can accumulate bespoke tools, repeated orchestration, duplicated policy checks and increasingly large interaction traces. These experiments ask whether a semantic execution boundary can reduce that agent-side work while preserving correctness and application control.
Read the runs as a progression: establish the baseline, scale it, measure efficiency, compare execution architectures, then test a high-assurance business capability.
Foundgine is intended to let an agent express a capability while the application remains responsible for semantics, authorization and execution. These runs progressively test that idea — from a small customer workflow to a high-assurance financial mutation.
From isolated contracts to a stateful agent-facing system
The benchmark suite is only meaningful when the execution boundary is verified underneath it. Foundgine's story progresses from deterministic unit behavior, through real PostgreSQL execution and security attack paths, into performance, and finally into the Supply Chain application workflow.
Agent → MCP → Foundgine → PostgreSQL
The application-level culmination: a stateful agent workload that brings semantic execution, authorization, high-assurance mutations, replay protection and PostgreSQL state integrity together.
Inspect the exact workload and concurrency result
The matrix shows the completed benchmark result for each workload/concurrency cell. Select a cell to compare the conventional and Foundgine execution paths using the published measurements.
Run 4 · 4 × 4 execution matrix
Select one workload/concurrency cell to inspect the conventional and Foundgine measurements for that exact experiment.
| Workload \ Concurrency | C8 | C16 | C32 | C64 |
|---|
No matrix cell selected yet.
What this cell means
Click a matrix cell above to inspect the benchmark result for one exact workload/concurrency combination.
The matrix tells you what the system did. The published benchmark measurements show how the two execution paths compare.
1 · Select the experiment
Start with a cell such as 10,000 customers · C64. That fixes the exact workload and concurrency being discussed. The result above is the published benchmark measurement for that experiment.
2 · Read the execution result
Compare tool calls, estimated context, latency, throughput and success rate. These describe the agent and application execution path. A lower context figure means less estimated replay context; it does not by itself prove lower electricity use.
3 · Inspect the exact measurements
Use the selected-cell comparison and detailed table to see RPS, wall time, estimated context load and tool calls for both execution paths. The values come from the published benchmark artifacts.
4 · Keep the claims separate
This is deliberate. We can say 87.4% lower estimated context when the benchmark supports it. We should only claim lower energy or carbon when the corresponding energy/emissions measurements were actually captured.
Measured and estimated values are labelled separately
Measured benchmark signals include tool calls, request timing, RPS and success/failure counts. The replay harness also computes an estimated context load using the benchmark's documented heuristic; that is not provider billing data.
Estimated context tokens are included because they describe the amount of agent-facing context carried through the workflow. They should not be presented as exact model-provider usage unless the benchmark is run against a live model with provider usage reporting.