Claude Code Highlights 01: Agents as Tasks

Digital Strategy Review | 2026

Claude Code Highlight 01 | Agent as Task: Why This Is the Most Critical Step in the Entire System

By Uncle Fruit · Reading Time / 8 Min

Preface

I am placing this highlight first, not because it is the most flashy, but because it determines whether all subsequent multi-agent capabilities can stand on solid ground. Understand this step first, and the later features—teammates, remote execution, and verification—won’t just feel like a collection of scattered features.

01

Agent as Task: Why This Is the Most Critical Step in the Entire System

In many AI Coding Agent systems, a “sub-agent” is essentially just an additional model call.

A common implementation looks something like this:

01 The main agent realizes it needs to delegate. 02 The system copies a portion of the context. 03 A new model request is sent. 04 The returned text is stuffed back into the main conversation.

This approach works fine in the short term and is even easy to demo. But as soon as the system becomes complex, its flaws are quickly exposed:

• Sub-agents lack a stable identity.
• There is no unified lifecycle.
• It is difficult to run in the background.
• It is difficult to resume.
• It is difficult for the UI to display them as first-class objects.
• It is difficult to coexist with other asynchronous execution units.

Claude Code handles this issue quite thoroughly: it designs the Agent directly as a Task.

This is not just an implementation detail; it is the foundation upon which the entire system is built.

02

I. How Claude Code Defines a Task

In src/Task.ts, a task is not a vague concept, but a clearly defined runtime entity.

It has a unified set of properties:

• id
• type
• status
• description
• toolUseId
• startTime / endTime
• outputFile
• outputOffset
• notified

Furthermore, the system explicitly defines multiple task types:

• local_bash
• local_agent
• remote_agent
• in_process_teammate
• local_workflow
• monitor_mcp
• dream

This means that from the very beginning, Claude Code does not treat an Agent as an “appendage to a chat system,” but places it into a unified task runtime.

The key to Claude Code is not just the ability to delegate, but the fact that it turns the delegated object into a manageable task entity.

03

II. Why “Agent as Task” is Superior to “Agent as Sub-conversation”

1. It Has a Natural Lifecycle

Once an Agent is a Task, it naturally possesses lifecycle states such as:

• pending
• running
• completed
• failed
• killed

This is fundamentally different from a “sub-conversation.” Sub-conversations usually only have two states: requesting or returned. But real-world coding agent scenarios are far more complex:

• They may run for a long time.
• They may need to be aborted.
• They may need to be moved to the background.
• They may need to be resumed.
• They may need to wait for user review after a failure.

The Task abstraction is perfectly suited to handle these requirements.

2. It Naturally Integrates into the UI Control Plane

In Claude Code, tasks are integrated directly into AppState. This allows the REPL to naturally display:

• Which background Agents are currently active.
• Which Agent is being viewed in the foreground.
• Which task just finished.
• Which teammate is currently running.

If an Agent were just a sub-conversation request, the UI layer would struggle to provide this “object-level” view.

3. It Naturally Supports the Notification System

LocalAgentTask.tsx sends results back to the main system via system messages like <task-notification> when a task completes, fails, or is terminated.

This means the main Agent does not need to block and wait for the sub-agent. The system can let the Agent run in the background and use notifications to stream results back only when they are ready.

This step is much like background job notifications in an operating system, rather than an interruptive reply in a chat application.

04

III. How Claude Code Integrates Agents into the Task System

1. Local Background Agent: LocalAgentTask

LocalAgentTask is not responsible for “executing model requests,” but for building a complete runtime wrapper around the Agent task:

• State registration
• Progress tracking
• Transcript / output files
• Foreground / retain semantics
• Notifications
• Kill / cleanup

In other words, while the actual Agent reasoning loop is driven by runAgent(...), as long as it wants to be a “background Agent,” it must enter the LocalAgentTask shell.

2. Remote Agent: RemoteAgentTask

Remote Agents do not reinvent a completely different object model. They are still Tasks; only the execution backend is swapped for remote session polling.

This means:

• The user sees the same task object.
• AppState manages the same tasks.
• The REPL handles the same task notifications and task lists.

This is the power of a unified abstraction.

3. In-Process Teammate: InProcessTeammateTask

A teammate is not a special exception, but another type of Task.

This is important because it shows that Claude Code’s design is not:

• One mechanism for normal Agents.
• Another for teammates.
• Yet another for remote agents.

Instead, it is:

Different execution forms sharing a single task abstraction.

05

IV. What This Unlocks for the Future System

Once an Agent is built as a Task, many advanced capabilities follow naturally.

1. Background Execution

Because a Task has an independent state and output location, the Agent does not need to be bound to the synchronous return of the main message stream.

2. Resumption and Persistence

Because a Task has an ID, output files, and metadata, the system can restore these execution objects upon resumption.

3. Multi-Agent Coexistence

Because all Agents enter the tasks collection, the system can host multiple execution units simultaneously, rather than being limited to “only one hidden sub-call per conversation turn.”

4. Unified Kill / Cleanup / Archive Semantics

Whether it is a local agent, remote agent, or teammate, everything can be brought under unified lifecycle management.

06

V. Why This Step Is Harder Than It Looks

Many people, upon seeing this highlight for the first time, might think it’s just “adding a task wrapper.” In reality, it is much more than that.

Turning an Agent into a Task means solving these problems simultaneously:

• How the Task interacts with the message stream.
• How Task results notify the main conversation.
• How to bootstrap a transcript when a Task is viewed by the user.
• How to handle foreground/retain logic in the UI.
• How the Task writes to an outputFile.
• How the Task cleans up during exceptions or kills.

In other words, this is not a data structure problem; it is a system coordination problem.

Claude Code is impressive not just because it defines a Task, but because it ensures the query loop, AgentTool, REPL, AppState, and notification system all work in concert around this Task model.

07

VI. The Difference Compared to Other Agent Systems

If you compare Claude Code with many systems that “support sub-agents,” the biggest difference is not that it has sub-agents, but that it treats the existence of sub-agents with engineering seriousness.

Sub-agents in common systems are more like:

• A function call.
• A side request.
• An auxiliary transcript.

Claude Code’s sub-agents are more like:

• A task object that can be started, observed, moved to the background, resumed, terminated, and notified.

This makes it more like a job/process in an operating system rather than a helper in a chat system.

08

VII. Understanding the Highlight in One Diagram

09

VIII. Conclusion

“Agent as Task” is the reason I ranked this first among the ten highlights of Claude Code—not because it is the most flashy, but because it is the most fundamental.

This step determines that Claude Code’s multi-agent capability is an “engineering object” rather than a “prompting trick.” Without this step, subsequent features like background execution, remote execution, teammates, unified UI, task notifications, and resumption mechanisms would all become patches.

In short:

Claude Code didn’t just add a few sub-agents to a chat system; it added a model-driven execution engine to a task system.