An execution environment in Agent Builder is a set of variables that are available to a block as it runs. It includes the agent’s state variables, along with the variables from the preceding blocks in the blueprint. You can access variables from the execution environment in the blueprint and in custom code.

The execution environment is specific to each block in the blueprint and changes based on the block’s inputs, outputs, and state.

This document includes:

​
Execution environment explained

Think of an execution environment like a toolbox that a block can access while it’s running. This toolbox contains useful information that your agent needs to do its job, like remembering information from earlier steps or accessing important values you’ve saved. Blocks can add, remove, and update variables in the execution environment as they run.

Most of the information in the toolbox is primarily useful for internal use, debugging, and advanced use cases, but two are particularly important for you as you build workflows:

  • result: the output from the previous block
  • payload: data from UI interactions like button clicks or user messages

For example, a UI Trigger block that’s configured to start when a user uploads a file adds the file to the execution environment. Other blocks in the blueprint can access the file.

Whenever a block finishes running, it adds its result to the execution environment. This result is then available to the next block in the blueprint so it can act on it.

​
Example from a blueprint

Consider the following section of a blueprint that generates text based on a specific prompt. It shows two connected blocks:

  • A Text generation block that generates text based on a specific prompt
  • A Set state block that sets a state variable with the results of the Text generation block

  • The Text generation block uses the state variable product to access information that the user input via the UI. It then generates text based on that information.
  • The Set state block’s execution environment includes the result variable from the Text generation block, which is the summary of the file. It sets a state variable with that result so that the UI can display the summary.

​
Variables available to each block

The following table shows the variables that are available to each block in the execution environment. Not all variables are available in all blocks; for example, the api_calls variable is only available when the block makes an API call.

Many of these variables are primarily useful for internal use, debugging, and advanced use cases. However, the result and payload variables are particularly useful for building workflows.

VariableTypeDescriptionExample
api_callsarray[dict]Any API calls made by the agent at this block, including the request and the response.[{'request': {'method': 'POST', ...}, 'response': {'status_code': 200, ...}}]
call_stackdictThe call stack of the agent. The key is the index of the block in the call stack and the value is the block ID.{0: "123abc", 1: "456def"}
contextdictThe ID of the block that triggered the blueprint execution and the event that triggered it.{'target': '123abc', 'event': 'wf-click'}
payloaddictProvided by UI Trigger blocks. The payload varies based on the type of trigger. For example, a wf-click event includes information about keys the user pressed while clicking the button. A wf-chatbot-message event includes the message the user sent to the chatbot.{'role': 'user', 'content': 'What is the capital of Japan?'}
resultvariesThe result of the preceding block. The type of the result varies based on the block.Thank you so much for your wonderful review! We're thrilled to hear that you've found the perfect tailored blazer with us.
resultsdictThe full list of results from all blocks in the blueprint. It’s a dictionary where the key is the block ID and the value is the result of the block. If the block hasn’t run yet, the value is null.{'123abc': 'Thank you so much...', '456def': '%Generating response...', '789ghi': null}
sessiondictSession information, such as the session ID, cookies, headers, and user information.{'id': '123', 'cookies': {...}, 'headers': {...}, 'userInfo': {}}
statedictThe agent’s state variables.{'user_name': 'John', 'persona': 'sales'}
targetstrThe ID of the next block to run.'123abc'
uiobjectThe UI of the agent as a WriterUIManager object. This is a Python object that allows you to interact with the UI of the agent via custom code.

​
Access execution environment variables

​
In blueprint blocks

You can read the execution environment variables in blueprint blocks using @{variable_name} syntax. For example, @{result} accesses the result of the preceding block.

This example shows a Set state block that uses the @{result} variable to access the result of the preceding block. The block sets a state variable message with the string Result: and the output of the preceding block.

​
Nested variable syntax

You can access nested variables in blueprint blocks using dot notation. For example, @{result.0.id} accesses the id field of the first result of the preceding block.

This example shows a Set state block to set a file_id state variable from an Add files to Writer Cloud block. It uses @{result.0.id} to access the id field of the first item in the result of the preceding block.

Here is the what the result variable looks like in the execution environment. It’s possible to add multiple files to Writer Cloud, so the result variable from this block is an array of dictionaries. The 0 index accesses the first item in the array.

The Set state block uses @{result.0.id} to access the id field of the first item in the result of the preceding block.

​
In custom Python code

You can access the execution environment variables in custom Python code directly as variables.

For example, this Python block in the blueprint accesses the output of the preceding block and prepends the string Result: to it. It then sets state variable message with the final result.