Automation Examples

Each example on this page is a complete Advanced Settings JSON overlay. Wabee merges the overlay with the agent configuration generated by the creation form.

Before using an example:

Configure every referenced tool or child agent on the agent.
Replace the example tool, agent, and argument names with the exact runtime names from your configuration.
Confirm that each dynamic value targets a string argument.
Test the workflow with representative input before enabling actions that write, send, publish, charge, or delete.

For field-by-field behavior, see the Automation Configuration Reference.

Direct tool call from request text

This is the smallest deterministic tool workflow. It passes the user's current message to one tool without using a model to prepare arguments.

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "react",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [
          {
            "task_id": "search_customers",
            "description": "Find the customer described in the user's request",
            "candidate_tools": ["customer_search"],
            "known_arguments": [
              {
                "tool_name": "customer_search",
                "arguments": [
                  {
                    "name": "query",
                    "value": "$$input$$"
                  },
                  {
                    "name": "limit",
                    "value": 5
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "Matching customer records",
            "output_variable_name": "customer_matches"
          }
        ],
        "variables_required_to_final_answer": ["customer_matches"],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

Why this uses direct execution:

there is exactly one candidate tool;
all required arguments are present;
runs_react_loop defaults to false; and
skip_llm_arguments_preparation has the exact string value "yes".

Remove that metadata field when some argument must be inferred by the model. The known values will still be supplied as context to the normal tool-selection step.

Sequential workflow with task output

This workflow looks up an account, passes its serialized result to a risk tool, and then writes a human-readable summary.

The tool behind account_lookup must return content suitable for the string-valued account_json argument on risk_calculator.

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "react",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [
          {
            "task_id": "look_up_account",
            "description": "Look up the account identified by the user",
            "candidate_tools": ["account_lookup"],
            "known_arguments": [
              {
                "tool_name": "account_lookup",
                "arguments": [
                  {
                    "name": "query",
                    "value": "$$input$$"
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "A serialized account record",
            "output_variable_name": "account_record"
          },
          {
            "task_id": "calculate_risk",
            "description": "Calculate risk for the account record",
            "candidate_tools": ["risk_calculator"],
            "dependencies": [
              {
                "task_id": "look_up_account",
                "required_status": "completed"
              }
            ],
            "known_arguments": [
              {
                "tool_name": "risk_calculator",
                "arguments": [
                  {
                    "name": "account_json",
                    "value": "$$account_record$$"
                  },
                  {
                    "name": "threshold",
                    "value": 0.7
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "A serialized risk result",
            "output_variable_name": "risk_result"
          },
          {
            "task_id": "summarize_risk",
            "description": "Write a concise explanation of the risk result",
            "candidate_tools": ["text_summarizer"],
            "dependencies": [
              {
                "task_id": "calculate_risk",
                "required_status": "completed"
              }
            ],
            "known_arguments": [
              {
                "tool_name": "text_summarizer",
                "arguments": [
                  {
                    "name": "text",
                    "value": "$$risk_result$$"
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "A concise account risk summary",
            "output_variable_name": "risk_summary"
          }
        ],
        "variables_required_to_final_answer": [
          "risk_summary",
          "risk_result"
        ],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

Important details:

calculate_risk explicitly depends on look_up_account.
The dynamic reference uses the producer's output_variable_name, not its task_id.
$$account_record$$ is a top-level string argument value.
Only the final risk outputs are selected for the final answer; the raw account record is not duplicated there.

Workflow using uploaded files and images

Fixed workflows can bind request-specific file and image paths without model inference. This example expects at least one context file and one context image on every request.

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "react",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [
          {
            "task_id": "extract_document",
            "description": "Extract the contents of the first uploaded document",
            "candidate_tools": ["document_parser"],
            "known_arguments": [
              {
                "tool_name": "document_parser",
                "arguments": [
                  {
                    "name": "file_path",
                    "value": "$$context_files[0]$$"
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "Extracted document text",
            "output_variable_name": "document_text"
          },
          {
            "task_id": "inspect_image",
            "description": "Describe information relevant to the report in the first uploaded image",
            "candidate_tools": ["image_analyzer"],
            "known_arguments": [
              {
                "tool_name": "image_analyzer",
                "arguments": [
                  {
                    "name": "image_path",
                    "value": "$$context_images[0]$$"
                  },
                  {
                    "name": "instruction",
                    "value": "Extract facts that should be compared with the uploaded document."
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "Facts extracted from the image",
            "output_variable_name": "image_facts"
          },
          {
            "task_id": "build_comparison",
            "description": "Compare the document text with the facts extracted from the image",
            "candidate_tools": ["comparison_writer"],
            "dependencies": [
              {
                "task_id": "extract_document",
                "required_status": "completed"
              },
              {
                "task_id": "inspect_image",
                "required_status": "completed"
              }
            ],
            "known_arguments": [
              {
                "tool_name": "comparison_writer",
                "arguments": [
                  {
                    "name": "document_text",
                    "value": "$$document_text$$"
                  },
                  {
                    "name": "image_facts",
                    "value": "$$image_facts$$"
                  }
                ]
              }
            ],
            "metadata": {
              "skip_llm_arguments_preparation": "yes"
            },
            "expected_output": "A comparison of the uploaded document and image",
            "output_variable_name": "comparison"
          }
        ],
        "variables_required_to_final_answer": ["comparison"],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

Request-state rules:

indexes are zero-based;
context_files[0] and context_images[0] fail resolution if the respective list is empty;
an image reference resolves to the image's stored file path;
only input, context_files, and context_images are exposed from request state; and
files and images are not optional in this plan. If they should be optional, use separate agents/workflows or a model-assisted task that can decide how to proceed.

Multi-tool React loop with result evaluation

Use a React loop when the model must decide how many searches or page reads are needed. This keeps the plan fixed at one research task while allowing adaptive execution inside that task.

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "react",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [
          {
            "task_id": "research_topic",
            "description": "Research the user's topic, inspect the strongest sources, and produce a concise sourced answer",
            "candidate_tools": [
              "web_search",
              "page_reader"
            ],
            "known_arguments": [
              {
                "tool_name": "web_search",
                "arguments": [
                  {
                    "name": "query",
                    "value": "$$input$$"
                  }
                ]
              }
            ],
            "expected_output": "A concise answer supported by at least two relevant sources",
            "output_variable_name": "research_answer",
            "runs_react_loop": true,
            "requires_analysis": true,
            "result_evaluation": "The answer must address the user's request, cite at least two relevant sources, and clearly distinguish evidence from inference."
          }
        ],
        "constraints": [
          "Prefer primary sources"
        ],
        "variables_required_to_final_answer": ["research_answer"],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

This example is intentionally model-assisted:

the model chooses between the two permitted tools;
it decides how many calls to make;
it decides when the task is complete; and
a separate model-backed result-analysis step checks the evaluation criteria.

The constraints array can guide a model when the serialized plan appears in its context, but the executor does not programmatically enforce the rule. To enforce primary-source use, repeat it in the agent control prompt, task description, tool access policy, or a validating tool.

Do not add direct-execution metadata to a multi-tool React loop.

Hierarchical child-agent workflow

Use a hierarchical workflow when tasks delegate to child agents that are already configured on the parent agent.

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "hierarchical",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [
          {
            "task_id": "research",
            "description": "Research the topic in the user's request and return evidence with source references",
            "candidate_agents": ["research_agent"],
            "expected_output": "Research notes with source references",
            "output_variable_name": "research_notes"
          },
          {
            "task_id": "write_brief",
            "description": "Write a concise brief using the completed research and the original user request",
            "candidate_agents": ["writer_agent"],
            "dependencies": [
              {
                "task_id": "research",
                "required_status": "completed"
              }
            ],
            "expected_output": "A polished brief grounded in the research notes",
            "output_variable_name": "final_brief"
          }
        ],
        "variables_required_to_final_answer": ["final_brief"],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

The child-agent names must match configured child agents exactly. candidate_agents is incompatible with a React workflow plan, so this overlay uses "type": "hierarchical".

Hierarchical delegation is model-assisted. Task descriptions, the original request, and dependency context guide agent selection and execution. Do not assume that tool-style known_arguments will be bound directly to a child agent.

Adding output formatting

Add output_template when human-facing output needs a consistent shape:

{
  "expected_output": "A customer status summary",
  "output_template": "Return Markdown with exactly these headings: Status, Evidence, and Next action.",
  "output_variable_name": "customer_summary"
}

The output formatter uses a model. It is appropriate for presentation, but not for a strict machine-to-machine contract. If a downstream system requires exact JSON, produce and validate that JSON in the tool itself.

Adding a replanning checkpoint

The following task shape deliberately ends the fixed portion of a workflow:

{
  "task_id": "plan_follow_up",
  "description": "Generate follow-up tasks based on the discovered records",
  "dependencies": [
    {
      "task_id": "search_customers",
      "required_status": "completed"
    }
  ],
  "output_variable_name": "replanned_work",
  "pause_and_replan": true
}

Once the dependency completes, the task replanner creates a replacement plan. The checkpoint task is not executed like a normal tool or reasoning task. Use this only when an adaptive plan is intentional.

Production checklist

For each workflow:

Paste only valid JSON into Advanced Settings JSON.
Confirm use_json_planner is true.
Keep both parallel settings false.
Test each tool independently with the exact known arguments.
Test each request reference with real request text, files, and images.
Test every dependency with empty and failed upstream results.
Verify every output-variable reference uses the string form "$$variable_name$$".
Verify direct tasks contain all required tool arguments.
Confirm retried write operations are idempotent.
Confirm the final answer contains only the necessary output variables.
Run the complete plan within the configured execution-time and recursion limits.
For unattended workflows, set allow_user_interaction to false.