A conventional application usually has a reasonably predictable execution path. A request enters the system, application code invokes a sequence of services, and the request eventually produces a response. Engineers can describe most of that sequence before execution begins, even when the system contains asynchronous tasks and distributed components.
An autonomous agent changes this relationship. The application may know the objective, the available tools, and the operational constraints, but it does not necessarily know which tools the agent will invoke, how many experiments it will conduct, or what additional work it will create. These decisions are made dynamically by a language model as the investigation progresses.
Now consider operating 10,000 such processes concurrently, as Third Moment Research reports doing with GPT-6 models and Codex. Each investigation can run for 36 to 48 hours, access computationally intensive research tools, and generate additional subagent tasks.
The architectural problem is not simply scheduling 10,000 containers. It is maintaining control over a large population of dynamically generated workflows whose execution requirements change over time.
Separating the reasoning plane from the execution plane
Third Moment's disclosed implementation places Codex inside a supervisory harness. The inner harness provides the tools and execution environment used for research. The outer harness examines incomplete work and decides whether it should continue, terminate, or escalate.
This suggests a useful architectural separation.
The reasoning plane determines what an agent wants to accomplish. It interprets experimental results, proposes changes, and identifies subsequent investigations. The execution plane carries out the requested operations, while the control plane manages scheduling, permissions, budgets, and lifecycle state.
These terms describe a possible architectural decomposition, not the internal service boundaries of Third Moment's actual deployment.
Figure 1: Reference architecture for a large-scale agent execution platform
flowchart TB
A["Research Objectives"] --> B["Agent Control Plane"]
subgraph CONTROL["Control Plane"]
B --> C["Task Scheduler"]
B --> D["Execution State Store"]
B --> E["Budget and Policy Enforcement"]
end
C --> F["Worker Pool"]
subgraph EXECUTION["Execution Plane"]
F --> G["Agent Runtime 1"]
F --> H["Agent Runtime 2"]
F --> I["Agent Runtime N"]
end
G --> J["Tools / Simulations / Data"]
H --> J
I --> J
J --> K["Artifacts and Results"]
K --> D
K --> L["Observability"]
L --> B
A key benefit of this decomposition is that the reasoning model does not need to administer every aspect of execution. The application can allow an agent to propose a new simulation without allowing it to decide unilaterally how much compute to allocate or which network resources it may access.
The scheduler can accept an agent-generated task only after validating the request against resource and authorization policies. Similarly, an execution service can report that a task is complete without requiring another model invocation merely to check its status.
Why concurrency is not the same as computational capacity
The figure of 10,000 concurrent agents is impressive, but concurrency alone does not describe the infrastructure's computational requirements.
An agent may spend part of its lifetime generating model responses, part of it waiting for external computation, and part of it idle while other tasks complete. Consequently, 10,000 concurrent agents do not necessarily correspond to 10,000 continuously occupied CPU cores or GPU processes.
This distinction becomes important when planning capacity.
Suppose a system maintains 10,000 active investigations, but only 15% are executing computational tasks at a particular moment. That would correspond to approximately 1,500 simultaneously executing tasks. The rest might be awaiting model responses, external services, or task dependencies.
The 15% figure is illustrative, not a measurement from Third Moment.
An efficient orchestrator should therefore allocate resources according to the operations actually being performed rather than reserving maximum compute capacity for the entire duration of every investigation.
This typically requires several capabilities:
- Admission control: Determine whether a proposed task can begin without exceeding available capacity.
- Backpressure: Delay or reject new work when execution services are overloaded.
- Workload prioritization: Allocate capacity according to deadlines, dependencies, and research value.
- Budget enforcement: Limit tokens, compute time, and tool usage across an entire investigation, including its subagents.
- Cancellation propagation: Stop dependent work when the original objective is abandoned or invalidated.
Without these mechanisms, an agent capable of generating additional tasks can create more work than the infrastructure can process.
The problem of dynamically generated task graphs
Traditional workflow engines generally execute tasks whose dependencies are defined in advance. An autonomous research agent may construct parts of its workflow during execution.
Imagine an agent investigating a performance regression in a distributed database. It begins by comparing query plans and identifying three possible causes: a missing index, an inefficient join strategy, and unexpectedly high network transfer between services.
The agent may delegate each hypothesis to a separate subagent. After evaluating the results, it might discover that two causes interact and initiate a fourth investigation.
The resulting workflow is a dynamically expanding dependency graph.
A production orchestrator must determine which experiments can run independently and which depend on previous results. It also needs to prevent circular dependencies, duplicate investigations, and uncontrolled delegation.
This is not merely a matter of assigning tasks to workers. The system must preserve relationships between the tasks and the evidence they produce.
For example, if one subagent modifies the database schema, another subagent's performance measurements may no longer be comparable with earlier results. The control plane must associate each experiment with the correct system version or experimental environment.
Recovering from an interrupted execution
Long-running execution creates another problem: workers are not guaranteed to survive for the entire investigation.
A container might terminate because of a host failure or resource limit. A deployment might replace the worker process. A network interruption might prevent a completed operation from reporting its result.
An orchestrator needs a durable representation of task state so that execution can resume elsewhere.
This is the underlying principle behind durable workflow systems such as Temporal. Temporal records workflow events so that a replacement worker can reconstruct execution state after a crash. External operations are handled as activities whose results can be recorded and reused during replay.
It would be incorrect to conclude that Third Moment uses Temporal; the company has not disclosed its workflow engine. Nevertheless, durable event histories provide a useful reference for the reliability properties long-running agent systems need.
The complication with AI agents is that model responses are not necessarily deterministic. Asking a model to reconstruct a previous decision does not guarantee the same output.
For that reason, replaying an investigation should not mean regenerating every previous model response. Where exact recovery matters, the original decisions and their outputs need to be preserved as execution records.
What changes when agents collaborate?
Third Moment's future ambition is to support hundreds of thousands of collaborating subagents. That introduces concurrency-control problems beyond those required for independent investigations.
Consider two coding agents modifying the same repository. One refactors a shared API while another implements a new feature against the old interface. Both agents may complete their assigned tasks successfully in isolation, but their outputs may conflict when combined.
A coordinated system needs versioned artifacts, mechanisms for detecting conflicting changes, and rules governing when downstream work becomes invalid.
The same applies to quantitative research. If an upstream experiment changes the assumptions of a simulation, downstream results generated under the previous assumptions may need to be discarded or rerun.
The orchestration layer must therefore manage not only which tasks are running, but also whether their results remain valid in the current state of the investigation.
The architectural lesson
Third Moment's case study demonstrates the value of separating research execution from supervision. But a large-scale autonomous platform also needs deterministic controls that exist independently of the model.
A model can decide that another experiment is worthwhile. The scheduler should decide whether resources are available. The policy system should determine whether the proposed operation is authorized. The state store should preserve enough information to recover from interruption.
The more autonomous an agent becomes, the more important these boundaries are.
Sources: OpenAI — Third Moment Research · Temporal — Workflow Execution and Event History
Related: How Third Moment Runs 10,000 Agents | AI Agent Failure Recovery