Automation Configuration Reference

This reference documents the agent-core fixed-workflow contract exposed through Advanced Settings JSON on the agent creation page.

The value entered there is an agent configuration overlay. Wabee merges it with the generated agent configuration, so it does not need to repeat the agent's name, models, prompts, tools, or other settings unless you intend to override them.

Complete configuration hierarchy

{
  "use_json_planner": true,
  "enable_parallel_execution": false,
  "workflow": {
    "type": "react",
    "spec": {
      "implicit_tool_selection": false,
      "workflow_plan": {
        "tasks": [],
        "constraints": null,
        "variables_required_to_final_answer": [],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

Agent-level fields

Field	Type	Required for Automation Mode	Default	Runtime behavior
`use_json_planner`	Boolean	Yes	`false`	Must be `true` so execution enters and returns to the structured plan executor. A configured `workflow_plan` alone is not sufficient.
`enable_parallel_execution`	Boolean	No	`false`	Agent-level gate for the parallel executor. Keep this `false` for stable fixed workflows; see Parallel execution.
`workflow`	Object	Yes	Varies	Selects the graph and contains the fixed plan.
`workflow.type`	String	Yes	`"react"`	Use `"react"` for tool workflows and `"hierarchical"` for workflows that delegate to child agents.
`workflow.spec`	Object	Yes	`{}`	Contains graph-specific settings.
`workflow.spec.implicit_tool_selection`	Boolean	No	`false`	When `true`, the reasoning path performs model-native tool selection. When `false`, a dedicated tool-selection step prepares non-direct calls. Direct tool execution bypasses both.
`workflow.spec.workflow_plan`	WorkflowPlan	Yes	`null`	The plan reused for every request.

Warning

The plan must be at workflow.spec.workflow_plan. A top-level workflow_plan, or an extra nested object such as workflow.spec.spec.workflow_plan, is ignored.

WorkflowPlan

{
  "tasks": [
    {
      "task_id": "fetch_record",
      "description": "Fetch the requested record",
      "candidate_tools": ["record_lookup"],
      "dependencies": [],
      "expected_output": "The matching record",
      "output_template": null,
      "result_evaluation": null,
      "requires_analysis": false,
      "status": "pending",
      "known_arguments": [
        {
          "tool_name": "record_lookup",
          "arguments": [
            {
              "name": "query",
              "value": "$$input$$"
            }
          ]
        }
      ],
      "metadata": {
        "skip_llm_arguments_preparation": "yes"
      },
      "output_variable_name": "record",
      "runs_react_loop": false,
      "pause_and_replan": false,
      "skip_vision_prompt_preparation": false
    }
  ],
  "constraints": null,
  "variables_required_to_final_answer": ["record"],
  "parallelism": false,
  "version": "1.0"
}

Plan fields

Field	Type	Required	Default	Runtime behavior
`tasks`	Array[WorkflowTask]	No by schema; yes for a useful automation	`[]`	Initial tasks in the fixed plan. Use at least one task.
`constraints`	Array[String] or `null`	No	`null`	Plan-level guidance. The serialized plan can appear in model context, but the executor does not programmatically enforce these strings. Put hard requirements in the agent control prompt, task descriptions, tool permissions, known arguments, and validating tools.
`variables_required_to_final_answer`	Array[String]	Yes	None	Output-variable names to add explicitly to final-answer context. Use an empty array when no task variable is required.
`parallelism`	Boolean	No	`false`	Plan-level parallel-execution gate. It only has an effect when the agent-level gate is also enabled.
`version`	String	No	`"1.0"`	Plan metadata. The current runtime does not switch behavior by this value; use `"1.0"`.

WorkflowTask

Task fields

Field	Type	Required	Default	Runtime behavior
`task_id`	String	Yes	None	Identifies the task in dependencies and runtime state. IDs must be unique within the plan.
`description`	String	Yes	None	Instructions and context for the task's reasoning or tool-selection step. Be specific enough to execute without reading another task.
`candidate_tools`	Array[String] or `null`	No	`null`	Exact configured tool names available to the task. One tool selects the single-tool path; multiple tools require a React loop for reliable execution.
`candidate_agents`	Array[String] or `null`	Hierarchical plans only	`null`	Exact configured child-agent names available to the task. At least one tool or agent is required by the hierarchical task schema.
`dependencies`	Array[TaskDependency]	No	`[]`	Conditions that must be satisfied before the task can run.
`expected_output`	String	No	`""`	Describes the desired task result and guides tool selection, reasoning, and evaluation. It is not a runtime type declaration.
`output_template`	String or `null`	No	`null`	Natural-language output format passed to an LLM-backed formatter. It is not deterministic placeholder substitution.
`result_evaluation`	String or `null`	No	`null`	Evaluation criteria. Supplying this value triggers result analysis even if `requires_analysis` is `false`; set both fields together for clarity.
`requires_analysis`	Boolean	No	`false`	Runs the LLM-backed result-analysis step before continuing.
`status`	TaskStatus	No	`"pending"`	Initial runtime status. Omit it or set it to `"pending"` in authored plans.
`known_arguments`	Array[KnownArguments] or `null`	No	`null`	Tool arguments known at configuration time or resolved from request/task variables.
`metadata`	Object	No	`{}`	Runtime task options. The public fixed-workflow option is `skip_llm_arguments_preparation`. Other keys should be treated as internal unless documented separately.
`output_variable_name`	String	Yes	None	Name under which the task's result is saved for later tasks and the final answer. Keep it unique and descriptive.
`runs_react_loop`	Boolean	No	`false`	Lets the model reason, call permitted tools or agents repeatedly, and decide when the task is complete. Set it to `true` when more than one candidate tool or agent is supplied.
`pause_and_replan`	Boolean	No	`false`	Turns this task into a replanning checkpoint after its dependencies resolve. The checkpoint task is a placeholder; the model generates a replacement plan instead of executing it normally.
`skip_vision_prompt_preparation`	Boolean	No	`false`	Compatibility field in the planning model. The current runtime has no active consumer for it; do not rely on it to change fixed-workflow behavior.

Choosing a task shape

Configuration	Route
One `candidate_tools` value, `runs_react_loop: false`	Single-tool execution. The model prepares arguments unless direct execution applies.
One candidate tool, matching `known_arguments`, and direct-execution metadata	Direct tool execution with no argument-preparation model call.
Multiple candidate tools and `runs_react_loop: true`	Model-assisted reasoning loop restricted to those tools.
No candidate tools in a React plan	Model reasoning without a required tool.
One `candidate_agents` value in a hierarchical plan	Child-agent delegation path.
Multiple tools or agents with `runs_react_loop: false`	Falls back to reasoning and is not a reliable fixed single action. Set `runs_react_loop: true` or split the work into tasks.

Dependencies

A dependency is a task ID plus the status it must reach:

{
  "dependencies": [
    {
      "task_id": "fetch_record",
      "required_status": "completed"
    }
  ]
}

Field	Type	Required	Default	Runtime behavior
`task_id`	String	Yes	None	Must match another task in the same plan.
`required_status`	TaskStatus	No	`"completed"`	The referenced task must reach this exact status. A completed dependency must also have a recorded task result before the consumer unlocks.

Valid schema values are:

pending
in_progress
skipped
completed
failed
cancelled

Use "completed" for normal data flow. Other values are primarily runtime or recovery states and can create surprising workflows when used as authored dependency conditions.

Task order alone is not a dependency. With serial execution, ready tasks are normally selected in plan order, but every task without dependencies is ready at the beginning of the run. Add explicit dependencies whenever order matters.

Dependency rules

Every referenced task ID must exist.
Task IDs must be unique.
Dependencies must not form a cycle.
A task that consumes $$some_output$$ should depend on the task that produces some_output.
Do not initialize tasks as completed; runtime completion also requires a recorded task result.
A missing dependency, cycle, or unsatisfied status can stall the plan and trigger model-based replanning.

Known arguments

known_arguments is a list because a React-loop task can permit more than one tool. Each entry applies to one exact candidate tool.

{
  "known_arguments": [
    {
      "tool_name": "record_lookup",
      "arguments": [
        {
          "name": "query",
          "value": "$$input$$"
        },
        {
          "name": "limit",
          "value": 10
        },
        {
          "name": "include_archived",
          "value": false
        }
      ]
    }
  ]
}

KnownArguments fields

Field	Type	Required	Runtime behavior
`tool_name`	String	Yes	Must exactly match a tool in the task's `candidate_tools`.
`arguments`	Array[ArgumentValue]	Yes	Known values keyed by the exact argument names in the tool schema. Use `[]` for a no-argument tool entry.

ArgumentValue fields

Field	Type	Required	Runtime behavior
`name`	String	Yes	Exact tool argument name.
`value`	String, number, Boolean, array, object, or `null`-free value	Yes	Static value or, for a top-level string, a dynamic reference. The schema does not accept `null`.

Static arrays and objects are allowed. Dynamic substitution is not recursive: the resolver only processes a top-level string argument value. A placeholder inside an array or object is passed through unchanged.

Dynamic references

Use dynamic references only in top-level string argument values.

Request values

Reference	Resolves to
`$$input$$`	Current request text
`$$context_files[0]$$`	First uploaded context file path
`$$context_files[1]$$`	Second uploaded context file path
`$$context_images[0]$$`	First uploaded image path
`$$context_images[1]$$`	Second uploaded image path

Only input, context_files, and context_images are exposed from request state. Arbitrary state keys, credentials, and tokens cannot be referenced. Indexes are zero-based and an out-of-range index fails resolution.

Previous task outputs

If a previous task has:

{
  "task_id": "fetch_record",
  "output_variable_name": "record"
}

a dependent task can use:

{
  "name": "record_json",
  "value": "$$record$$"
}

The canonical JSON form is a string:

{
  "name": "record_json",
  "value": "$$record$$"
}

Do not use the older object-shaped example:

{
  "name": "record_json",
  "value": {
    "name": "$$record$$"
  }
}

Because value also accepts ordinary JSON objects, agent-core parses that second form as a static object and does not resolve it.

Reference behavior and limitations

References can be the entire value ("$$record$$") or part of a string ("Summarize this record: $$record$$").
JSON-authored references resolve to strings. Use them only for tool arguments that accept strings.
Referencing a list or object stringifies it. For native structured inputs, use a tool that accepts serialized JSON or let a React-loop task prepare the argument.
Scratchpad output variables take precedence over request-state values with the same name.
An unresolved reference is logged and the original placeholder is passed onward, which normally causes tool argument validation or execution to fail.
The resolver also recognizes [variable], {variable}, and [task_id.output_variable], but $$variable$$ is the canonical form for new Advanced Settings JSON configurations.

Direct tool execution

Direct execution bypasses the model call that would otherwise select the single tool and prepare its arguments.

All of the following must be true:

The task has exactly one candidate_tools value.
runs_react_loop is false or omitted.
known_arguments contains an entry whose tool_name exactly matches the candidate tool.
Every required argument in the tool schema is supplied.
Task metadata contains the exact string value shown below.

{
  "metadata": {
    "skip_llm_arguments_preparation": "yes"
  }
}

The value is the string "yes", not Boolean true.

If the metadata is absent, the model receives the known values as context and can fill missing arguments. If the metadata is present but there is no matching known_arguments entry, the task does not gain complete direct arguments and falls back to the normal tool path.

Direct execution removes argument-preparation inference; it does not make the tool itself idempotent. For tools that create, send, delete, charge, or publish, design idempotency and retry safety in the tool or its API.

Outputs and final answers

`output_variable_name`

For a single-tool, non-React task, the tool result is saved with the task's exact output_variable_name. React-loop and reasoning tasks save their synthesized task result under that name when the model marks the task complete.

Use names that:

are unique within the plan;
contain letters, numbers, and underscores;
describe the data rather than the action; and
do not reuse request-state names such as input or context_files.

`variables_required_to_final_answer`

This required list selects task variables that must be included explicitly in the final-answer context:

{
  "variables_required_to_final_answer": [
    "record",
    "record_summary"
  ]
}

Every name should match a task's output_variable_name. Do not depend on list order: the runtime merges this list with variables selected during reasoning and does not guarantee ordering.

Task-result metadata is also supplied to the final-answer step, but listing the important output variables ensures their actual contents are available. Avoid including large intermediate values that the final response does not need.

`output_template`

output_template invokes an LLM-backed formatter after the task produces its content. It is useful for a required shape such as:

{
  "output_template": "Return JSON with exactly these keys: customer_id, status, and next_action."
}

It is not a JSON Schema validator and does not perform literal placeholder replacement. Validate machine-consumed output in the producing tool whenever strict guarantees are required.

Result analysis and replanning

Result analysis

Set both fields together:

{
  "requires_analysis": true,
  "result_evaluation": "The result must contain a non-empty customer_id and a valid status."
}

After task execution, a model evaluates the result. A passing result completes the task; a failing result can lead to retry, failure handling, or replanning. This adds quality control but also latency, cost, and model-dependent behavior.

Providing result_evaluation by itself currently triggers analysis, but using both fields makes the configuration's intent unambiguous.

`pause_and_replan`

A task with pause_and_replan: true is a checkpoint, not a normal action. Once its dependencies resolve, the runtime invokes the task replanner and omits the checkpoint task from the replacement plan.

Use this only when later tasks cannot be known until runtime. It deliberately changes a fixed workflow into an adaptive one.

React-loop tasks

Use a React loop when one task needs multiple calls or when the exact call order cannot be fixed:

{
  "task_id": "research_topic",
  "description": "Research the requested topic and produce a sourced summary",
  "candidate_tools": ["web_search", "page_reader"],
  "known_arguments": [
    {
      "tool_name": "web_search",
      "arguments": [
        {
          "name": "query",
          "value": "$$input$$"
        }
      ]
    }
  ],
  "expected_output": "A concise summary supported by the retrieved sources",
  "output_variable_name": "research_summary",
  "runs_react_loop": true
}

Only tools in candidate_tools are intended to be available to the task. Tool names must match configured runtime names exactly, including any MCP server or proxy prefix.

The model decides which permitted tool to call, can make multiple calls, and decides when the task is complete. known_arguments guides applicable calls but does not turn a multi-tool loop into direct execution.

Hierarchical workflows

Plans containing candidate_agents require workflow.type to be "hierarchical":

{
  "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 user's topic",
            "candidate_agents": ["research_agent"],
            "output_variable_name": "research_notes"
          }
        ],
        "variables_required_to_final_answer": ["research_notes"],
        "parallelism": false,
        "version": "1.0"
      }
    }
  }
}

