Workflow Examples

Copy-and-adapt snippets for building workflows. Each example shows the minimal YAML needed for a specific technique.

Basic Patterns

Simple Agent Loop with Auto-Approve

The standard agent pattern: call LLM, execute tools, repeat while there’s work.

- id: agent_loop
  type: loop
  while: (outputs.tool_calls != null && size(outputs.tool_calls) > 0) && iter.iteration < inputs.max_turns
  inline:
    entry: [call_llm]
    outputs:
      tool_calls: "{{nodes.call_llm.tool_calls}}"

    nodes:
      - id: call_llm
        type: call_llm
        args:
          model: "{{inputs.model}}"

      - id: execute_tools
        type: execute_tools
        args:
          tool_calls: "{{nodes.call_llm.tool_calls}}"

    edges:
      - from: call_llm
        cases:
          - to: execute_tools
            condition: nodes.call_llm.tool_calls != null && size(nodes.call_llm.tool_calls) > 0

Key points:

while condition checks for non-empty tool_calls to continue looping
No approval step means tools execute automatically

Manual Approval Mode

Add an approval gate before tool execution.

nodes:
  - id: call_llm
    type: call_llm
    args:
      model: "{{inputs.model}}"

  - id: approval
    type: approval
    args:
      title: Approve tool execution?
      timeout: 1h

  - id: execute_tools
    type: execute_tools
    args:
      tool_calls: "{{nodes.call_llm.tool_calls}}"

edges:
  - from: call_llm
    cases:
      - to: approval
        condition: nodes.call_llm.tool_calls != null && size(nodes.call_llm.tool_calls) > 0

  - from: approval
    cases:
      - to: execute_tools
        condition: nodes.approval.status == 'approved'

Key points:

Approval blocks until user responds or timeout
Check nodes.approval.status == 'approved' before proceeding

Plan Mode (Read-Only Tools)

Restrict agent to read-only tools for planning without modifications.

inputs:
  model:
    type: model
    default: ""
  mode:
    type: enum
    enum: ["auto", "plan", "manual"]
    default: "auto"
  planning_prompt:
    type: string
    default: "You are in planning mode. Plan, but do not modify code."
  system_prompt:
    type: string
    default: ""

nodes:
  - id: call_llm
    type: call_llm
    args:
      model: "{{inputs.model}}"
      # Choose the preloaded tools based on mode
      tools_config:
        preloaded_tools: "{{inputs.mode == 'plan' ? ['tag:coding:plan'] : ['tag:coding:default']}}"
      # Optionally add planning-specific system prompt
      system_prompt: "{{inputs.mode == 'plan' ? inputs.planning_prompt : inputs.system_prompt}}"

Key points:

Use tools_config.preloaded_tools to choose which tools the model starts with
tag:coding:plan includes read-only tools plus planning tools (create_plan, add_task, etc.)
Pair with a planning-specific system prompt

Conditional Logic

Branch Based on Exit Code

Route workflow based on command success/failure.

nodes:
  - id: run_tests
    type: run
    command: make test

  - id: on_success
    type: save_message
    args:
      role: assistant
      content: "Tests passed!"

  - id: on_failure
    type: save_message
    args:
      role: assistant
      content: "Tests failed: {{nodes.run_tests.stderr}}"

edges:
  - from: run_tests
    cases:
      - to: on_success
        condition: nodes.run_tests.exit_code == 0
        label: success
      - to: on_failure
        condition: nodes.run_tests.exit_code != 0
        label: failure

Key points:

run nodes expose exit_code, stdout, stderr
Use conditions to branch on exit_code

Branch Based on Tool Calls Present

Check if LLM made tool calls to decide next step.

edges:
  - from: call_llm
    cases:
      # LLM wants to use tools
      - to: execute_tools
        condition: nodes.call_llm.tool_calls != null && size(nodes.call_llm.tool_calls) > 0
        label: has_tools
    # LLM responded without tools (done)
    default: complete

Key points:

Always check both != null and size() > 0
Every case needs a condition; default: is where the edge goes when none matches

Loop While Condition Met

Retry while tests fail (up to iteration limit). Uses fork with memo: false so each iteration starts fresh from the original request, with targeted error feedback injected after failures.

