Skip to content

Runs

Start agent work, follow live Run states, inspect outputs, and handle human approvals without confusing results with external actions.

Start an agent request

A Run records an execution attempt. A Run Group keeps the main attempt and any delegated work together for one objective.

  1. Prepare the request

    Open the target Space, check context and attachments, then describe the desired result and constraints. Choose Ask agent and select an agent if more than one is available.

  2. Choose available execution options

    Use the model picker to choose a model and the offered reasoning or speed options. Options depend on this Space's eligible routes; a connection alone does not guarantee a runnable model.

  3. Start and confirm

    Optionally enable Decision gate for human review of the finished result. Select Start agent work, then open the created Run or result card. Readiness failures are reported before a Run Group is created.

Review saved Tasks

A Task stores the brief. Saving one does not start execution or spend Cloud credits.

  1. Open Tasks

    Select Tasks in the Space navigation. Open a brief to read its full description, status and timestamps.

  2. Save a brief

    Select New Task, enter a title and complete instructions, then save. Edit Task updates an existing brief before its Runs execute.

  3. Queue or cancel

    Queue Run starts a separate attempt using the Task's saved execution constraints. Cancel Task stops that brief and its pending Runs before execution; use a Run Group's cancellation to stop a whole objective, including delegated work.

  4. Follow dependencies

    The detail panel links to prerequisite and dependent Tasks, plus any associated Runs. Task status and Run status describe different records.

  5. Choose who can work

    Ask your connected agent to launch or schedule the Task for itself, a specific agent, any agent, or other agents. It can claim and execute work in its own host without device setup. Swarm Cloud and enrolled devices are optional execution choices, never automatic fallbacks.

Understand Run states

Read the Run's reason and timeline, not just its color. A Run Group and each individual Run have their own status.

Blocked or queued

Work may be waiting for dependencies, approval, budget, a matching runtime, or runtime capacity. Queued is not proof that model execution has begun.

Leased or running

Leased means a runtime has claimed the attempt. Running means execution has started. Open the timeline for recorded steps and progress.

Succeeded, failed, or canceled

These are terminal attempt states. Succeeded means execution completed, not that a human approved the result or that its claims are correct. A retry can create a separate attempt.

Follow live progress

The conversation, Run details, and timeline refresh from recorded server state while the view is active.

  1. Open the work

    Use the Run card or Runs view. Open the Run Group to find main and delegated attempts, then open an individual attempt's timeline.

  2. Inspect evidence

    Review available events, artifacts, evaluations, usage, and action receipts. Some detail is bounded or unavailable to your role; follow linked records and page controls for more.

  3. Recover a stale view

    Bring the tab back into view and restore connectivity. Refresh if progress appears stale, and check the same Run before starting another. A disconnected browser is not proof that hosted execution stopped.

Preparation, results, and external actions

Approvals apply to the specific operation and resource shown. These three stages are not interchangeable.

Before execution

A Run can require approval to prepare or execute work. Open its pending approval, review the requested scope, and approve or deny as an authorized human. Work waits for required execution approvals; no finished result exists yet.

After execution

The composer's Decision gate creates review of the completed output. The Run can succeed while the result approval remains pending. Approving or denying that result does not rewrite the completed Run's execution status.

External effects

Permission to prepare a draft or approval of its result does not authorize sending it, changing external data, or spending money. External actions have their own permission and approval checks; inspect their receipts when available.

Review a human decision

A Decision gate lets execution finish, then asks a human to approve or deny its result.

  1. Open the approval

    Follow the approval from the Run, review surface, or Inbox. Read what is being approved and open the linked output and checks.

  2. Decide on the evidence

    If you have review authority, add a note when useful and choose Approve or Deny. Disabled actions show that the current state or your access does not allow a decision.

  3. Verify what happened

    Read the updated decision and Run state. Approving an output is not blanket permission to send email, change a repository, spend money, or perform another external action.

Control and troubleshoot Runs

Use only the actions offered on the current Run or Run Group. Not every state supports every control.

Pause, resume, cancel, or retry

Use these controls only when available. Read the resulting state before continuing. Canceling does not roll back completed external effects, and retrying work is different from retrying a failed network request.

No progress

Open the queued or blocked reason. Check approvals, model availability, runtime connectivity, and Entity budget. A waiting runtime is different from a slow model.

Output needs correction

Open the saved artifact, compare its sources, and write a focused follow-up. Keep the original attempt for comparison rather than treating a success status as a quality guarantee.

Swarm | Runs