The named child agents must already be configured on the parent agent. A single-agent task enters the delegation path; multiple candidates require model-assisted selection and should normally set runs_react_loop: true.

known_arguments is reliably bound for tool execution. The current hierarchical delegation path passes task descriptions and dependency context to the agent selection step; it does not provide the same direct argument-binding guarantee for candidate_agents.

Parallel execution

The schema has two parallelism gates:

{
  "enable_parallel_execution": true,
  "workflow": {
    "spec": {
      "workflow_plan": {
        "parallelism": true
      }
    }
  }
}

Both must be true, and only simultaneously ready tasks can be considered. Dependencies still take precedence.

Parallel plan execution is not part of the stable fixed-workflow contract in the current agent-core runtime. Keep both values false for production automations unless your deployed version has a separately validated parallel executor. Serial tasks can still call tools that implement their own safe parallel operations.

Companion agent settings

These existing agent settings often matter to an automation:

Field	Guidance
`max_execution_time`	Ensure the total limit covers every task, retry, analysis step, and final answer.
`local_recursion_limit`	React loops and multi-step plans consume graph steps. If the budget is exhausted, the runtime finalizes with the progress available.
`allow_user_interaction`	Set to `false` for unattended batch or scheduled runs that must never pause for a user response.

Validation checklist