- id: implement_loop
  type: loop
  while: outputs.exit_code != 0 && iter.iteration < 5
  inline:
    entry: [implement]
    outputs:
      exit_code: "{{nodes.verify.exit_code}}"
      stderr: "{{nodes.verify.stderr}}"

    nodes:
      - id: implement
        type: workflow
        ref: builtin://agent
        thread:
          mode: fork
          memo: false  # Fresh fork each iteration
          inject:
            role: user
            content: |
              {{inputs.task}}
              {{iter.iteration > 0 && has(outputs.stderr) ? 'Previous attempt failed:\n' + outputs.stderr + '\nPlease fix these issues.' : ''}}

      - id: verify
        type: run
        command: make test

    edges:
      - from: implement
        default: verify

Key points:

while condition evaluated after each iteration with outputs.* containing results
thread: mode: fork with memo: false gives each iteration a fresh start from the original request
inject.condition adds error feedback only after the first iteration fails
In loop body, iter.iteration is 0-indexed; in while check, it reflects completed iterations

Multi-Agent

Two Agents Taking Turns on Same Thread

Agents alternate on shared context (e.g., proposer/critic debate).

- id: debate_loop
  type: loop
  while: iter.iteration < 3
  inline:
    entry: [proposer]
    nodes:
      - id: proposer
        type: workflow
        ref: builtin://agent
        thread:
          mode: inherit
        args:
          system_prompt: "You are the PROPOSER. Create or refine the plan."

      - id: critic
        type: workflow
        ref: builtin://agent
        thread:
          mode: inherit
          inject:
            role: user
            content: "Challenge this plan. What could go wrong?"
        args:
          system_prompt: "You are the CRITIC. Find flaws and edge cases."

    edges:
      - from: proposer
        default: critic
  thread:
    mode: inherit

Key points:

Both agents use thread: mode: inherit to share context
Each agent sees what the other wrote
Use inject to add turn-specific instructions

Parallel Agents with Join

Launch multiple agents simultaneously, wait for all to complete.

entry: [impl_1, impl_2]  # start both in parallel

nodes:
  - id: impl_1
    type: workflow
    ref: builtin://agent
    thread:
      mode: fork
      inject:
        role: user
        content: "Implement approach A"

  - id: impl_2
    type: workflow
    ref: builtin://agent
    thread:
      mode: fork
      inject:
        role: user
        content: "Implement approach B"

  - id: implementations_done
    type: join

  - id: review
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: "Review both implementations and pick the winner."

edges:
  # Both feed into join
  - from: impl_1
    default: implementations_done
  - from: impl_2
    default: implementations_done

  # After join
  - from: implementations_done
    default: review

Key points:

See Threads for thread mode documentation (fork, new, inherit)
Use unique key values for each parallel branch
A type: join node waits for all incoming edges

Groups for Different Model Configs

Configure different settings for each agent type.

inputs:
  model:
    type: model
    default: ""
    description: Default model for all agents

  Implementer:
    type: group
    presets:
      tag: agent
    inputs:
      model:
        type: model
        default: ""
      temperature:
        type: number
        default: 1.0
      system_prompt:
        type: string
        default: "You are an implementation agent."

  Reviewer:
    type: group
    presets:
      tag: agent
    inputs:
      model:
        type: model
        default: ""
      temperature:
        type: number
        default: 0.7
      system_prompt:
        type: string
        default: "You are a code reviewer."

nodes:
  - id: implement
    type: workflow
    ref: builtin://agent
    args:
      # Fall back to workflow default if group model is empty
      model: "{{inputs.Implementer.model != '' ? inputs.Implementer.model : inputs.model}}"
      temperature: "{{inputs.Implementer.temperature}}"
      system_prompt: "{{inputs.Implementer.system_prompt}}"

  - id: review
    type: workflow
    ref: builtin://agent
    args:
      model: "{{inputs.Reviewer.model != '' ? inputs.Reviewer.model : inputs.model}}"
      temperature: "{{inputs.Reviewer.temperature}}"
      system_prompt: "{{inputs.Reviewer.system_prompt}}"

edges:
  - from: implement
    default: review

Key points:

A group is an input with type: group; its own inputs: nest inside it
Groups appear as collapsible sections in the UI
Set presets: { tag: agent } on a group to give it a preset picker
Reference group inputs as inputs.GroupName.field

Context Management

Filter Large Tool Results with CallLLM

