Tasks

Tasks are the live work history for an agent. Use them to see what the agent has run, which tasks are still active, and where a task succeeded, failed, or needs attention.

What tasks show

• Status: Running, Needs info (the agent asked a question), Success, Failed, or Idle.
• Timeline: The messages, tool calls, and outputs that led to the result.
• Detail: The task context you need to debug or review a run.
• Evals: Performance and classification of a task against set criteria.

From the Tasks view, you can start new chats, provide follow-ups on open tasks, and continuously evaluate agent performance.

A task can temporarily remain Running after its agent has finished if the platform could not save the final status. During recovery, a later recorded result from that same run can correct an earlier status estimated by the platform. This status correction preserves the agent's existing response and does not rerun your instruction.

Steer a running task

• Add follow-up: Send another message to a task, including while it is still running.
• Stop: Stop the running agent. The button appears only while there is something to stop.
• Answer: When a task is in Needs info, an Agent needs more info banner shows the agent's question. Select Answer to reply and the task resumes.

If you select Stop while the agent is starting or finishing, the console briefly retries that same Stop request. It does not switch to stopping a newer run. Stop requested on a message records your request; it does not confirm that the agent stopped. If the console cannot confirm Stop, it asks you to try Stop again before sending another message.

In chat, if you request Stop but the agent later reports success for the same turn, an input confirmed as part of that turn's initial instructions shows Stop requested. The agent later reported success. The reply stays visible, and that input no longer offers Edit, Resend or Dismiss. This keeps the Stop request in the history without claiming the instruction was left unfinished. It does not resend the message or change its cancellation record. A partial reply or a result from another turn is not enough; undelivered messages keep their existing cancellation and retry controls.

Agents using the current Daytona runtime can schedule a later continuation in the same task. Once registered, that wakeup survives workspace sleep and runner restarts. A replacement wakeup cancels the previous pending one, and Stop cancels pending wakeups. Each scheduled occurrence is accepted once, including when delivery is retried. Timers expire after seven days; work that has already started follows the usual Stop controls.

Failed task diagnoses

When an existing Daytona workspace needs to restart, Brainbase retries temporary provider and connection errors before failing the task. These retries reuse the same workspace and preserve its saved files. If the retry budget is exhausted, the task records the startup failure.

When a task fails, its detail keeps the diagnostic text the runner captured: the runner-reported error when there is one, otherwise the runner's recorded failure reason together with whether the agent itself declared the failure or the runtime did.

Some failures carry no explanation from the agent — for example, an agent that declares it failed without summarizing why. For those, the diagnosis states what was actually observed (that the failure was declared without a summary, or that no terminal event was captured) rather than leaving the failure blank. This describes what the runner saw; it cannot name a cause the agent did not provide.

An agent-declared failure is a task outcome, not an incident: it is recorded on the task and does not raise an operational alert. Failures attributed to the runtime remain alertable. The recorded failure reason and origin are surfaced for all tasks as soon as the platform picks up the change, including tasks on sandboxes that were already running. Only the wording used for failures that carry no explanation ships with the sandbox image, so sandboxes already running keep the earlier, sparser wording for those failures until they are recycled.

Cloudflare follow-ups after sandbox sleep

Cloudflare agents support follow-ups in the same task, including after the sandbox sleeps. The conversation and saved workspace files remain available when the task resumes.

Chat attachments

Attach files to a new chat or a follow-up message. Hosted agents accept files up to 1 GiB each. Videos larger than 25 MiB are added as workspace files for the agent to work with.

Upload progress appears beside each attachment. Hosted uploads can be cancelled and retried within 24 hours while you remain signed in. After a reload, select the original files again; for a new chat, first choose Resume unfinished upload. Brainbase checks each entire file before resuming. Send the message once its attachments are ready. Signing out clears the upload recovery information saved in this browser. After signing back in, select the files again to start a new upload.

Downloading a hosted attachment from a sent chat message returns the original upload for as long as the task exists. To download a version the agent has edited, open the task's Filesystem tab instead.

Task files

Use the task's Filesystem tab to browse the workspace and download current contents, including the agent's edits. For hosted agents, files outside Shared/ support uploads and downloads up to 1 GiB per file, with the upload recovery described above.

Files under Shared/... use the shared-folder limits: uploads up to 25 MiB and downloads up to 50 MiB per file. Shared uploads do not resume after a reload.

Execution setting credentials

When strict admission is enabled, changing a task's model or replacing its metadata through PATCH /v2/tasks/{task_id} requires a person's session or user-wide PAT with access to manage the task. For valid updates, sandbox PATs, other resource-scoped PATs and task keys receive 403 with detail.code: agent_credential_refused before any part of the update is saved. This also covers clear_model and metadata patches that set or remove keys starting with brainbase_, _ or orchestration_: these include evaluation settings and platform-owned state. Reserved keys remain rejected by existing validation, including for person credentials.

Task credentials can still rename a task and edit ordinary labels using metadata_patch, subject to their existing task permissions. For example, {"metadata_patch":{"set":{"customer":"acme"},"unset":["queue"]}} changes those labels without replacing execution settings. Whole-map metadata replacement requires the person credential because it can remove execution settings without naming them. Do not put a person's credential in a sandbox; make configuration changes from the console or a trusted controller.

Strict admission requires both INTEGRATION_CONTROL_ENABLED=true and cutover:strict_admission=true; it is off by default. Existing behavior applies when either switch is off. If the master switch is on but the strict-admission setting cannot be read, protected resource-credential updates return 503 with detail.code: origin_unavailable and Retry-After: 5; retry after five seconds. These checks do not grant additional task access or change normal managed messages and delegation.

When to use Tasks

Start with Tasks when you want to understand what happened in a real run. It is the most direct view for debugging behavior, reviewing quality, or following up on work the agent already performed.