Planning & Execution¶

When you submit a request to a squad, the planner agent creates a structured plan, you review and approve it, and the squad executes tasks in dependency-respecting waves.

Submitting a Request¶

Open your squad's monitoring dashboard and enter your request in the input field. Describe what you want to achieve in plain language:

"Build a REST API for user management with CRUD endpoints, input validation, and unit tests."

Optionally toggle Auto-approve if you trust the planner to create a good plan without manual review.

The Planning Phase¶

The planner agent receives your request and generates a plan containing:

• Title — A concise summary of the planned work
• Tasks — Individual units of work, each with:
  • Title and description
  • Assigned agent
  • Dependencies on other tasks
  • Priority level (low, medium, high, critical)

graph LR
    T1[Design API schema] --> T2[Implement endpoints]
    T1 --> T3[Write validation]
    T2 --> T4[Write unit tests]
    T3 --> T4
    T4 --> T5[Code review]

Approving a Plan¶

Unless auto-approve is enabled, the plan is presented for your review in the Plan Approval dialog. You can see:

• The full list of tasks with descriptions
• Agent assignments
• The dependency graph
• Estimated complexity

Click Approve to begin execution, or Reject to discard the plan and optionally provide feedback for the planner to try again.

Editing the Plan Before Approving¶

Edit plan turns the task list into an editor. You can retitle a task, rewrite its description, reassign it to another agent of the squad, change its priority, remove it, and add tasks of your own.

A task you add carries an id, shown on the row and derived from the task's title as you type it. Other tasks depend on the task by this id, so the field is editable. An id may hold only ASCII letters, digits and hyphens, may be at most 128 bytes, and may not be index or a Windows device name such as CON: the squad board writes each task as <id>.json beside its own index.json. Leave the field blank to let the server name the task, in which case nothing can depend on it.

Dependencies are picked from the other rows rather than typed, so a task you add can depend on another task you add, in either order. The editor refuses a plan whose ids collide (including two differing only by case) or whose dependencies form a cycle, naming the offending row, and the server applies the same rules when the edited plan arrives.

Wave Execution¶

Once approved, tasks are organized into waves based on their dependencies:

gantt
    title Execution Waves
    dateFormat X
    axisFormat %s

    section Wave 1
    Design API schema     :0, 1
    section Wave 2
    Implement endpoints   :1, 2
    Write validation      :1, 2
    section Wave 3
    Write unit tests      :2, 3
    section Wave 4
    Code review           :3, 4

• Tasks within the same wave execute in parallel
• A wave starts only after all tasks in the previous wave have completed
• If a task fails, dependent tasks in later waves are automatically skipped

Execution Lifecycle¶

Monitoring Progress¶

The squad monitoring dashboard shows real-time execution progress:

• Current wave and total wave count
• Task counts — pending, running, completed, failed, skipped
• Per-agent status — which agent is active, idle, or in error state
• Token usage — real-time consumption per agent and total
• Activity feed — chronological log of events (agent started, task completed, memory updated, etc.)
• Live work summary ticker — a compact bar at the bottom of the chat area shows a continuously updated one-line summary of what the planner or active agents are working on. The ticker is visible during the planning and execution phases and can be dismissed with the × button.

Waiting for Backends¶

When continuum-router temporarily has no healthy backend during an in-process agent's model request, the current squad run pauses and displays a warning with the next attempt number, retry limit, and delay. The same model request is tried again after 1, 2, and 4 seconds, for four attempts including the original request. Results from completed tasks remain visible throughout the wait. Container tasks remain single-dispatch because restarting a container could repeat external side effects.

The Resume control is hidden during this automatic pause because it cannot make a backend available or safely bypass the delay. Cancel remains available. If a backend becomes available, the same run resumes automatically; if all attempts fail, the run stops with the message 'Backends are still unavailable. Automatic retries stopped. Completed results were kept.' Existing task and execution time limits continue to count during the wait.

Cancelling an Execution¶

Click Cancel at any time to stop the current execution. Running tasks are terminated, and pending tasks are marked as cancelled. Completed task results are preserved.

Agent Conversations¶

You can also interact with individual agents directly through Agent Chat:

• Start a conversation with any agent in the squad
• Messages are streamed in real-time
• Conversations are persisted to the workspace
• Per-conversation token usage is tracked

The chat turn runs entirely on the backend, the same way squad task execution and Discussion Room turns do. The agent can use any tools listed in its configuration. File tools are workspace-scoped: paths are resolved relative to the squad workspace root and cannot escape it. This covers read_file, write_file, list_files, and the workspace-scoped versions of list_directory, search_files, and diff_files. read_file returns up to 1,000 lines per call by default; the agent reads further with offset and max_lines, and a partial page ends with a note line that is not part of the file. Tools that operate on arbitrary host paths (search_content, execute_python, etc.) are blocked for all squad agents regardless of the tool configuration.

This is useful for ad-hoc questions, debugging an agent's behavior, or providing additional context outside of the normal planning flow.