Reduce context bloat by summarizing large outputs.

nodes:
  - id: call_llm
    type: call_llm
    args:
      model: "{{inputs.model}}"

  - id: execute_tools
    type: execute_tools
    args:
      tool_calls: "{{nodes.call_llm.tool_calls}}"

  # Filter large results before saving
  - id: filter_results
    type: call_llm
    save_message:
      role: assistant
      content: "{{output.response_text}}"
    args:
      model:
        tags: [fast]  # Use a fast model for filtering
      tools_config:
        preloaded_tools: []
      system_prompt: |
        Extract only relevant information from tool results:
        - Keep file paths and line numbers
        - Keep error messages
        - Remove verbose/redundant output
      messages:
        - role: user
          content: |
            Filter these tool results:
            {{toJson(nodes.execute_tools.tool_results)}}

  # Save small results directly
  - id: save_results
    type: save_message
    args:
      role: tool
      tool_results: "{{nodes.execute_tools.tool_results}}"

edges:
  - from: call_llm
    default: execute_tools
  - from: execute_tools
    cases:
      - to: filter_results
        condition: nodes.execute_tools.total_result_chars > 4000
        label: filter_large
    default: save_results

Key points:

Check total_result_chars to decide filtering
An empty preloaded_tools list keeps the filtering call from using tools
Save the filtered text as a message so later turns see the short version

Compact When Tokens Exceed Threshold

Trigger context compaction after tool execution.

- id: compact
  type: compact
  timeout: "10m"

edges:
  - from: execute_tools
    cases:
      - to: compact
        condition: nodes.execute_tools.thread_token_count > 185000
        label: compact_needed

Key points:

thread_token_count available after ExecuteTools or SaveMessage
Compact saves its summary message internally with the new context sequence
No save_message block needed for Compact nodes

Conditional Message Saving

Save messages only under certain conditions.

- id: verify
  type: run
  command: go test ./...
  save_message:
    condition: "output.exit_code != 0"
    role: user
    content: |
      Tests failed. Please fix:
      ```
      {{output.stderr}}
      ```

Key points:

save_message.condition controls whether message is saved
Useful for feedback loops (only inject on failure)
Message content can reference node outputs via output.*

Approvals and Oversight

Approval with a Timeout

Ask a person before a step runs, and decide what happens if nobody answers.

- id: approval
  type: approval
  args:
    title: "Review proposed changes"
    timeout: 30m

edges:
  - from: approval
    cases:
      - to: execute_tools
        condition: nodes.approval.status == 'approved'
      - to: report_timeout
        condition: nodes.approval.status == 'timeout'

Key points:

status is approved, denied or timeout
With no edge for denied, the branch simply ends there, as the built-in agent’s does when you deny a tool call
The approval appears in the chat and in the Inbox. In an unattended run (an automation) nobody can answer, so it resolves at once with status unattended: neither granted nor denied. Gate on status == 'approved' and that case takes the not-approved branch

Audit Check Before Tool Execution

Run an auditor agent before allowing tool execution.

nodes:
  - id: main_agent
    type: call_llm
    args:
      model: "{{inputs.model}}"

  - id: audit_check
    type: call_llm
    args:
      model:
        tags: [moderate]  # Balanced model for audit
      response_tool:
        name: audit_result
        description: Report audit findings
        schema:
          type: object
          required: [choice, value]
          properties:
            choice:
              type: string
              enum: [approved, denied]
              description: "approved: the agent is on track. denied: it needs guidance"
            value:
              type: string
              description: A brief confirmation, or what is wrong and how to fix it
      messages:
        - role: user
          content: |
            Review this action. Is the agent on track?
            Response: {{nodes.main_agent.response_text}}
            Tool calls: {{size(nodes.main_agent.tool_calls)}}

  - id: execute_audit
    type: execute_tools
    args:
      tool_calls: "{{nodes.audit_check.tool_calls}}"

  - id: execute_tools
    type: execute_tools
    args:
      tool_calls: "{{nodes.main_agent.tool_calls}}"

edges:
  - from: main_agent
    cases:
      - to: audit_check
        condition: nodes.main_agent.tool_calls != null && size(nodes.main_agent.tool_calls) > 0

  - from: audit_check
    cases:
      - to: execute_audit
        condition: nodes.audit_check.tool_calls != null

  - from: execute_audit
    cases:
      - to: execute_tools
        condition: has(nodes.execute_audit.response_data) && nodes.execute_audit.response_data != null && nodes.execute_audit.response_data.audit_result != null && nodes.execute_audit.response_data.audit_result.choice == 'approved'

