Oracle Publishes 1,000-Agent Cloud Benchmark, With a Clear Latency Trade-Off

Oracle has published a reference architecture and benchmark for operating 1,000 persistent AI agents on its cloud. In the company’s Ashburn test, all 6,000 short, read-only requests succeeded without client retries—but the results also showed a stark choice between batch speed and slower responses for the last users in line.

A public front door, private agents behind it

The design uses Oracle Kubernetes Engine, or OKE, to place and manage the containers that run individual agents. OCI File Storage Service provides durable workspaces, while a stateless Model Context Protocol gateway receives public requests and hands work to runners through in-cluster messaging. Model serving stays on a private path.

That separation addresses a practical problem with long-running agents: their work cannot safely live only inside a container that may be recreated or moved. Oracle’s storage layout gives each agent a private read-write area, makes account reference files read-only, and reserves a separate shared area for project artifacts. The runner is not given the storage root or other agents’ private workspaces.

The workspace boundaries

• Private workspace: an individual agent’s state and task artifacts.
• Reference files: account materials and installed skills mounted read-only.
• Project workspace: shared artifacts available to related agents.

The test measured a narrow workload

Oracle used a fixed roster of 1,000 persistent agents across six concurrency settings, from 10 to 1,000 simultaneous requests. Each agent received one short, read-only prompt in each phase, so the benchmark tests the public request path’s ability to reach the whole roster rather than a workload involving lengthy tool use, writes, or active collaboration among agents.

The strongest throughput result came at 500 concurrent requests: 18.4 successful requests a second. Lower settings of 50 and 100 simultaneous requests held p99 end-to-end latency near 10 seconds. Oracle’s benchmark therefore shows a system that can finish the entire request set at every tested level, while exposing an operating choice: more concurrency did not mean faster service for every request.

A baseline, not a capacity promise

The reported result moves the discussion from an abstract agent swarm to a disclosed deployment pattern: clustered runners, durable workspaces, controlled access and queued handoffs. It is not yet a full account of how the design behaves under heavier or more varied work. Oracle says its next validation stage will add measurements for nodes and Pods, file-storage latency, queue depth, model-service latency and restart events.

Those measurements are intended to help Oracle evaluate paths toward larger agent populations and more demanding workloads. For now, the company has supplied a disclosed baseline with a useful warning built into the numbers: scaling an agent fleet is also a decision about which delays users can tolerate.