Agent Script Reference

After you configure the assets and other elements of your agent network project, you build the rest of the workflow using Agent Script. Agent Script enables you to build predictable, context-aware agent workflows that don’t rely solely on interpretation by an LLM.

Agent Script Structure
Node Types
A2A Namespace Functions
Built-in Functions
Node Outputs
Node Expressions and References

Agent Script Structure

The following sections explain settings and configurations specific to MuleSoft agent network projects. To learn more about Agent Script, see the Agent Script documentation.

Dialect Referencing and Versioning

Agent Script files contain a header specifying the dialect and a version binding. SEMVER major and minor are used for fixing to a specific dialect version.

The dialect header specifies that the script is strictly bound to a specific version or later of the AGENTFABRIC dialect. Deploying an agent to a runtime that doesn’t support this version results in an error.

Using major.minor (for example, AGENTFABRIC=1.1) binds to version 1.1 or later
Using major only (for example, AGENTFABRIC=1) references the latest version within that major version

Example

# @dialect: AGENTFABRIC=1.0

System Section

This section defines the instructions attribute, which acts as a default system prompt used whenever an agentic node doesn’t define its own system.instructions.

Example

system:
   instructions: "You are the onboarding agent"

The system section has these parameters.

Parameter Description Type Required

Parameter	Description	Type	Required
`instructions`	Default system prompt used when an agentic node doesn’t define its own `system.instructions`.	String	Yes

instructions

Default system prompt used when an agentic node doesn’t define its own system.instructions.

String

Yes

Agent Config Section

The config section is the standard Agent Script config section, with the addition of the optional default_llm field. This section defines metadata and default settings for the agent.

Example

config:
   agent_name: "employee-onboarding"
   label: "Employee Onboarding Agent"
   description: "An Agent that performs employee onboarding"

The config section has these parameters.

Parameter Description Type Required

Parameter	Description	Type	Required
`agent_name`	The name identifier for the agent.	String	-
`label`	A human-readable display name for the agent.	String	-
`description`	A description of what the agent does.	String	-
`default_llm`	Specifies a default LLM to be used on all agentic nodes that don’t specify otherwise.	@llm reference See LLM	No

agent_name

The name identifier for the agent.

String

label

A human-readable display name for the agent.

String

description

A description of what the agent does.

String

default_llm

Specifies a default LLM to be used on all agentic nodes that don’t specify otherwise.

@llm reference See LLM

LLM Section

The llm element is where you define the LLMs to use for reasoning and generation. Each target must use the llm:// URI scheme so the runtime binds to the correct governed connection.

Example

llm:
    open-api-llm:
     target: "llm://open_ai_connection"
     kind: "OpenAI"
     model: "gpt5-mini"
     reasoning_effort: "LOW"
   gemini-llm:
     target: "llm://gemini_connection"
     kind: "Gemini"
     model: "gemini-3-flash-preview"
     thinking_level: "HIGH"
     top_p: 0.3

LLM Configuration: OpenAI

The OpenAI configuration has these properties.

Bedrock OpenAI uses the openai. prefix for model names (for example, openai.gpt-5.5), which differs from the model names used with OpenAI and Azure OpenAI.

Parameter Description Type Required

Parameter	Description	Type	Required
`target`	Governed LLM connection as a URI; must use the `llm://` scheme	URI (`llm://…`)	Yes
`kind`	Discriminator for the LLM provider; selects which provider-specific attributes apply	String, `OpenAI`	Yes
`model`	The name of the model to use	String	Yes
`reasoning_effort`	Constrains effort on reasoning for reasoning models. gpt-5.1 defaults to `NONE`; previous ones default to `MEDIUM`.	enum['NONE', 'MINIMAL', 'LOW', 'MEDIUM', 'HIGH']	No
`temperature`	Controls randomness in the output	number	No
`top_p`	Nucleus sampling parameter	number	No
`top_logprobs`	Number of most likely tokens to return at each position	integer	No
`max_output_tokens`	Maximum number of tokens to generate	integer	No

target

Governed LLM connection as a URI; must use the llm:// scheme