Key points:

Use response_tool to ask for structured output, described by a JSON schema
A choice enum plus a value explanation is a convenient shape for a decision
Access response data via nodes.<execute_tools_node>.response_data.<tool_name>.choice or .value, or directly on the Call LLM node as nodes.audit_check.response_data.choice
Auditor can use cheaper/faster model

Response Tools for Structured Feedback

Ask the LLM for a structured response through a “response tool”: a tool only the model can call, whose input is the answer, shaped by a JSON schema.

- id: validation_report
  type: call_llm
  args:
    model: {tags: [moderate]}
    response_tool:
      name: validation_result
      description: Report validation results
      schema:
        type: object
        required: [choice, value]
        properties:
          choice: {type: string, enum: [passed, failed]}
          value: {type: string, description: What was verified, or the issues found}

# Access structured data
outputs:
  passed: "{{has(nodes.validation_report.response_data.choice) && nodes.validation_report.response_data.choice == 'passed'}}"
  details: "{{has(nodes.validation_report.response_data.value) ? nodes.validation_report.response_data.value : ''}}"

Key points:

response_tool is a synthetic tool only the LLM can call
The Call LLM node parses the call into response_data; an execute_tools node that runs the call also has it, keyed by tool name
The tool is offered, not forced: guard reads with has(), or use builtin://structured-agent to keep the model working until it answers through the tool

Worktrees

Create Worktree for Isolated Work

Give an agent its own working directory.

- id: create_worktree
  type: create_worktree
  args:
    name: "feature-{{workflow.id}}"
    base_branch: "{{has(workflow.branch) ? workflow.branch : 'main'}}"
    force: true

- id: implement
  type: workflow
  ref: builtin://agent
  thread:
    mode: inherit
    inject:
      role: user
      content: |
        Implement the feature in: {{nodes.create_worktree.path}}

Key points:

Include workflow.id in name for uniqueness
force: true overwrites existing worktree with same name
Reference worktree path via nodes.create_worktree.path

Copy Env Files to Worktree

Include configuration files in new worktree.

- id: create_worktree
  type: create_worktree
  args:
    name: "impl-{{workflow.id}}"
    base_branch: main
    copy_files:
      - .env
      - .env.local
      - config/secrets.yaml
    force: true

Key points:

copy_files are exact paths from the project root; nothing is searched for (.env is only the root .env — list frontend/.env separately)
Each path lands in the same place in the new worktree; a directory is copied whole and a missing path is skipped
Files are copied from the project root, not the current worktree

Multiple Parallel Worktrees

Create isolated environments for competing implementations.

entry: [create_wt_1, create_wt_2]  # create worktrees in parallel

nodes:
  - id: create_wt_1
    type: create_worktree
    args:
      name: "compete-1-{{workflow.id}}"
      base_branch: main
      copy_files: [.env]
      force: true

  - id: create_wt_2
    type: create_worktree
    args:
      name: "compete-2-{{workflow.id}}"
      base_branch: main
      copy_files: [.env]
      force: true

  - id: worktrees_ready
    type: join

  - id: impl_1
    type: workflow
    ref: builtin://agent
    thread:
      mode: new
      inject:
        role: user
        content: "Work in: {{nodes.create_wt_1.path}}"

  - id: impl_2
    type: workflow
    ref: builtin://agent
    thread:
      mode: new
      inject:
        role: user
        content: "Work in: {{nodes.create_wt_2.path}}"

edges:
  # Wait for both
  - from: create_wt_1
    default: worktrees_ready
  - from: create_wt_2
    default: worktrees_ready

  # Launch implementations in parallel
  - from: worktrees_ready
    default: impl_1
  - from: worktrees_ready
    default: impl_2

Key points:

Create worktrees in parallel for faster setup
Use thread: mode: new so implementations don’t share context
Each parallel edge needs its own - from: block

Complete Workflow Examples

Full workflow definitions showing how patterns combine into real-world solutions.

Code Review Pipeline

Automatically review PRs with multiple specialized agents.

name: Code Review Pipeline
description: Multi-agent code review with security and style checks

