Skip to main content

Canvas and templating

The Studio canvas is the same across Tools, Agents, and Voice Agents. This page covers the cross-cutting authoring concepts you'll use everywhere.

Nodes and wires​

Every application is a graph of nodes — LLM calls, Knowledge Base searches, API calls, Python code, web scrapers, and so on. Nodes are added from the + Step / + Node picker and configured in a side panel.

Nodes are wired together implicitly by variable references in your field values. When node B references a variable from node A's output, the platform knows B depends on A and runs them in the right order.

You don't typically draw wires manually — you wire by writing {{a.output}} in node B's input.

Variable references with {{ }}​

To reference a variable from a previous node, the Start Point, or a Custom Attribute, wrap it in double curly braces:

{{node_name.output_key}}

Nested access using dotted notation works:

{{api_call.response.body.items.0.title}}

This works in every text-entry field across the platform that supports templating — Tool node fields, Agent base instructions, evaluator config fields in Evaluation, voice agent system prompts, and so on.

Jinja-like expressions​

Templating supports more than simple variable interpolation. Inside {{ }} you can use Jinja-style logic:

Conditionals​

{{ "VIP" if user.tier == "gold" else "Standard" }}

Loops​

{% for item in cart %}
- {{ item.name }} ({{ item.qty }})
{% endfor %}

Filters and basic manipulation​

Standard Jinja filters (upper, lower, length, default, join, replace, etc.) plus dotted access for structured data.

The expression is evaluated at execution time (late binding) using the runtime context — i.e., values that the upstream nodes actually produced for this run. The evaluated result becomes the final value used by the field.

Type casting at field boundaries​

Each field has an expected type — string, number, JSON, etc. When your templated expression's result doesn't match the field's expected type, the platform attempts to cast rather than failing immediately.

Common cases this enables:

  • Pass a node's structured output as a JSON string to a field that expects a JSON object — the platform parses the string.
  • Pass a number as a string to a text field — automatic stringification.
  • Pass a string "42" to a numeric field — automatic numeric cast.

If casting genuinely cannot succeed (e.g., the string isn't parseable to JSON), the cast fails and the step errors with a clear message. But the common "node output is JSON-as-text" pattern that used to require a transform node now works directly.

Node outputs stay native​

Despite type casting at field boundaries, node outputs retain their native types in the workflow context. Casting is applied only at the moment a specific field consumes the value — not globally. This means you can pass a structured object through several nodes without worrying about it being stringified along the way; the stringification (or other cast) happens only at fields that genuinely require a different type.

Custom Attributes​

The Custom Attributes tab in the Start Point drawer stores per-application values you want to reference like environment variables:

  • Per-application secrets (API keys, tokens).
  • Per-application constants (account IDs, region codes, default values).
  • Reference using {{custom_attribute_name}} from any node.

Custom Attributes are stored encrypted when marked as secrets. They survive a Conversation-mode toggle on Tools — see Switching mode.

Default values​

Many fields across the platform have sensible defaults — temperature, top_p, limits, timeouts, retry counts, etc. The default is shown next to the field; if you don't override, the default is used. This applies across Tools (both task mode and Conversation mode), Agents, Voice Agents, and Evaluators.

When you copy / clone an application or import one across deployments, default values are carried correctly so behavior is identical to the source.

What fields support templating​

These fields support {{ }} Jinja templating end-to-end:

  • Tool — all node configuration input fields (LLM prompts, API URLs, headers, payloads, Python code, etc.).
  • Agent — Base Instructions.
  • Evaluation — evaluator setup / configuration fields where instructions or inputs are authored. See Evaluators.
  • Voice Agent — Base instruction and other text fields.

If a field doesn't support templating, the field will use the literal text — no {{ }} evaluation. The product UI distinguishes templated fields visually.