Performance and benchmark evidence
The useful question is not whether Foundgine is universally faster. It is what the measured workloads show about agent work, execution shape and physical performance.
How to read the evidence
Every benchmark should be interpreted with its workload, concurrency, fixture and implementation in view. The site separates directly measured values from modeled context estimates.
| Metric | Type | Interpretation |
|---|---|---|
| Tool calls | Measured | Agent-side coordination observed in the benchmark. |
| Latency / RPS | Measured | Physical request performance for the tested fixture and host. |
| Success / failure | Measured | Correctness signal for the published workload. |
| Context tokens | Estimated | Benchmark heuristic; not provider billing or live model usage. |
Agent-work evidence
The published agent-facing runs compare the same business workflow through conventional and semantic execution paths. Their strongest signal is reduced tool coordination and, in some runs, reduced context carried by the workflow. These are workload-specific measurements, not universal claims about every model or application.
High-assurance mutation evidence
The TransferFunds experiments add tenant isolation, ownership, authorization revalidation, account-state checks, idempotency and atomic transactional behavior. Run 5 exposed a concurrency limitation; Run 5b isolates request shape with the same client to study individual versus batch calls.
Supply Chain E2E
The application-level case connects agent → MCP → Foundgine → PostgreSQL and combines semantic execution, authorization, mutation handling and seeded state verification.
Do not over-generalize
A benchmark is evidence about the experiment that was run. It is not proof that one architecture is always faster, cheaper or safer. Read the run methodology and inspect success/failure counts before drawing conclusions.