nodes:
  - id: fetch_changes
    type: run
    command: git diff origin/main...HEAD

  - id: security_review
    type: workflow
    ref: builtin://agent
    thread:
      mode: fork
      inject:
        role: user
        content: |
          Review these changes for security issues:
          ~~~
          {{nodes.fetch_changes.stdout}}
          ~~~
    args:
      system_prompt: |
        You are a security-focused code reviewer. Look for:
        - SQL injection, XSS, command injection
        - Hardcoded secrets or credentials
        - Insecure dependencies
        - Authentication/authorization issues

  - id: style_review
    type: workflow
    ref: builtin://agent
    thread:
      mode: fork
      inject:
        role: user
        content: |
          Review these changes for style and best practices:
          ~~~
          {{nodes.fetch_changes.stdout}}
          ~~~
    args:
      system_prompt: |
        You are a code style reviewer. Check for:
        - Consistent naming conventions
        - Code organization and readability
        - Documentation and comments
        - Error handling patterns

  - id: reviews_done
    type: join

  - id: summarize
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: "Summarize the review findings and provide an overall assessment."

edges:
  - from: fetch_changes
    default: security_review
  - from: fetch_changes
    default: style_review
  - from: security_review
    default: reviews_done
  - from: style_review
    default: reviews_done
  - from: reviews_done
    default: summarize

Key techniques:

Parallel agents for different review focuses
Fork threads to isolate each reviewer’s context
Join to wait for all reviews before summarizing

Test-Driven Bug Fix

Implement a fix using a test-first approach with retry loop.

name: TDD Bug Fix
description: Write test, implement fix, verify with retry

inputs:
  bug_description:
    type: string
    description: Description of the bug to fix
  max_attempts:
    type: number
    default: 3

nodes:
  - id: write_test
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: |
          Write a failing test that reproduces this bug:
          {{inputs.bug_description}}
          
          The test should fail now and pass after the fix.
    args:
      system_prompt: "You are a test engineer. Write minimal, focused tests."

  - id: verify_test_fails
    type: run
    command: npm test
    save_message:
      role: user
      condition: "output.exit_code == 0"
      content: "Test passed but should fail. Rewrite the test to actually catch the bug."

  - id: fix_loop
    type: loop
    while: outputs.exit_code != 0 && iter.iteration < inputs.max_attempts
    inline:
      entry: [implement_fix]
      outputs:
        exit_code: "{{nodes.run_tests.exit_code}}"
        error: "{{nodes.run_tests.stderr}}"
        
      nodes:
        - id: implement_fix
          type: workflow
          ref: builtin://agent
          thread:
            mode: inherit
            inject:
              role: user
              content: |
                {{iter.iteration > 0 && has(outputs.error) ? 'Previous fix attempt failed:\n' + outputs.error + '\nTry a different approach.' : 'Implement the fix.'}}
          args:
            system_prompt: "Fix the bug. Make minimal changes."

        - id: run_tests
          type: run
          command: npm test

      edges:
        - from: implement_fix
          default: run_tests

edges:
  - from: write_test
    default: verify_test_fails
  - from: verify_test_fails
    default: fix_loop

Key techniques:

Test-first approach ensures fix is verified
Loop with iteration limit prevents infinite retries
Conditional message injection adds context on failures

Documentation Generator

Generate documentation for a codebase with structure analysis.

name: Documentation Generator
description: Analyze code and generate comprehensive docs

inputs:
  target_dir:
    type: string
    default: "src"
  output_file:
    type: string
    default: "DOCUMENTATION.md"

nodes:
  - id: analyze_structure
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: |
          Analyze the structure of {{inputs.target_dir}}:
          1. List main modules/packages
          2. Identify public APIs
          3. Find existing documentation
          4. Note any complex or undocumented areas
    args:
      system_prompt: "You are a technical analyst. Be thorough but concise."

  - id: generate_docs
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: |
          Based on your analysis, generate documentation for {{inputs.output_file}}.
          Include:
          - Overview and architecture
          - Module descriptions
          - API reference for public functions
          - Usage examples
    args:
      system_prompt: |
        You are a technical writer. Write clear, helpful documentation.
        Use markdown formatting. Include examples.

  - id: review_docs
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: "Review the generated documentation for accuracy and completeness."
    args:
      system_prompt: "Review documentation critically. Check for errors and gaps."

