The next step in agentic AI is not simply a better single agent. It is a system in which hundreds and then thousands of specialized agents investigate, test, critique, and improve work together. This model matters whenever a task can be divided into parallel hypotheses, experiments, reviews, and domain roles – from science and mathematics to engineering operations and enterprise analysis.

This article starts a series on the infrastructure behind that collaboration. We focus on provisioning and managing a persistent 1,000-agent fleet on Oracle Kubernetes Engine (OKE), with OCI File Storage Service (FSS) as the durable POSIX workspace layer. In a public end-to-end run, the platform completed 6,000 of 6,000 requests across a fixed 1,000-agent roster without client retries. The result demonstrates a practical OCI foundation for scalable agent operations and creates a strong baseline for larger agent populations.

  • Why the value of a large agent system depends on collaboration, not merely more model calls.
  • Why 100, 1,000, and larger agent populations need cluster-level execution and persistent, controlled workspaces.
  • Which OCI services can extend this foundation for durable state, messaging, shared knowledge, and orchestration.

Abstract

A single agent can plan and use tools. A large agent swarm can pursue independent hypotheses, compare candidate solutions, verify work, and preserve evidence for later stages. More agents alone do not create better outcomes; the benefit comes from a collaboration model and an infrastructure layer that preserves identity, state, and access boundaries.

Our baseline uses OKE for working-agent Pods, FSS for durable shared POSIX workspaces, a stateless public Model Context Protocol (MCP) Gateway, and asynchronous delivery between the Gateway and runners. In the measured Ashburn run, 1,000 persistent agents each received a short, read-only prompt in six concurrency phases. All 6,000 requests succeeded with zero client retries. The fastest full-batch result was 18.4 successful requests per second at 500 simultaneous requests; at 50 to 100 simultaneous requests, p99 end-to-end latency was about 10 seconds.

From one agent to a collaboration system

Single-agent systems are valuable for focused work, but they limit independent exploration and verification. A multi-agent system can assign roles to generate hypotheses, find evidence, implement candidates, run tests, critique results, and synthesize a recommendation. Recent mathematical AI progress makes this direction compelling: in August 2026, OpenAI reported ten advances in mathematics and theoretical computer science that resolved or substantially advanced long-standing open problems. Difficult problems benefit from parallel exploration and structured verification.

The goal is not to claim that launching more agents guarantees a discovery. The useful unit is a collaboration system: agents exchange evidence and artifacts, workflows decide what happens next, and people retain control of objectives and acceptance criteria. The same design applies to enterprise incident response, software delivery, security review, and research operations.

The 100-, 1,000-, and eventually 100,000-agent thresholds are planning markers, not capacity promises. They are where a single-machine design, ephemeral container disks, and ad hoc message passing stop being dependable foundations.

Why agent swarms are a cluster problem

At a few agents, placing every runtime on one node and using local disk is tempting. It stops working as agents execute model calls, tools, code, and data processing together: CPU, memory, I/O, network sockets, and isolation all compete for the same host. A host event can also interrupt too much of the fleet.

At 100 or 1,000 agents, the platform must place work across nodes and recreate individual workers without losing their identities or workspaces. This is a cluster-level lifecycle problem. OKE supplies the required primitives: working-agent Pods, health checks, resource requests and limits, Services, and placement across worker nodes. Our Agent Manager creates and removes runners through namespace-scoped Kubernetes RBAC, while the public Gateway remains stateless.

Figure 1. The public request path, private OKE execution plane, in-cluster MQ, external OCI File Storage Service, and external private vLLM service.

Figure 1. The public request path, private OKE execution plane, in-cluster MQ, external OCI File Storage Service, and external private vLLM service.

The Gateway authenticates and admits public work, then delivers correlated work to a runner through the in-cluster MQ. Runner execution and model interactions remain private. A new client request can reach any healthy Gateway replica, while OKE manages runner placement independently.

The following OCI Console views provide a deployment snapshot. They show the infrastructure configured for the agent platform, rather than CPU, memory, or storage telemetry from the benchmark run.

Figure 2. OCI Compute Console snapshot of the complete OKE cluster, showing 12 instances across the configured E6 Flex shapes and availability domains.

Figure 2. OCI Compute Console snapshot of the complete OKE cluster, showing 12 instances across the configured E6 Flex shapes and availability domains.

Figure 3. OKE Console snapshot of `pool1`, the 10 active, Ready nodes that host the Agent Pods, running Kubernetes v1.36.1.

Figure 3. OKE Console snapshot of `pool1`, the 10 active, Ready nodes that host the Agent Pods, running Kubernetes v1.36.1.

Persistent and shared workspaces are essential

An agent is not a traditional stateless runtime. It needs a durable workspace for task artifacts, tool outputs, code changes, local instructions, and intermediate results. A Pod root filesystem can disappear on recreation; it is the wrong lifecycle for agent work that must survive rescheduling or maintenance.

In a swarm, every agent needs private state, while related agents need intentional access to common materials and deliverables. FSS is a strong baseline because it provides durable, scalable, concurrent POSIX-compliant file access, and OKE can mount FSS-backed persistent volumes through the CSI volume plugin.

