Understanding the Task View and Statuses

The Agent task view is used to get a consolidated look at multiple Agent tasks. Its goal is to let you tell at a glance which tasks are working, which need your input, which have finished, and which have failed.

The design of this task view draws on the customer experience of Claude Code's Agent View: let the user see status first, then open details, reply, approve, or take over only when needed.

What the task view shows

Each task row typically includes:

• Task name.
• Working mode.
• Current status.
• What it's currently doing.
• Last update time.
• The Agent role responsible.
• Whether user input is needed.
• Whether there's a pending approval.
• Whether there are deliverables.
• Whether there's a failure reason.
• Model consumption and budget status.

The working mode affects what you see

Different working modes emphasize different things in the task view.

Common statuses

There are nine top-level task states:

"Needs input," "awaiting approval," and "ready to review" are not separate top-level task statuses — they're specific situations while a task is running, and usually correspond to the following real signals:

An approval request is a separate object with its own state machine: pending, approved, rejected, expired — it is not part of the task status itself.

Status priority

The task view should prioritize showing:

1. Tasks with a pending approval request (waiting_approval).
2. Tasks that need you to provide additional information (running state, needs input).
3. Tasks that have produced deliverables awaiting your review (ready to review).
4. failed.
5. degraded.
6. running (other cases).
7. verifying.
8. completed.
9. stopped (normal completion).

This way, users don't need to dig through a mass of logs to find what needs handling.

Viewing task details

Once you open a task, you can see:

• Goal summary.
• Current stage.
• Agent roles.
• Recent actions.
• Key logs.
• Resource access records.
• Model consumption.
• Pending approvals.
• Deliverables.
• Failure reason.

Replying to the Agent

When a task shows "needs input," you can reply with:

• Additional requirements.
• Changed priorities.
• A chosen approach.
• More uploaded or connected documents.
• Adjusted resource scope.
• A request to generate a plan first.
• A request to stop a certain direction.

Replies should be as specific as possible.

Not recommended:

Keep going.
Use your judgment.
Hurry up.

Recommended:

For now, only implement user login and the project list; don't build the notifications module.
On the backend, only change the api/projects-related endpoints.
Don't access the production database.
Give me the test results first when done — don't deploy.

Reviewing deliverables

Deliverables can include:

• Requirements documentation.
• Technical approach.
• Code diff.
• Test results.
• Build results.
• Deployment logs.
• Runtime URL.
• Audit records.
• Follow-up suggestions.

Before accepting, don't just look at the final one-liner — check the key artifacts.

Taking over a task

When a task is complex or needs human judgment, you can take it over.

After taking over, you can:

• View the full context.
• Reply directly with more detailed requirements.
• Adjust resource authorization.
• Split the task.
• Request re-planning.
• Stop the current execution.

Taking over doesn't mean giving up on the task. It just moves you from the overview view into a more detailed task conversation.

Stopping a task

Situations where you might stop a task:

• The goal was written incorrectly.
• The wrong resources were selected.
• The budget is abnormal.
• The Agent is clearly heading in the wrong direction.
• The task is stuck.
• A security risk has appeared.
• Execution is no longer needed.

After stopping a task, you should check:

• Whether there's uncommitted code.
• Whether there are temporary resources.
• Whether there's an unclosed deployment.
• Whether there are still-valid short-lived credentials.
• Whether the audit trail needs to be retained.

Re-running a task

Before re-running, it's recommended to adjust:

• The goal description.
• Resource scope.
• Agent roles.
• Budget.
• Approval rules.
• SK skills.

Don't repeatedly retry under the same failure conditions — it wastes model budget.