edges:
  - from: analyze_structure
    default: generate_docs
  - from: generate_docs
    default: review_docs

Key techniques:

Sequential pipeline: analyze → generate → review
Thread inheritance maintains context across stages
Specialized prompts for each role

Parallel Implementation Competition

Have multiple agents implement the same feature, then pick the best.

name: Parallel Compete
description: Multiple agents compete on same task
entry: [create_wt_a, create_wt_b]

inputs:
  task:
    type: string
    description: The feature to implement

nodes:
  - id: create_wt_a
    type: create_worktree
    args:
      name: "compete-a-{{workflow.id}}"
      copy_files: [.env]
      force: true

  - id: create_wt_b
    type: create_worktree
    args:
      name: "compete-b-{{workflow.id}}"
      copy_files: [.env]
      force: true

  - id: worktrees_ready
    type: join

  - id: impl_a
    type: workflow
    ref: builtin://agent
    thread:
      mode: new
      inject:
        role: user
        content: |
          Implement in {{nodes.create_wt_a.path}}:
          {{inputs.task}}
          
          Focus on: simplicity and readability
    presets:
      default: implementer

  - id: impl_b
    type: workflow
    ref: builtin://agent
    thread:
      mode: new
      inject:
        role: user
        content: |
          Implement in {{nodes.create_wt_b.path}}:
          {{inputs.task}}
          
          Focus on: performance and efficiency
    presets:
      default: implementer

  - id: implementations_done
    type: join

  - id: compare
    type: workflow
    ref: builtin://agent
    thread:
      mode: inherit
      inject:
        role: user
        content: |
          Compare both implementations:
          - Implementation A ({{nodes.create_wt_a.path}}): simplicity focus
          - Implementation B ({{nodes.create_wt_b.path}}): performance focus
          
          Evaluate: correctness, code quality, performance, maintainability.
          Recommend which to proceed with.
    presets:
      default: code_reviewer

edges:
  - from: create_wt_a
    default: worktrees_ready
  - from: create_wt_b
    default: worktrees_ready
  - from: worktrees_ready
    default: impl_a
  - from: worktrees_ready
    default: impl_b
  - from: impl_a
    default: implementations_done
  - from: impl_b
    default: implementations_done
  - from: implementations_done
    default: compare

Key techniques:

Worktrees provide isolated Git environments
thread: mode: new keeps implementations separate
Join synchronizes parallel work
Final comparison sees both implementations’ context

​Basic Patterns

​Simple Agent Loop with Auto-Approve

​Manual Approval Mode

​Plan Mode (Read-Only Tools)

​Conditional Logic

​Branch Based on Exit Code

​Branch Based on Tool Calls Present

​Loop While Condition Met

​Multi-Agent

​Two Agents Taking Turns on Same Thread

​Parallel Agents with Join

​Groups for Different Model Configs

​Context Management

​Filter Large Tool Results with CallLLM

​Compact When Tokens Exceed Threshold

​Conditional Message Saving

​Approvals and Oversight

​Approval with a Timeout

​Audit Check Before Tool Execution

​Response Tools for Structured Feedback

​Worktrees

​Create Worktree for Isolated Work

​Copy Env Files to Worktree

​Multiple Parallel Worktrees

​Complete Workflow Examples

​Code Review Pipeline

​Test-Driven Bug Fix

​Documentation Generator

​Parallel Implementation Competition

Basic Patterns

Simple Agent Loop with Auto-Approve

Manual Approval Mode

Plan Mode (Read-Only Tools)

Conditional Logic

Branch Based on Exit Code

Branch Based on Tool Calls Present

Loop While Condition Met

Multi-Agent

Two Agents Taking Turns on Same Thread

Parallel Agents with Join

Groups for Different Model Configs

Context Management

Filter Large Tool Results with CallLLM

Compact When Tokens Exceed Threshold

Conditional Message Saving

Approvals and Oversight

Approval with a Timeout

Audit Check Before Tool Execution

Response Tools for Structured Feedback

Worktrees

Create Worktree for Isolated Work

Copy Env Files to Worktree

Multiple Parallel Worktrees

Complete Workflow Examples

Code Review Pipeline

Test-Driven Bug Fix

Documentation Generator

Parallel Implementation Competition