SubAgents Cowork Mode

SubAgents Cowork mode lets you define SubAgent workflows, breaking complex tasks into multiple Agents executed in stages (DAG orchestration). Ideal for large-scale refactoring, design reviews, and multi-step collaboration.

Invoking a Workflow

There are two ways:

Shortcut (recommended for daily use):

$plan Refactor the user authentication module

$ followed by the workflow name, then a space and your request. This is equivalent to:

/workflow plan query="Refactor the user authentication module"

Standard command (supports additional parameters):

/workflow plan query="Refactor the auth module" env=prod

Type $ and press Tab to auto-complete available workflow names.

Get Workflows

Visit the SubAgents Cowork Market to find community-contributed workflows. Download and place them in ~/.auto-coder/.autocoderworkflow/ to use.

Some common workflows available on the market:

For example, after downloading the plan workflow, run a full plan-to-implementation flow:

$plan '''
1. Refactor the auth module to support OAuth2
2. Add unit test coverage
3. Update API documentation
'''

The plan workflow executes sequentially: Context Gathering → Design Solution (output to docs/) → Code Implementation → Verification & Testing → Code Review, with each stage potentially using a different model.

Configure Workflow Models

Before using a workflow, make sure the models it references are properly configured. Run /models /list to see your currently available models, then check against the tables below.

plan — Required Models

impl — Required Models

read — Required Models

Summary: All three workflows use the following models — make sure they are all configured:

• volcengine/deepseek-v3-1-terminus
• volcengine/deepseek-v3-2
• openrouter/openai/gpt-5

If a model is unavailable, edit the model field in the workflow YAML file to use one you already have. See Configuration for how to add new models.

Async Workflow Execution

In addition to synchronous execution, workflows can also be submitted to run asynchronously via /async. Async workflows run in an isolated git worktree without affecting your current work.

Command Syntax

/async /name my-plan /workflow plan "Refactor the user authentication module"

• /name my-plan — Name the task (required)
• /workflow plan — Specify the workflow to execute (required)
• Followed by the query (optional — the workflow YAML may define a default query)

The order of /name and /workflow is interchangeable:

/async /workflow plan /name my-plan "Refactor the user authentication module"

Differences from Regular Async Tasks

Managing Async Workflow Tasks

Async workflow tasks share the same management commands as regular async tasks:

# List all async tasks
/async /list

# View task details
/async /task my-plan

# Merge results into main branch
/auto /merge my-plan

Workflow YAML Structure

Workflows are defined as YAML files with the following core structure:

apiVersion: autocoder/v1
kind: SubagentWorkflow
metadata:
  name: my-workflow
  description: "My custom workflow"
spec:
  globals:
    model: "volcengine/deepseek-v3-2"

  vars:
    project_type: "*"

  agents:
    - id: context
      model: "volcengine/deepseek-v3-2"
      runner: terminal
    - id: coder
      model: "volcengine/deepseek-v3-2"
      runner: terminal

  steps:
    - id: gather_context
      agent: context
      with:
        user_input: |
          ${vars.query}
          Analyze project context and find relevant files.
      outputs:
        attempt_raw: "${attempt_result}"

    - id: write_code
      needs: [gather_context]
      agent: coder
      with:
        user_input: |
          Implement the code based on context.
      outputs:
        attempt_raw: "${attempt_result}"

Key concepts:

• agents — Define participating Agents, each with its own model and runner
• steps — Orchestrated as a DAG (directed acyclic graph), needs declares dependencies
• vars — Global variables; ${vars.query} references the user's input
• outputs — Each step's output can be referenced by subsequent steps

Workflow Search Paths

The system searches for workflow files in this priority order:

1. ./.autocoderworkflow/ — Project-level (highest priority)
2. ./.auto-coder/.autocoderworkflow/ — Project-level
3. ~/.auto-coder/.autocoderworkflow/ — Global

You can create .autocoderworkflow/ in your project directory for project-specific workflows, or place shared workflows in the global directory.

Next Steps

• See Project Structure to understand project organization
• See Best Practices for tips on efficient usage