Before saving Advanced Settings JSON:

The text is valid JSON with double-quoted keys and no comments or trailing commas.
use_json_planner is true.
The plan is nested at workflow.spec.workflow_plan.
workflow.type is "react" for tool workflows or "hierarchical" for child-agent workflows.
The plan has at least one task.
Every task ID and output variable name is unique.
Every dependency points to an existing task and the dependency graph is acyclic.
Every tool and argument name exactly matches the configured tool schema.
Every dynamic reference uses the string form and has a matching producer dependency when needed.
Every direct task supplies all required arguments and uses the exact metadata string.
Every required final output appears in variables_required_to_final_answer.
Task status is omitted or "pending".
Parallelism is disabled unless it has been validated for the deployed runtime.

Troubleshooting

Symptom	Likely cause	Fix
The agent creates or follows a different plan	`use_json_planner` is missing/false, or the plan is nested incorrectly	Set `use_json_planner: true` and use `workflow.spec.workflow_plan`
A task never becomes ready	Missing dependency, cycle, wrong `required_status`, or a completed dependency has no task result	Correct the graph and keep normal dependencies on `"completed"`
A placeholder reaches the tool unchanged	Object-shaped reference, misspelled output variable, missing dependency, nested placeholder, or out-of-range file/image index	Use a top-level string such as `"$$record$$"` and verify the producer and index
Direct execution still invokes argument preparation	Multiple candidate tools, `runs_react_loop: true`, missing/mismatched known arguments, or incorrect metadata value	Meet all five direct-execution requirements
The wrong tool is available or selection fails	Tool name does not match the configured runtime name	Copy the exact name, including MCP/proxy prefixes
The final response omits important content	Required output variable is absent or misspelled	Add the exact `output_variable_name` to `variables_required_to_final_answer`
A multi-agent plan raises an incompatibility error	`candidate_agents` is used with a non-hierarchical workflow	Set `workflow.type` to `"hierarchical"`
Enabling `parallelism` has no useful effect or stalls	Only one gate is enabled or the deployed parallel executor is not validated	Disable both gates and use serial dependencies
Output does not exactly match `output_template`	The template is LLM-guided formatting, not validation	Validate or construct strict output inside the tool
A plan unexpectedly changes after a checkpoint or failure	`pause_and_replan`, result analysis, or error recovery invoked the replanner	Remove adaptive fields for a strictly fixed path and make tools return valid results