Tasks

A task is the persistent thread of work on a single prompt. It holds the visibility, ownership, comments, and shared history — and it wraps one or more runs, the ephemeral container lifecycles where the actual agent work happens.

Every task is private by default: only you can see it until you explicitly share it, hand it off, or flip its visibility to the wider tenant. See Collaboration for sharing and hand-off and Run queueing for what happens when you're at a concurrency cap.

Task Lifecycle#

Pending → Running → Completed
Queued ↗    ↓      → Failed
     Awaiting      → Cancelled (manual)
     Approval  ↘
     Awaiting
     User    ↘
     Awaiting
     User Input

1. Pending — Container is starting up
2. Queued — Waiting for another task on the same project to finish (one at a time per project)
3. Running — Agent is actively working
4. Awaiting Approval — Plan-mode gate: the worker has proposed a plan and is waiting for you to approve or reject before writing any code. Only occurs when plan mode is always or when auto determines a plan is needed. See Plan Mode.
5. Awaiting User — The worker asked one or more clarification questions (via AskUserQuestion) and is waiting for your answers before proceeding. A question card appears in the task view showing up to 4 questions in sequence; each question offers 2–4 option chips (tap to select) and optionally an "Other" free-text input. Single-select questions auto-advance on selection. The run resumes once you submit all answers.
6. Awaiting User Input — The worker exhausted its stop-rejection budget while TODOs remain open (the agent kept attempting to stop but pending items blocked it). Open the TODOs panel to mark items N/A, mark them complete, or edit any unresolved item; the run resumes when you act.
7. Completed — Agent finished successfully
8. Failed — Agent encountered an error (can be retried)
9. Cancelled — Manually stopped by a user

Runs#

A task holds 1 or more runs — each run is a single ephemeral container lifecycle. A new run is created when:

• The task is retried after a failure
• The task is resumed after a cancel
• You send a follow-up message that triggers a new container turn

Each run tracks its own status, cost, and token usage. The Runs tab in the task view lists all runs in order, letting you inspect what happened in each container lifecycle. See Run queueing for how concurrency limits apply across runs.

Starting a Task#

From the Command Center, click Start Task to open the task dialog:

• Prompt — Describe the task you want the worker to complete
• Plan mode — Choose always, never, or auto (default: always). See Plan Mode.
• Advanced options (optional) — Override the default provider and model for this task; toggle Auto-retry on incomplete work (checked by default — the platform automatically resumes a run up to 3 times when it ends with incomplete platform TODOs (a failed validation gate or a missing decision-log declaration surfaces as an incomplete TODO, not as a separate failure reason); uncheck for single-shot semantics). When the retry budget runs out the run is marked Retries exhausted; if the platform detects no forward progress across the retry chain it escalates to Stuck (no forward progress) instead.

Permission required: execution:create

How a Worker Runs#

Each task is handled by a single autonomous worker. The worker:

• Reads project context from the workspace root on every run — checking .redstickai/agents.md, then AGENTS.md, then CLAUDE.md (first match wins; files larger than 8 KB are ignored). See Project context.
• Receives a per-turn progress log injected into every container spawn — a trailing snapshot of .redstickai/{execution_id}/progress.md — so it retains continuity across retries and follow-up turns without replaying full history
• Uses tool calls (file reads/writes, terminal commands, search) to complete the task

Plan mode controls whether the worker proposes a plan and pauses at Awaiting Approval before writing code. See Plan Mode for details.

Real-Time Streaming#

While running, the task streams in real-time:

• Text responses — The agent's reasoning and explanations
• Extended thinking — The agent's internal reasoning process (collapsible)
• Tool calls — File operations, terminal commands, and other actions
• Status updates — Container lifecycle events

Tool Call Display#

Tool calls are grouped by type and show:

• File writes/edits — Inline +N/-M line count stats in the header, with an expandable unified diff view (green for additions, red for removals)
• Terminal commands — Command and output display
• File reads — Collapsible file content
• Search results — Glob and Grep results with context

Turn-Based Chat#

Tasks support multi-turn conversations:

1. Start with an initial prompt
2. After the agent completes a turn, send a follow-up message to continue
3. Each turn is visually separated with dividers
4. Full conversation context is preserved across turns

To send a follow-up message to a completed task, use the new-run composer at the bottom of the Runs tab. Each follow-up creates a new Run inside the same task, preserving full conversation context.

You can attach images to any message — drag and drop an image onto the composer, or click the paperclip icon to open a file picker. Images are included with the message sent to the worker.

Task Controls#

You can also swap the provider or model mid-task from the breadcrumb bar (via the model chip). The change is queued and takes effect starting from the next turn; it does not restart the current run.

Resolving Open TODOs#

When a task enters Awaiting User Input, the TODOs panel highlights every unresolved item. You have three actions per TODO:

• Mark N/A — Dismiss the item with an optional note explaining why it does not apply to this task. The run counts the item as resolved and continues.
• Mark Completed — Confirm that the item has been satisfied (use this when you have done the work yourself or verified it out-of-band).
• Edit — Reword the TODO text before the run retries, useful when the original wording was ambiguous and caused the worker to fail.

Acting on any open TODO unblocks the run; the platform spawns a new container to resume from the rejection point.

Permission required: execution:create

Cost Tracking#

Each task tracks:

• Input tokens — Tokens sent to the model
• Output tokens — Tokens generated by the model
• Cost (USD) — Estimated cost per run and total

Token counts and costs are tracked per run and accumulated at the task level.

Results Tab#

After completion, the Results tab shows:

• Agent Timeline — A visual bar chart of worker activity over the task's duration. The footer row shows totals for duration, tokens, cost, and tool calls.
• Files changed — An aggregated view of every file the agent wrote or edited. Each entry shows the file path, lines added/removed (+N/-M), and an expandable unified diff

Smoke tests#

When the worker declares functional smoke flows using the DeclareSmokeFlows tool, the Activity sidebar shows each declared flow alongside its recorded exit code (pass / fail). If the worker used NoSmokeFlows to explicitly opt out, that declaration and its reason are shown instead.

Autonomous decisions#

When the worker resolves a design fork silently (via LogDecision) rather than asking you, the Activity sidebar surfaces each decision's summary and rationale under Autonomous decisions. Review these after completion to understand choices the agent made on your behalf.

Tool Efficiency#

After each run completes, a letter grade (A–F) appears on the run card. The grade is computed from tool-usage patterns during that run: redundant file reads, repeated identical Bash pairs, scope expansions, and loop warnings. A lower grade signals inefficient tool use that may inflate cost and duration, not a functional failure.

Verification Warnings#

After each completed or failed run, the platform computes a set of advisory warning codes that describe gaps in the agent's verification behaviour. These appear as a small amber badge (⚠ N) on the run card in the Runs panel.

The five codes are:

• no_test_gate_detected — No test gate was found in the project manifests. The agent completed work without any automated test runner configured.
• code_edited_without_test_run — Behaviour files were edited during the run but no test gate was invoked before completion.
• code_edited_without_readback — Files were written but never read back after the last write, so the agent did not verify its own output.
• gate_skipped_unrunnable — A detected test gate was skipped because it could not execute in the current sandbox environment.
• gate_skipped_env_error — A detected gate failed repeatedly and was auto-skipped rather than blocking the run.

Verification warnings are advisory and non-gating — they never cause a run to fail or block completion. They appear in the run card badge in the main Runs panel and in the Warnings tab of the admin telemetry drill-in panel.

Workspace Checkpoints#

The platform captures git checkpoints (the current HEAD SHA) at key points during execution. For tasks with plan mode enabled, a pre_execute checkpoint is captured after you approve the plan, before any code is written. After each successful execution-phase turn, a turn_0 checkpoint is captured. If you need to undo the worker's changes you can revert the workspace to any of these checkpoints via the Revert control (see Task Controls). The revert is a hard git reset to the captured SHA; any uncommitted workspace changes made after that checkpoint are discarded.

Searching Tasks#

Use the global search to find tasks across all projects by prompt text.

Comments#

Add comments to tasks for team communication. Comments are separate from the agent conversation and visible to all team members. See Comments.