Data flow and variables

An agent's run is a sequence of steps, and the value of each step usually depends on what happened before it. This page covers how data moves from one step to the next and how the agentic loop decides which tool to reach for at each point.

Step outputs feed later steps

When a step completes — a tool call, a code execution, a knowledge search — its output becomes available to the steps that follow it. Instead of hardcoding a value, a later step can reference the output of an earlier one, so the agent can carry a result forward: a value looked up in one step becomes an argument passed into the next, a document found via knowledge_search becomes context for the response that quotes it, a number computed in code_execution becomes input to an api_call.

This is what lets an agent do more than a single tool call: it chains steps together, using the real output of each one rather than guessing at what it might have been.

Passing inputs

A run typically starts with some input — a message, a form submission, a webhook payload, a scheduled trigger with no input at all. That initial input is available to the first step just like any step output is available downstream, so the whole run has a consistent way of referencing "the thing I need to work with," whether it originated from the trigger or from a step earlier in the chain.

Referencing prior outputs

Rather than copying values by hand, steps reference each other through templated references — a step points at another step's output, and at run time that reference is resolved to the actual value produced. This keeps the graph honest: if an earlier step's output changes because the world changed (a different search result, a different API response), everything downstream that depends on it picks up the new value automatically, instead of working from a stale copy.

You can see this resolution happen live: the execution trace records each step's tool, arguments, and output, so you can confirm exactly what value flowed into what.

How the agentic loop chooses tools

The loop driving a run is a bounded, multi-turn tool-calling loop, not a single-shot call. At each turn, the model looks at the goal, the conversation and step history so far, and the tools available to it, and decides what to do next: call a tool, ask for more information, or finish. Whatever it decides to call, the arguments are validated against that tool's schema before execution — if validation fails, the error is fed back to the model so it can correct itself, rather than crashing the run.

This continues for up to a bounded number of steps (eight by default), which keeps a run from looping indefinitely while still giving the agent enough turns to gather information, act, and check its work. If a step would be destructive, the loop halts and waits for approval before continuing — see guardrails for how that gate works alongside the rest of the run's safety controls.

Designing for clear data flow

When you're wiring an agent — whether through the conversational builder or the canvas — it helps to think in terms of what each step needs and where that value comes from. A step that needs a customer's account ID should reference the step that looked it up, not repeat logic to fetch it again. Keeping references explicit, rather than relying on the model to re-derive values, makes runs faster, cheaper, and easier to debug from the execution trace.