URI (llm://…)

Yes

kind

Discriminator for the LLM provider; selects which provider-specific attributes apply

String, OpenAI

Yes

model

The name of the model to use

String

Yes

reasoning_effort

Constrains effort on reasoning for reasoning models. gpt-5.1 defaults to NONE; previous ones default to MEDIUM.

enum['NONE', 'MINIMAL', 'LOW', 'MEDIUM', 'HIGH']

temperature

Controls randomness in the output

number

top_p

Nucleus sampling parameter

number

top_logprobs

Number of most likely tokens to return at each position

integer

max_output_tokens

Maximum number of tokens to generate

integer

LLM Configuration: Gemini

The Gemini configuration has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`target`	Governed LLM connection as a URI; must use the `llm://` scheme	URI (`llm://…`)	Yes
`kind`	Discriminator for the LLM provider; selects which provider-specific attributes apply	String, `Gemini`	Yes
`model`	The name of the model to use	String	Yes
`thinking_level`	The level of thoughts tokens that the model should generate	Enum['LOW', 'HIGH']	No
`thinking_budget`	Indicates the thinking budget in tokens. 0 is DISABLED. -1 is AUTOMATIC. The default values and allowed ranges are model dependent	Number	No
`temperature`	Controls the degree of randomness in token selection. Lower temperatures are good for prompts that require a less open-ended or creative response, while higher temperatures can lead to more diverse or creative results	Number	No
`top_p`	Tokens are selected from the most to least probable until the sum of their probabilities equals this value. Use a lower value for less random responses and a higher value for more random responses	Number	No
`response_logprobs`	Whether to return the log probabilities of the tokens that were chosen by the model at each step	Boolean	No
`max_output_tokens`	Maximum number of tokens that can be generated in the response	Integer	No

target

Governed LLM connection as a URI; must use the llm:// scheme

URI (llm://…)

Yes

kind

Discriminator for the LLM provider; selects which provider-specific attributes apply

String, Gemini

Yes

model

The name of the model to use

String

Yes

thinking_level

The level of thoughts tokens that the model should generate

Enum['LOW', 'HIGH']

thinking_budget

Indicates the thinking budget in tokens. 0 is DISABLED. -1 is AUTOMATIC. The default values and allowed ranges are model dependent

Number

temperature

Controls the degree of randomness in token selection. Lower temperatures are good for prompts that require a less open-ended or creative response, while higher temperatures can lead to more diverse or creative results

Number

top_p

Tokens are selected from the most to least probable until the sum of their probabilities equals this value. Use a lower value for less random responses and a higher value for more random responses

Number

response_logprobs

Whether to return the log probabilities of the tokens that were chosen by the model at each step

Boolean

max_output_tokens

Maximum number of tokens that can be generated in the response

Integer

Action Definitions

You define A2A and MCP actions in Agent Script under the top-level actions block. Each action target uses a URI whose scheme is the underlying protocol (for example a2a:// or mcp://), so the runtime can route the connection correctly.

A2A Actions

A2A actions execute the message/send A2A method and do not specify inputs or outputs.

Example

actions:
   hr_agent:
     target: "a2a://hr_agent_connection"
     kind: "a2a:send_message"

A2A actions have these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`target`	Governed A2A connection as a URI; must use the `a2a://` scheme	URI (`a2a://…`)	Yes
`kind`	Indicates that this executes the message/send A2A method.	"a2a:send_message"	Yes

target

Governed A2A connection as a URI; must use the a2a:// scheme

URI (a2a://…)

Yes

kind

Indicates that this executes the message/send A2A method.

"a2a:send_message"

Yes

MCP Actions

MCP actions invoke Model Context Protocol actions with optional input binding.

Example

actions:
   send_slack_message:
     target: "mcp://slack_mcp_connection"
     kind: "mcp:tool"
     tool_name: "send-message"
     inputs:
       channel: string = "my-default-channel"
       message: string

MCP actions have these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`target`	Governed MCP connection as a URI; must use the `mcp://` scheme	URI (`mcp://…`)	Yes
`kind`	Constant indicating that this invokes an MCP tool	"mcp:tool"	Yes
`tool_name`	The name of the tool to call	String	Yes
`inputs`	Define bindable arguments. Input arguments provided are not exhaustive. The tool will auto-discover additional arguments and consider them in slot filling mode.	Object	No

target

Governed MCP connection as a URI; must use the mcp:// scheme

URI (mcp://…)

Yes

kind

Constant indicating that this invokes an MCP tool

"mcp:tool"

Yes

tool_name

The name of the tool to call

String

Yes

inputs

Define bindable arguments. Input arguments provided are not exhaustive. The tool will auto-discover additional arguments and consider them in slot filling mode.

Object

A2A Trigger

Triggers reference one of the interfaces defined for a broker in the agent network. Each broker must have one—and only one—trigger per each interface declared in its agent network.

The A2A trigger reacts to send/message methods and automatically manages the task history, context ID and task IDs. The trigger also responds to various A2A protocol methods.

Agent network only supports triggers using JSON-RPC or HTTP JSON transport.

Example

trigger employeeOnboardingTrigger:
   kind: "a2a"
   target: "brokers://employee-onboarding/a2a"
   on_message: -> transition to @orchestrator.hrSystemOnboard

The A2A trigger has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`kind`	Value that indicates this is an A2A trigger.	`"a2a"`	Yes
`target`	Broker interface entry point. Must use the `brokers://` URI form: `brokers://<brokerName>/<interfaceName>`	URI (`brokers://…`)	Yes
`on_message`	Procedure that executes when the A2A interface receives a new `message/send` request. Must define a transition to the workflow’s initial node.	Procedure	Yes

kind

Value that indicates this is an A2A trigger.

"a2a"

Yes

target

Broker interface entry point. Must use the brokers:// URI form: brokers://<brokerName>/<interfaceName>

URI (brokers://…)

Yes

on_message

Procedure that executes when the A2A interface receives a new message/send request. Must define a transition to the workflow’s initial node.

Procedure

Yes

Node Types

Agent network and Agent Script support these node types.

Choosing the Right Node Type

Use this table to decide which node type fits your use case.

Subagent Orchestrator Generator Executor

	Subagent	Orchestrator	Generator	Executor
Uses an LLM	Yes (reasoning loop)	Yes (reasoning loop)	Yes (single call)	No
Calls actions (A2A/MCP)	Yes—LLM chooses when and how	Yes—LLM coordinates multiple agents/tools	No	Yes—deterministic, fully-bound arguments
Number of LLM iterations	Multiple (configurable loop)	Multiple (configurable loop)	Exactly one	Zero
Slot filling (`…`)	Yes	Yes	No	No
Structured output schema	Yes	Yes	Yes	No
Best for	Single-task reasoning: classification, extraction, semantic routing, human-in-the-loop decisions	Multi-agent coordination: delegating to several agents/tools to achieve a complex goal	One-shot text generation: summaries, formatting, templated responses	Deterministic execution: calling actions with known arguments, setting variables, no LLM judgment needed

Uses an LLM

Yes (reasoning loop)

Yes (single call)

Calls actions (A2A/MCP)

Yes—LLM chooses when and how

Yes—LLM coordinates multiple agents/tools

Yes—deterministic, fully-bound arguments

Number of LLM iterations

Multiple (configurable loop)

Exactly one

Zero

Slot filling (…)

Yes

Structured output schema

Yes

Best for

Single-task reasoning: classification, extraction, semantic routing, human-in-the-loop decisions

Multi-agent coordination: delegating to several agents/tools to achieve a complex goal

One-shot text generation: summaries, formatting, templated responses

Deterministic execution: calling actions with known arguments, setting variables, no LLM judgment needed

Orchestrator vs. Subagent: When to Use Which

Both the orchestrator and subagent nodes run an LLM reasoning loop with access to actions. These are the key differences.

Orchestrator is optimized for workflows where the LLM must coordinate multiple external agents and tools to achieve a goal. The LLM decides which agents to call, in what order, and how to combine their results. Use it when the node needs access to two or more actions and the sequencing between them requires judgment.
Subagent is a general-purpose reasoning node ideal for single-task work: classifying input, extracting structured data, making a routing decision, or interacting with one tool. It also supports human-in-the-loop patterns where the LLM can request clarification.

If the node coordinates multiple agents or tools toward a shared goal, use orchestrator. If it reasons about a single task (even if it uses one action), use subagent.

Subagent Node

This node defines a generic agent loop node, made of a prompt and a set of actions. Because it can use actions and supports human-in-the-loop flows, this node is ideal for implementing patterns like classification, semantic routing, or LLM reasoning.

Example

- subagent profile-extractor:
     description: "Extracts structured user profile data from text"
     reasoning:
       instructions: -> Extract the following information from the user's message: {!@request.payload.message.parts[0].text}
       outputs:
         properties:
           name:
             type: "string"
             description: "Full name of the person"
             minLength: 1
           email:
             type: "string"
             description: "Email address"
             pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
           age:
             type: "integer"
             description: "Person's age"
             minimum: 0
             maximum: 150
           preferences:
             type: "object"
             description: "User preferences"
             properties:
               newsletter:
                 type: "boolean"
                 description: "Whether user wants newsletter"
                 default: "false"
               category:
                 type: "string"
                 description: "Preferred category"
                 enum:
                   - "tech"
                   - "business"
                   - "sports"
           tags:
             type: "array"
             description: "Interest tags"
             items:
               type: "string"
             minItems: 1
             maxItems: 10
       max_number_of_loops: 5
       max_consecutive_errors: 5
       task_timeout_secs: 30
     on_exit: -> transition to @orchestrator.process_profile

The subagent node has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`on_exit`	A procedure that executes when the node execution finishes. If `on_exit` is not defined, the graph ends when the agentic node loop ends.	Procedure, but only `transition_to` statements are allowed.	No
`llm`	Overrides the default LLM setting	@llm reference See LLM Section	No
`system.instructions`	Overrides the global `system.instructions` at the file root level	String	No
`reasoning.instructions`	Session-specific query or instructions for this particular node, typically containing user provided or user related context	String	Yes
`reasoning.actions`	The available actions	Array[actions]	No
`reasoning.outputs`	Schema definition describing the expected structure of the agent’s output	Outputs See Node Outputs	No
`reasoning.max_number_of_loops`	The maximum number of loops an execution can take. Useful for keeping the execution from running too long and consuming too many tokens. Default: 25	Integer	No
`reasoning.max_consecutive_errors`	The maximum number of consecutive errors allowed during execution. Useful for keeping the node from running too long and consuming too many tokens.	Integer	No
`reasoning.task_timeout_secs`	A timeout (in seconds) for the total node execution.	Integer	No
`outputs`	A schema definition for the agentic output.	Object See Node Outputs	No

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

on_exit

A procedure that executes when the node execution finishes. If on_exit is not defined, the graph ends when the agentic node loop ends.

Procedure, but only transition_to statements are allowed.

llm

Overrides the default LLM setting

@llm reference See LLM Section

system.instructions

Overrides the global system.instructions at the file root level

String

reasoning.instructions

Session-specific query or instructions for this particular node, typically containing user provided or user related context

String

Yes

reasoning.actions

The available actions

Array[actions]

reasoning.outputs

Schema definition describing the expected structure of the agent’s output

Outputs See Node Outputs

reasoning.max_number_of_loops

The maximum number of loops an execution can take. Useful for keeping the execution from running too long and consuming too many tokens. Default: 25

Integer

reasoning.max_consecutive_errors

The maximum number of consecutive errors allowed during execution. Useful for keeping the node from running too long and consuming too many tokens.

Integer

reasoning.task_timeout_secs

A timeout (in seconds) for the total node execution.

Integer

outputs

A schema definition for the agentic output.

Object See Node Outputs

Orchestrator Node

The orchestrator node is a specialization of the subagent node used for orchestrating multiple agents and MCP servers to achieve a specified goal. It is optimized for multi-agent orchestration. Use this node type for workflows that need to call multiple external agents or actions to achieve a goal.

Example

orchestrator flight-booking-agent:
     description: books flights by looking for the best offer across approved partners
     system:
       instructions: "You are a flight booking agent. The process for flight booking is: 1. Ask the user for a destination and travel dates and present them with matching alternatives using available actions. 2. Allow the user to change or refine the search. 3. Once the user selects a flight, book it using the concur agent tool."
     reasoning:
       instructions: -> @request.payload.message.parts[0].text
       actions:
         search-flight: @actions.search-flight with companyId = @variables.companyId
         get-flight-info: @actions.get-flight-info
         concur: @actions.concur-agent with http_headers = {"Authorization": @request.headers["Authorization"]}
       max_number_of_loops: 10
       max_consecutive_errors: 10
       task_timeout_secs: 60
     outputs:
       properties:
         flightNumber:
           type: "string"
           description: "The flight identification number"
         airline:
           type: "string"
           description: "The airline name"
     on_exit: -> transition to @executor.send_summary

The orchestrator node has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`on_exit`	A procedure that executes when the node execution finishes. If `on_exit` is not defined, the graph ends when the agentic node loop ends.	Procedure, but only `transition_to` statements are allowed.	No
`llm`	Overrides the default LLM setting	@llm reference See LLM Section	No
`system.instructions`	Overrides the global `system.instructions` at the file root level	String	No
`reasoning.instructions`	Session-specific query or instructions for this particular node, typically containing user provided or user related context	String	Yes
`reasoning.actions`	The available actions	Array[actions]	No
`reasoning.outputs`	Schema definition describing the expected structure of the agent’s output	Outputs See Node Outputs	No
`reasoning.max_number_of_loops`	The maximum number of loops an execution can take. Useful for keeping the execution from running too long and consuming too many tokens. Default: 25	Integer	No
`reasoning.max_consecutive_errors`	The maximum number of consecutive errors allowed during execution. Useful for keeping the node from running too long and consuming too many tokens.	Integer	No
`reasoning.task_timeout_secs`	A timeout (in seconds) for the total node execution.	Integer	No
`outputs`	A schema definition for the agentic output.	Object See Node Outputs	No

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

on_exit

A procedure that executes when the node execution finishes. If on_exit is not defined, the graph ends when the agentic node loop ends.

Procedure, but only transition_to statements are allowed.

llm

Overrides the default LLM setting

@llm reference See LLM Section

system.instructions

Overrides the global system.instructions at the file root level

String

reasoning.instructions

Session-specific query or instructions for this particular node, typically containing user provided or user related context

String

Yes

reasoning.actions

The available actions

Array[actions]

reasoning.outputs

Schema definition describing the expected structure of the agent’s output

Outputs See Node Outputs

reasoning.max_number_of_loops

The maximum number of loops an execution can take. Useful for keeping the execution from running too long and consuming too many tokens. Default: 25

Integer

reasoning.max_consecutive_errors

The maximum number of consecutive errors allowed during execution. Useful for keeping the node from running too long and consuming too many tokens.

Integer

reasoning.task_timeout_secs

A timeout (in seconds) for the total node execution.

Integer

outputs

A schema definition for the agentic output.

Object See Node Outputs

Generator Node

The generator node calls an LLM to generate text. It is not an agent loop, and it does not support human-in-the-loop learning or other actions. It performs exactly one LLM call. Use this node for summarization, formatting, or templated text generation.

Example

generator summarize-report:
     description: "Generate a one-paragraph summary of the report."
     prompt: "Summarize the following in one paragraph: {!@variables.report}"
     on_exit: ->        transition to ...

The generator node has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`on_exit`	A procedure that executes when the node execution finishes. If `on_exit` is not defined, the graph ends when the agentic node ends.	Procedure, but only `transition_to` statements are allowed.	No
`llm`	A reference to the LLM connection.	@llm reference See LLM Section	No
`system.instructions`	Overrides the global `system.instructions` at the file root level for this generator node.	String	No
`prompt`	Session-specific query or instructions for this particular node, typically containing user provided or user related context.	String	Yes
`outputs`	A schema definition for the agentic output.	Object See Node Outputs	No

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

on_exit

A procedure that executes when the node execution finishes. If on_exit is not defined, the graph ends when the agentic node ends.

Procedure, but only transition_to statements are allowed.

llm

A reference to the LLM connection.

@llm reference See LLM Section

system.instructions

Overrides the global system.instructions at the file root level for this generator node.

String

prompt

Session-specific query or instructions for this particular node, typically containing user provided or user related context.

String

Yes

outputs

A schema definition for the agentic output.

Object See Node Outputs

Executor Node

The executor node executes Agent Script statements deterministically and no LLM is involved. Because there is no LLM reasoning loop, every action argument must be fully resolved at execution time (you cannot use slot filling … in an executor). Use this node when you need to call an action with known arguments, store a computed value in a variable, or chain multiple deterministic steps before transitioning.

Example

executor sendHrSlackUpdate:
   do: -> run @actions.send_slack_message with text=@generator.generate-hr-slack-update-message.output with channel_id="my-onboarding-channel-id"
   on_exit: -> transition to @router.countrySwitch

Example with multiple statements:

executor prepareAndNotify:
  description: "Sets the ticket status variable and sends a Slack notification."
  do: ->
    set @variables.ticketStatus = "resolved"
    run @actions.send_slack_message
      with text="Ticket " + @generator.classifySeverity.output.ticket_id + " resolved"
      with channel_id=@variables.notificationChannel
  on_exit: -> transition to @echo.finalResponse

The executor node has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`on_exit`	A procedure that executes when the node execution finishes. If `on_exit` is not defined, the graph ends when the executor ends.	Procedure, but only `transition_to` statements are allowed.	No
`do`	A procedure containing one or more Agent Script statements to execute deterministically. See Supported Statements in `do`.	Procedure	Yes

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

on_exit

A procedure that executes when the node execution finishes. If on_exit is not defined, the graph ends when the executor ends.

Procedure, but only transition_to statements are allowed.

do

A procedure containing one or more Agent Script statements to execute deterministically. See Supported Statements in do.

Procedure

Yes

Supported Statements in `do`

The do block accepts a procedure (→) containing one or more of these statements:

Statement Description Example

Statement	Description	Example
`run @actions.<name>`	Invoke a defined action. Use `with` to bind arguments from variables, node outputs, or literal values. All arguments must be fully resolved (no slot filling). Multiple `with` clauses can be chained.	`run @actions.escalate` or `run @actions.send_slack_message with text=@generator.summary.output with channel_id="my-channel"`
`set @variables.<name> = <expression>`	Store a value in a workflow variable for use in downstream nodes.	`set @variables.ticketStatus = "escalated"`

run @actions.<name>

Invoke a defined action. Use with to bind arguments from variables, node outputs, or literal values. All arguments must be fully resolved (no slot filling). Multiple with clauses can be chained.

run @actions.escalate or run @actions.send_slack_message with text=@generator.summary.output with channel_id="my-channel"

set @variables.<name> = <expression>

Store a value in a workflow variable for use in downstream nodes.

set @variables.ticketStatus = "escalated"

Router Node

The router node performs dynamic transitions based on deterministic conditions. This node doesn’t support transition to in its on_exit attribute. Use this node for branching based on structured output from a previous node.

Example

router countryRouter:
   routes:
     - target: @orchestrator.argentinaOnboard
       when: @orchestrator.hrSystemOnboard.output.country  == "ARG"
       label: "Argentina"
     - target: @orchestrator.usOnboard
       when: @orchestrator.hrSystemOnboard.output.country  == "USA"
       label: "USA"
   otherwise:
     target: @echo.invalidCountryResponse

The router node has these properties.

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`routes`	An array of condition and target pairs, plus an optional label field for UI. Must define at least one route. Each route contains: `target`, `when`, and optional `label`.	Array	Yes
`otherwise`	Defines a default transition when no route condition matches. Contains: `target`.	Object	Yes with `routes`

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

routes

An array of condition and target pairs, plus an optional label field for UI. Must define at least one route. Each route contains: target, when, and optional label.

Array

Yes

otherwise

Defines a default transition when no route condition matches. Contains: target.

Object

Yes with routes

Echo Node

The echo node sends a response back to the client. The number of responses depends on the trigger interface and its configuration. Use this node for the end of a workflow, or anytime you want to emit a response.

Example

echo addArtifact:
  kind: "a2a:artifact_update_event"
  artifact: a2a.artifact({
    artifactId: uuid(),
    name: "myArtifact",
    description: "this is optional",
    parts: [
      a2a.textPart("You have been onboarded! Your employee ID is " + @orchestrator.hrSystemOnboard.output.employeeId)
    ],
    metadata: {},
  }),
  append: false
  lastChunk: false

echo setStatus:
  kind: "a2a:status_update_event"
  state: "TASK_STATE_COMPLETED",
  message: a2a.message({
    messageId: uuid(),
    parts: [
      a2a.textPart("You have been onboarded! Your employee ID is " + @orchestrator.hrSystemOnboard.output.employeeId)
    ]
  })

Parameter Description Type Required

Parameter	Description	Type	Required
`id`	The node identifier, defined next to the node type.	String	Yes
`label`	An optional short, human-readable display name for the node.	String	No
`description`	A CommonMark string providing a description of the node.	String	No
`on_exit`	A procedure that executes when the node execution finishes. If `on_exit` is not defined, the graph ends when the agentic node loop ends.	Procedure, but only `transition_to` statements are allowed.	No
`kind`	Discriminator for the event type. Valid values: `a2a:status_update_event`, `a2a:artifact_update_event`.	String	Yes
`state`	The task state. Used with `a2a:status_update_event` kind.	String	Yes (for `status_update_event`)
`message`	A message object created via `a2a.message()`. Used with `a2a:status_update_event` kind.	Message object	Yes (for `status_update_event`)
`artifact`	An artifact object created via `a2a.artifact()`. Used with `a2a:artifact_update_event` kind.	Artifact object	Yes (for `artifact_update_event`)
`append`	Whether to append to an existing artifact. Used with `a2a:artifact_update_event` kind.	Boolean	No
`lastChunk`	Whether this is the last chunk of the artifact. Used with `a2a:artifact_update_event` kind.	Boolean	No
`metadata`	Optional metadata dictionary.	dict	No

id

The node identifier, defined next to the node type.

String

Yes

label

An optional short, human-readable display name for the node.

String

description

A CommonMark string providing a description of the node.

String

on_exit

A procedure that executes when the node execution finishes. If on_exit is not defined, the graph ends when the agentic node loop ends.

Procedure, but only transition_to statements are allowed.

kind

Discriminator for the event type. Valid values: a2a:status_update_event, a2a:artifact_update_event.

String

Yes

state

The task state. Used with a2a:status_update_event kind.

String

Yes (for status_update_event)

message

A message object created via a2a.message(). Used with a2a:status_update_event kind.

Message object

Yes (for status_update_event)

artifact

An artifact object created via a2a.artifact(). Used with a2a:artifact_update_event kind.

Artifact object

Yes (for artifact_update_event)

append

Whether to append to an existing artifact. Used with a2a:artifact_update_event kind.

Boolean

lastChunk

Whether this is the last chunk of the artifact. Used with a2a:artifact_update_event kind.

Boolean

metadata

Optional metadata dictionary.

dict

The following table summarizes echo node parameters organized by kind.

Kind Required Parameters Optional Parameters

Kind	Required Parameters	Optional Parameters
`a2a:artifact_update_event`	`artifact` (object created via `a2a.artifact()`)	`append` (boolean), `lastChunk` (boolean)
`a2a:status_update_event`	`state` (string), `message` (object created via `a2a.message()`)	`metadata` (dict)

a2a:artifact_update_event

artifact (object created via a2a.artifact())

append (boolean), lastChunk (boolean)

a2a:status_update_event

state (string), message (object created via a2a.message())

metadata (dict)

Echo Node Behavior

The following table describes echo node behavior based on the A2A operation used by the client.

Operation / Condition Echo Behavior

Operation / Condition	Echo Behavior
`SendMessage` with `returnImmediately = false`	Each echo invocation updates the stored task. Each echo invocation emits a push notification payload for all created push notifications. A consolidated response is emitted when the graph ends or is suspended.
`SendMessage` with `returnImmediately = true`	An immediate response is sent before graph execution is triggered. The response includes the task and context ID. A stored task entry with the response already exists before graph execution begins. All echo invocations update the stored task atomically (including consolidated and individual events). Each echo invocation emits a push notification payload for all created push notifications.
`SendStreamingMessage`	All echo invocations update the stored task atomically (including consolidated and individual events). All individual events are sent through the event stream. Each echo invocation emits a push notification payload for all created push notifications.
`SubscribeToTask`	This condition works on top of the scenarios above. Any task in a non-terminal state can be subscribed to. Whenever echo is executed, events are pushed to all subscribed clients.

SendMessage with returnImmediately = false

Each echo invocation updates the stored task. Each echo invocation emits a push notification payload for all created push notifications. A consolidated response is emitted when the graph ends or is suspended.

SendMessage with returnImmediately = true

An immediate response is sent before graph execution is triggered. The response includes the task and context ID. A stored task entry with the response already exists before graph execution begins. All echo invocations update the stored task atomically (including consolidated and individual events). Each echo invocation emits a push notification payload for all created push notifications.

SendStreamingMessage

All echo invocations update the stored task atomically (including consolidated and individual events). All individual events are sent through the event stream. Each echo invocation emits a push notification payload for all created push notifications.

SubscribeToTask

This condition works on top of the scenarios above. Any task in a non-terminal state can be subscribed to. Whenever echo is executed, events are pushed to all subscribed clients.

A2A Namespace Functions

The a2a namespace provides a set of functions that support A2A Task object creation. Do not prefix these functions with @ as it’s reserved for references such as @variables, @actions, @request, and @orchestrator.<nodeId>.

Function Description Input Arguments Output Example

Function	Description	Input Arguments	Output	Example
`a2a.message`	Builds an A2A Message object	`messageId: str` (required) `parts: list` (required, from `a2a.textPart/a2a.dataPart/a2a.filePart`) `role: str` (optional, default: "agent") `metadata: dict` (optional)	`dict` (Message)	`a2a.message({messageId: uuid(), parts: [a2a.textPart("Hello")]})`
`a2a.textPart`	Builds a TextPart object (kind: "text")	`text: str` (required) `metadata: dict` (optional)	`dict` (TextPart)	`a2a.textPart("Employee ID: {!@orchestrator.employee.id}") a2a.textPart("Status: Complete", metadata={priority: "high"})`
`a2a.dataPart`	Builds a DataPart object (kind: "data")	`data: dict` (required) `metadata: dict` (optional)	`dict` (DataPart)	`a2a.dataPart({employeeId: "E123", department: "Engineering"}) a2a.dataPart(@orchestrator.result.output)`
`a2a.filePart`	Builds a FilePart object (kind: "file")	`uri: str` (optional, required if bytes not provided) `bytes: str` (optional, base64-encoded) `name: str` (optional) `mime_type: str` (optional) `metadata: dict` (optional)	`dict` (FilePart)	`a2a.filePart(uri="https://example.com/report.pdf", name="report.pdf", mime_type="application/pdf") a2a.filePart(bytes="SGVsbG8gV29ybGQ=", name="data.txt")`
`a2a.artifact`	Builds an A2A Artifact object	`artifactId: str` (optional, auto-generated) `name: str` (optional) `description: str` (optional) `parts: list` (required, from `a2a.textPart/a2a.dataPart/a2a.filePart`) `metadata: dict` (optional)	`dict` (Artifact)	`a2a.artifact({artifactId: uuid(), name: "Results", parts: [a2a.dataPart(…)]})`

a2a.message

Builds an A2A Message object

messageId: str (required) parts: list (required, from a2a.textPart/a2a.dataPart/a2a.filePart) role: str (optional, default: "agent") metadata: dict (optional)

dict (Message)

a2a.message({messageId: uuid(), parts: [a2a.textPart("Hello")]})

a2a.textPart

Builds a TextPart object (kind: "text")

text: str (required) metadata: dict (optional)

dict (TextPart)

a2a.textPart("Employee ID: {!@orchestrator.employee.id}") a2a.textPart("Status: Complete", metadata={priority: "high"})

a2a.dataPart

Builds a DataPart object (kind: "data")

data: dict (required) metadata: dict (optional)

dict (DataPart)

a2a.dataPart({employeeId: "E123", department: "Engineering"}) a2a.dataPart(@orchestrator.result.output)

a2a.filePart

Builds a FilePart object (kind: "file")

uri: str (optional, required if bytes not provided) bytes: str (optional, base64-encoded) name: str (optional) mime_type: str (optional) metadata: dict (optional)

dict (FilePart)

a2a.filePart(uri="https://example.com/report.pdf", name="report.pdf", mime_type="application/pdf") a2a.filePart(bytes="SGVsbG8gV29ybGQ=", name="data.txt")

a2a.artifact

Builds an A2A Artifact object

artifactId: str (optional, auto-generated) name: str (optional) description: str (optional) parts: list (required, from a2a.textPart/a2a.dataPart/a2a.filePart) metadata: dict (optional)

dict (Artifact)

a2a.artifact({artifactId: uuid(), name: "Results", parts: [a2a.dataPart(…)]})

Usage notes:

Functions are designed to be composed: a2a.message and a2a.artifact accept parts created by a2a.textPart/a2a.dataPart/a2a.filePart.
a2a.filePart requires either uri OR bytes (base64-encoded), but not both.
a2a.artifact auto-generates artifactId if it’s not provided.
All metadata parameters are optional and accept arbitrary dictionaries.
For tasks, it’s not necessary to define the id, contextId and history attributes, those are automatically populated by the trigger.

Built-in Functions

Use these functions in expressions alongside references and interpolations. They include time and ID helpers (now, uuid), string utilities (strip, startswith, and endswith), JSON parsing (parse_json), and common numeric helpers (abs, round, and sum) for deterministic math-style logic without calling external tools.

Function Description Input arguments Output Example

Function	Description	Input arguments	Output	Example
`now`	Current UTC time in ISO 8601 format	None	String (ISO 8601)	`now()`
`uuid`	Random UUID v4	None	String (UUID)	`uuid()`
`strip`	Removes leading/trailing characters from a string	String, optional chars (default: whitespace)	String	`strip(" hello ") → "hello"`
`startswith`	Whether a string starts with a prefix	String, prefix	Boolean	`startswith("hello world", "hello")`
`endswith`	Whether a string ends with a suffix	String, suffix	Boolean	`endswith("report.pdf", ".pdf")`
`abs`	Absolute value	Number	Number	`abs(-42)`
`round`	Round to optional digit count	Number, optional `ndigits`	Number	`round(3.14159, 2)`
`sum`	Sum of a numeric list	List	Number	`sum([10, 20, 30])`
`parse_json`	Parse a JSON string	String (valid JSON)	Object or array	`parse_json('{"key": "value"}')`

now

Current UTC time in ISO 8601 format

None

String (ISO 8601)

now()

uuid

Random UUID v4

None

String (UUID)

uuid()

strip

Removes leading/trailing characters from a string

String, optional chars (default: whitespace)

String

strip(" hello ") → "hello"

startswith

Whether a string starts with a prefix

String, prefix

Boolean

startswith("hello world", "hello")

endswith

Whether a string ends with a suffix

String, suffix

Boolean

endswith("report.pdf", ".pdf")

abs

Absolute value

Number

abs(-42)

round

Round to optional digit count

Number, optional ndigits

Number

round(3.14159, 2)

sum

Sum of a numeric list

List

Number

sum([10, 20, 30])

parse_json

Parse a JSON string

String (valid JSON)

Object or array

parse_json('{"key": "value"}')

Node Outputs

Use the outputs field to define the expected shape of the agent’s response using a schema notation similar to a JSON schema. When provided, the agent produces output matching the defined structure for downstream parsing and processing.

Each property maps to a field in the agent’s output. These types are supported.

Note: Advanced JSON schema features are not supported, so do not copy patterns from generic JSON Schema tutorials unless they match what is documented here.

Type Description

Type	Description
String	Text values with optional constraints like `pattern` (regex), `minLength`, `maxLength`, and `enum` (allowed values).
Number / Integer	Numeric values with optional constraints like `minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, and `enum`.
Boolean	`True` or `False` (with optional default).
Array	Lists of items, where `items` define the schema for each element (can be any supported type). Supports `minItems` and `maxItems`.
Object	Nested structures with their own `properties` map. Supports a `required` array to specify mandatory fields.

String

Text values with optional constraints like pattern (regex), minLength, maxLength, and enum (allowed values).

Number / Integer

Numeric values with optional constraints like minimum, maximum, exclusiveMinimum, exclusiveMaximum, and enum.

Boolean

True or False (with optional default).

Array

Lists of items, where items define the schema for each element (can be any supported type). Supports minItems and maxItems.

Object

Nested structures with their own properties map. Supports a required array to specify mandatory fields.

Each property definition can include:

type: The data type (required).
description: A human-readable explanation of the property’s purpose.
default: A default value if the property is omitted.

The outputs definition doesn’t support:

additionalProperties or similar JSON Schema extensibility flags
Combinators such as anyOf, oneOf, or allOf
References or shared definitions ($ref, $defs)
Composition beyond nested object / array structures as described above

Node Expressions and References

Nodes access data from other parts of the workflow using expressions.

These references are used.

Prefix Reference Example

Prefix	Reference	Example
`@llm.`	LLM definitions	`@llm.open-api-llm`
`@actions.`	action definitions	`@actions.hr_agent`
`@request.`	Trigger request data	`@request.payload`, `@request.interface`
`@request.headers`	HTTP headers (case-insensitive)	`@request.headers["Authorization"]`
`@variables.`	Workflow variables	`@variables.companyId`
`@<nodeType>.<nodeId>.`	Node references	`@orchestrator.hrOnboard.output`

@llm.

LLM definitions

@llm.open-api-llm

@actions.

action definitions

@actions.hr_agent

@request.

Trigger request data

@request.payload, @request.interface

@request.headers

HTTP headers (case-insensitive)

@request.headers["Authorization"]

@variables.

Workflow variables

@variables.companyId

@<nodeType>.<nodeId>.

Node references

@orchestrator.hrOnboard.output

Accessing Node Output and Input

Every node has .output (the value it produced) and .input (the output of whichever node transitioned into it).

If a node doesn’t produce a value (for example, a router), its .output is None.
If the preceding node is a trigger, .input is None.

Example

@orchestrator.hrSystemOnboard.output.employeeId  # returns the `employeeId` property of the object returned by the `hrSystemOnboard` node
@generator.writeEmailContent.output              # returns the string generated by the `writeEmailContent` node

When to Use `.output` vs `.input`

Use .output when you know exactly which upstream node you need data from. In a straight-line graph, .output is the simplest approach:

process ──► generate_email ──► send_email

generate_email reads @subagent.process.output as the source content.
send_email reads @generator.generate_email.output as its content.

An expression can target any preceding node in the graph, not only the node immediately before the current node.

To decouple a node from the path that reached it, use .input. In this example, @generator.generate_email.input returns the output from whichever of node_a, node_b, or node_c transitioned into generate_email:

node_a ──┐
node_b ──┼──► generate_email ──► send_email
node_c ──┘

Accessing Trigger Data

The @request namespace provides access to the trigger’s incoming request data. Use @request expressions to read the payload, headers, and other properties of the request that started the workflow.

@request.payload: Returns the request payload. For the on_message handler of the A2A trigger, this expression returns a SendMessageRequest object.
@request.interface: Returns the name of the interface that produced the message (for example, a2a).

For A2A triggers, these additional references are also available:

@request.headers: A case-insensitive dictionary of the HTTP request headers. For example, @request.headers["Authorization"] and @request.headers["authorization"] return the same value.
@request.taskId: The current A2A task ID, either provided in the request or automatically generated by the trigger.
@request.contextId: The current A2A context ID, either provided in the request or automatically generated by the trigger.

Example

reasoning:
  instructions: -> @request.payload.message.parts[0].text
  actions:
    concur: @actions.concur-agent with http_headers = {"Authorization": @request.headers["Authorization"]}

Setting Action Headers

Any actions that connect to an external system often need to set custom headers. Use cases range from propagating authorization headers (for example, in OBO authentication) to adding custom correlation information.

For this, both the MCP and A2A actions automatically get an implicit optional http_headers parameter object type that can be used to set those:

actions:
   my_hr_agent: @actions.hr_agent     with http_headers = {"Authorization": @request.headers["Authorization"], "X-CorrelationId": @variables.conversationId}

String Interpolation

Use {!expression} to embed values inside strings.

Example

prompt: "The employee's country is {!@orchestrator.hrOnboard.output.country}"

Slot Filling

Use slot filling (…) to tell an LLM to figure out a value.

Example

actions:
   send_message: @actions.send_slack_message     with message = ...
    # LLM decides the message content

Tool Binding at the Node Level

When you reference a tool inside a node, you can fix, default, or slot-fill its arguments using with.

Example

actions:
   # All arguments via slot filling (LLM decides everything)
   sendToDefault: @actions.send_slack
   # Fix the channel, LLM fills the message
   sendToFixed: @actions.send_slack     with channel = "agent-fabric"
   # Fix everything -- fully deterministic
   fullyDeterministic: @actions.send_slack     with message = @variables.calculatedMessage     with channel = @variables.channelId

Agent Script Reference

Agent Script Structure

Dialect Referencing and Versioning

System Section

Agent Config Section

LLM Section

LLM Configuration: OpenAI

LLM Configuration: Gemini

Action Definitions

A2A Actions

MCP Actions

A2A Trigger

Node Types

Choosing the Right Node Type

Orchestrator vs. Subagent: When to Use Which

Subagent Node

Orchestrator Node

Generator Node

Executor Node

Supported Statements in do

Router Node

Echo Node

Echo Node Behavior

A2A Namespace Functions

Built-in Functions

Node Outputs

Node Expressions and References

Accessing Node Output and Input

When to Use .output vs .input

Accessing Trigger Data

Setting Action Headers

String Interpolation

Slot Filling

Tool Binding at the Node Level

Supported Statements in `do`

When to Use `.output` vs `.input`