From One Thread to a System: Delegation and Interfaces

In openai/codex, scaling beyond one conversation does not require abandoning the boundaries of the single-agent loop. A child agent is created as an owned thread with bounded context, inherited environment and policy relationships, and a parent-controlled lifecycle. An app-server, in-process host, CLI, or SDK is a different client boundary over related semantics. This chapter follows both relationships so you can judge what changes at scale—and what the runtime is designed to keep invariant.

The motivating case is a repository task that has more than one useful line of work. One agent may inspect a failing test while another reviews a proposed change. A desktop application may drive the same runtime through typed requests rather than a terminal. A remote executor may run the process on a different operating system. These are not automatically separate kinds of autonomy. They are ways of placing more threads or more transport layers around the same control plane.

A child agent is an owned thread

Codex's collaboration path begins with an explicit spawn request. The runtime parses the task message, optional role, model and reasoning settings, and the requested fork scope. It derives a child configuration from the parent turn, carries parent and root turn relationships, and asks the shared agent-control layer to create the child thread and submit its initial communication.

The child can receive different amounts of parent history. A full-history fork preserves the larger context relationship. A bounded fork can take only a specified number of recent turns, and a request can avoid forking context altogether. The choice affects what the child can infer and how much context it must carry. It does not turn the child into an independent authority. The child remains registered under the parent-controlled agent tree and is associated with the relevant environment and policy relationship.

Roles add specialization without becoming a privilege escape. A role can change a child's model, instructions, reasoning settings, features, or skills, and the source describes roles as able to customize or reduce the parent-derived configuration but not replace the parent's authority. This is a useful design constraint. Delegation is valuable when a child can focus on a narrower job; it becomes dangerous when “specialized” is allowed to mean “unrestricted.”

The control plane also owns identity. The registry tracks the child agent's path, thread identity, role, nickname, and lifecycle metadata. A canonical task path makes messages addressable and gives the parent a stable way to refer to the work. It also prevents an arbitrary thread that happens to be loaded in the process from presenting itself as a child of the current task.

stateDiagram-v2 [*] --> Reserved Reserved --> Started: owner creates child Reserved --> Closed: capacity unavailable Started --> Working: start turn Working --> Waiting: wait for activity Waiting --> Working: mailbox or steer Working --> Completed: terminal result Working --> Failed: error or cancellation Completed --> Closed: parent-owned cleanup Failed --> Closed: parent-owned cleanup Closed --> [*]

The lifecycle begins with reservation, not with an untracked process. Capacity can prevent a child from starting. Once started, the child can work, wait for mailbox activity, or be steered. It can complete or fail, but closure remains an owner-controlled transition. The state diagram is a model of the relationship, not a guarantee that every enabled collaboration mode exposes every state in the same way.