AI coding tools are paying more attention to subagents. This is not just feature chasing. A single agent eventually hits limits when it has to handle real engineering work.

If one agent reads code, checks logs, edits implementation, runs tests, analyzes failures, and summarizes results at the same time, the main context quickly becomes noisy. Search results, command output, test logs, and intermediate reasoning get mixed together. Later decisions become less reliable. Work also becomes hard to parallelize: exploration, implementation, verification, and review all sit on one main thread.

The purpose of subagents is to reduce that pressure. The main session stops doing everything from start to finish and becomes more like a coordinator: define goals, assign work, receive results, and merge them into the final answer. A subagent handles a local piece of work, such as exploration, implementation, verification, or review, and returns a compressed conclusion.

So a subagent is not “another copy of me.” It is a way to split tangled engineering work into clearer roles.

Shared Foundations

A mature subagent system usually needs four foundations:

• Context isolation.
• Role specialization.
• Project and user-level configuration.
• Tool and permission boundaries.

Context isolation comes first. Real repositories produce a lot of intermediate material: dozens of search hits, hundreds of test log lines, noisy command output. If all of that is poured into the main session, the main thread gets confused. A subagent can digest that local process and bring back only the signals that matter.

Role specialization is just as important. Multi-agent does not mean opening several identical models. Exploration roles should search, read, and summarize. Implementation roles should focus on local code changes. Verification roles should run checks, identify risks, and report clearly.

Tool and permission boundaries determine whether the system can be used safely. A subagent should not automatically inherit every capability of the main session. A read-only explorer does not need write access. A verifier may not need to change implementation. Background tasks and isolated worktrees need visible boundaries.

Codex and Claude Code share these concerns, but they take different routes.

Codex: Explicit Delegation

Codex’s subagent design feels restrained.

It gives you a controlled, lightweight delegation mechanism around the current main session. When to delegate, who receives the task, and when results are collected are all explicit decisions. The control flow stays in the current task.

Its traits are clear:

• The main session explicitly delegates subwork.
• The role set stays small.
• The main session knows which agent is doing what.
• Results return to the main line for final judgment.
• Collaboration boundaries are transparent.

This works well for teams that care about manual orchestration, predictability, and execution determinism. You can ask an explorer to inspect a call chain, ask a worker to make a bounded change, then let the main session merge the result and decide whether to test further.

The tradeoff is that orchestration pressure still sits with the main session. The main thread must decide when to split work, how to split it, who should take it, and how to merge the result. For lightweight collaboration this is pleasant; for long-running engineering workflows it can become tiring.

Claude Code: Agents as Workstations

Claude Code takes a more platform-like route.

It treats agents as describable, selectable, configurable, memorable, isolated, and background-capable objects. A subagent is not just a helper in a conversation. It is closer to a workstation in an engineering system.

The system can expose agent lists, use cases, descriptions, and tool boundaries to the model, allowing the model to decide which role should handle a turn. That makes delegation more automatic.

Several capabilities define this direction.

First, a role system. Explorer, planner, general-purpose, and verifier roles can carry usage descriptions, tool restrictions, default models, and runtime conditions. A read-only explorer can be prevented from editing files. A planner can focus on architecture. A verifier can focus on checks.

Second, inheritance and overrides. A subagent is not completely free. It inherits the larger boundary of the main session by default, but can adjust local behavior within allowed rules. The main session defines the big boundary; the agent performs local assembly inside it.

Third, memory. Memory is not just “remember a few things.” It can have scope. User memory is like long-term preference. Project memory is repository background. Local memory is environment-specific state. This lets some agents avoid relearning the project from scratch.

Fourth, background work and worktree isolation. Some verification tasks can keep running in the background, while the main thread continues. When stronger isolation is needed, an agent can work in a separate worktree, keeping the project connected but the operation space separated.

Fifth, plugin ecosystem. If agents are first-class objects, you have to think about distribution, installation, priority, override rules, and safety. Plugin agents can enter the system, but high-risk fields such as permission mode, hooks, and MCP servers should remain guarded.

This makes Claude Code feel more like an agent runtime than a one-session collaboration tool.

The Difference

Codex is closer to a controlled delegation tool:

• Explicit delegation.
• Lightweight role set.
• Clean control flow.
• Subtasks centered on the current session.
• Good for deterministic, human-orchestrated work.

Claude Code is closer to an engineering workstation system:

• Agents are formally modeled.
• Roles are more systematic.
• Memory, background execution, isolation, and plugins are part of the runtime.
• The model can help choose roles.
• Good for long-term projects and platform-like workflows.

The real question is not which one has more features. It is whether you want a subagent to be “a helper I explicitly call” or “a long-lived workstation in the system.”

How to Choose

Choose the Codex style if you value explicit control, lightweight delegation, and safe parallelism inside the current session. It is good for code review, small changes, clearly scoped implementation tasks, and workflows where a human wants to keep the rhythm.

Choose the Claude Code style if you want systematic roles, long-term memory, background execution, worktree isolation, plugin extension, and a more complete agent runtime.

Ask two questions:

1. Are you comfortable with the model choosing who should do the work?
2. Do you need a fuller agent runtime?

If the first question makes you uncomfortable, explicit delegation is likely better. If the second answer is yes, a platform-like workstation system may fit better.

Practical Advice

Do not treat subagents as “more models means stronger.” Better practice is:

• Give every role a clear task boundary.
• Limit the tools each role can use.
• Ask subagents to return conclusions, not raw logs.
• Keep final decisions in the main session.
• Make background tasks and worktree isolation visible.
• Set clear safety boundaries for plugin agents.

The value of subagents is not quantity. It is clean division of labor, cleaner context, and more stable main-thread decisions.

Summary

Codex and Claude Code solve the same problem: one agent cannot comfortably carry all real engineering work. Both recognize the importance of context isolation, role specialization, permissions, and local summarization.

Codex is more restrained, emphasizing explicit delegation and main-session control. Claude Code is more systematic, treating agents as configurable, memorable, isolated, background-capable workstations that can also enter a plugin ecosystem.

The choice is not which brand wins. It is whether your workflow needs a controlled collaboration tool or a full agent runtime.