Automation Mode
Automation Mode runs a workflow plan that you define in advance instead of asking
the agent to create a new plan for every request. In agent-core, this is the
workflow.spec.workflow_plan feature.
Use Automation Mode when the same steps, tools, dependencies, and outputs should be used on every run. The request can still supply different text, files, and images.
Important
On the agent creation page, paste an agent configuration overlay into Advanced Settings JSON. Wabee merges that object with the rest of the generated agent configuration. Include only the settings you intend to override.
What is fixed
A workflow plan fixes:
- the tasks that are initially available to the agent;
- the tools or child agents each task may use;
- the dependencies between tasks;
- known tool arguments;
- the names used to pass results between tasks; and
- the task outputs made available to the final-answer step.
It also bypasses model-generated task planning. It does not automatically remove every model decision from execution.
For example:
- a normal single-tool task can still use a model to prepare missing arguments;
- a React-loop task lets the model decide which permitted tools to call and when the task is complete;
- result evaluation and output formatting use a model;
pause_and_replanreplaces the remaining fixed path with a newly generated plan; and- hierarchical workflows use model-assisted agent selection.
For the most deterministic tool call, use one candidate tool, provide all of its required arguments, and enable direct tool execution.
Required configuration shape
The following is a complete Advanced Settings JSON overlay for a one-task fixed
workflow. Replace customer_lookup and its arguments with the exact name and
schema of a tool already configured on the agent.
{
"use_json_planner": true,
"enable_parallel_execution": false,
"workflow": {
"type": "react",
"spec": {
"implicit_tool_selection": false,
"workflow_plan": {
"tasks": [
{
"task_id": "look_up_customer",
"description": "Look up the customer requested by the user",
"candidate_tools": ["customer_lookup"],
"known_arguments": [
{
"tool_name": "customer_lookup",
"arguments": [
{
"name": "query",
"value": "$$input$$"
}
]
}
],
"metadata": {
"skip_llm_arguments_preparation": "yes"
},
"expected_output": "The matching customer record",
"output_variable_name": "customer_record"
}
],
"variables_required_to_final_answer": ["customer_record"],
"parallelism": false,
"version": "1.0"
}
}
}
}
Three settings are essential:
use_json_plannermust betrue. Without it, execution does not remain in the workflow-plan executor after planning and tool calls.- The plan must be nested at
workflow.spec.workflow_plan. - Each useful task needs a unique
task_idand anoutput_variable_name.
For a child-agent workflow, use "type": "hierarchical" and
candidate_agents instead of, or alongside, candidate_tools.
Task execution modes
| Task shape | Runtime behavior | Model involvement |
|---|---|---|
One candidate tool, runs_react_loop: false |
Calls that tool after preparing its arguments | Yes, unless direct execution is enabled |
One candidate tool with complete known_arguments and direct-execution metadata |
Calls the tool with the supplied and resolved arguments | No argument-preparation model call |
Multiple candidate tools with runs_react_loop: true |
Reasons and calls only the listed tools until the task is complete | Yes |
| No candidate tools in a React workflow | Completes the task through reasoning | Yes |
One or more candidate_agents in a hierarchical workflow |
Delegates through the hierarchical agent-selection path | Yes |
Passing request data and task results
Known arguments can contain dynamic references in top-level string values:
| Reference | Value at runtime |
|---|---|
$$input$$ |
The current request text |
$$context_files[0]$$ |
The first uploaded context file path |
$$context_images[0]$$ |
The first uploaded image path |
$$customer_record$$ |
The output saved by a previous task whose output_variable_name is customer_record |
When one task consumes another task's output, add a matching dependency. This prevents the consumer from running before the referenced value exists.
{
"task_id": "summarize_customer",
"description": "Summarize the customer record",
"candidate_tools": ["text_summarizer"],
"dependencies": [
{
"task_id": "look_up_customer",
"required_status": "completed"
}
],
"known_arguments": [
{
"tool_name": "text_summarizer",
"arguments": [
{
"name": "text",
"value": "$$customer_record$$"
}
]
}
],
"metadata": {
"skip_llm_arguments_preparation": "yes"
},
"output_variable_name": "customer_summary"
}
Dynamic references in JSON must be strings. Do not use an object such as
{"name": "$$customer_record$$"}; agent-core treats that as an ordinary
object and does not resolve it.
Building a reliable workflow
- Configure and test every tool or child agent before adding the workflow.
- Start with
use_json_planner: true, a React workflow, andparallelism: false. - Give every task a unique ID and output variable.
- Use exact configured tool names and exact argument names from each tool's schema.
- Add dependencies wherever a task consumes an earlier task's output.
- Put the outputs needed for the response in
variables_required_to_final_answer. - Add direct execution only after all required tool arguments are known.
- Add React loops, analysis, replanning, hierarchical delegation, or parallelism only when the workflow genuinely needs those model-assisted behaviors.
- Test the workflow with missing input, tool failures, empty tool results, and multiple uploaded files or images before using it in production.
Next steps
- Use the Automation Configuration Reference for every field, runtime behavior, limitation, and troubleshooting case.
- Copy a complete configuration from Automation Examples.
- Review Tools before naming tools or known arguments in a plan.