Workspace areaAccessPurpose
/workspace/private/Read/writeIndividual agent workspace and runtime state.
/workspace/files/Read onlyAccount reference files and installed skills.
/workspace/projects/Same-account read/writeShared project artifacts.

The runner does not receive the FSS root, another account root, parent directories, or sibling private workspaces. This scoped mount model is what makes shared storage useful without abandoning isolation.

FSS fits durable, concurrently accessible workspaces. For data-intensive agent workflows where parallel I/O becomes the measured bottleneck, OCI File Storage with Lustre is an option to evaluate. It is a managed parallel filesystem for AI/ML and HPC workloads and can be mounted by OKE. Choose it based on observed I/O behavior, capacity, region availability, client compatibility, and cost – not as a default FSS replacement.

Evidence from the 1,000-agent baseline

The public client test used a fixed roster of 1,000 persistent agents in Ashburn. Each agent received one short, read-only prompt per phase. The run used 10, 50, 100, 200, 500, and 1,000 simultaneous requests; every request had independent bearer authentication, no MCP session ID, and no client retry.

Concurrent requestsCompletedWall timeRequests/sp99 latency
1,0001,000/1,000155.53s6.4111.53s
5001,000/1,00054.27s18.448.92s
2001,000/1,00060.66s16.518.25s
1001,000/1,00064.56s15.510.11s
501,000/1,000106.48s9.49.54s
101,000/1,000516.98s1.910.36s

All 6,000 measured requests completed successfully. The result exposes an operating trade-off: 500 simultaneous requests completed the 1,000-request batch fastest, at 18.4 successful requests per second, but had 48.92-second p99 latency. At 50 and 100 simultaneous requests, p99 stayed close to 10 seconds. At 1,000 simultaneous requests, the batch completed but p99 reached 111.53 seconds.

The result demonstrates that the stateless public MCP path can address the complete 1,000-agent roster under this short, read-only request profile. It establishes a strong OKE baseline for scalable agent operations. The next validation stage will add node and Pod telemetry, FSS latency, queue depth, model-service latency, and restart events to identify the most effective path to still larger populations and more demanding workloads.

OCI features to evaluate as the swarm grows

The following are architectural options for later phases of the series. Each must be validated against workload evidence, governance requirements, service limits, and cost.

  • HA operational state: Use Oracle Database, MySQL HeatWave, or Autonomous AI Database for identities, leases, task status, checkpoints, and audit records.
  • Asynchronous work delivery: Evaluate OCI Queue for managed decoupling between clients, controllers, runners, and audit systems; test its delivery, retention, ordering, and throughput characteristics.
  • Shared context and vector search: Use Autonomous AI Database and Oracle AI Database vector capabilities to retrieve approved documents, prior artifacts, and semantic memory with appropriate metadata and access controls.
  • Dynamic graph orchestration: Evaluate Oracle Property Graph for relationships among agents, tasks, sources, and artifacts, alongside an application-level workflow engine for loops, chains, and branches.
  • Private model serving: Run self-managed vLLM on OCI Compute or OKE behind an internal endpoint when you need operational control of the model and GPU fleet. Alternatively, use OCI Generative AI OpenAI-compatible APIs or dedicated model endpoints through a private endpoint for VCN-based access to supported managed models.

Conclusion: an OCI foundation for large-scale agent operations

This work proposes and validates a practical OCI architecture for operating a persistent 1,000-agent fleet. OKE provides cluster-level placement, lifecycle management, and recovery for working-agent Pods. FSS supplies durable, scoped POSIX workspaces so that agents can retain private state and share project artifacts without exposing the storage root. The stateless MCP Gateway, private network path, queue-based handoff, and private model service separate public request admission from individual agent execution. In the measured run, that public path completed 6,000 of 6,000 requests with no client retries.

More broadly, OCI provides the building blocks for a full multi-agent ecosystem rather than only a place to run containers: Kubernetes for the runtime, shared and parallel filesystems for persistent work, managed databases for operational state, managed messaging for asynchronous coordination, private model access, and data capabilities for retrieval and relationship analysis. The architecture lets these layers scale and evolve independently as the agent population and workload become more demanding.

The next OCI capabilities to validate are FSS versus Lustre for data-intensive collaboration; Oracle Database, MySQL HeatWave, and Autonomous AI Database for highly available state; OCI Queue for managed handoffs; Autonomous AI Database vector capabilities for shared context; Oracle Property Graph for relationship-aware orchestration; and either private vLLM on OCI Compute or OKE, or OCI Generative AI private model endpoints, for model serving. These are not placeholders for scale. Each should be added with production-like workload evidence, telemetry, security controls, and cost analysis.

Sources and scope

This work is part of the JAPAC Center of Excellence (CoE) AI-First initiative: a practical effort to demonstrate the feasibility and architecture direction for operating 1,000 and larger populations of collaborating agents on OCI. The CoE brings infrastructure, AI, and application perspectives together so that the resulting designs can be tested against real operational requirements rather than treated as an isolated model demonstration.

The OCI services and capabilities discussed in this article are: