Building Agents
Journey Builder
Cross-Agent Nodes

Cross-Agent Nodes

Cross-agent nodes let you orchestrate multi-agent workflows and manage transitions between automated flows and human support. Use them to delegate tasks to specialized agents, share context across agent boundaries, and escalate conversations when the AI cannot resolve an issue.

Trigger Agent

The Trigger Agent node invokes another agent's headless run. The target agent executes its own journey independently, and you can optionally wait for the result before continuing the current flow.

Configuration

PropertyTypeDescription
targetAgentIdstringThe ID of the agent to invoke.
targetAgentNamestringDisplay name of the target agent (shown in the editor for readability).
waitForResultbooleanWhen enabled, the flow pauses until the target agent completes (sync mode). When disabled, the node fires and forgets (async mode).
inputVariablesarrayList of variable mappings, each with sourceVar (variable in the current flow) and targetVar (variable name the target agent receives).
outputVariablestringVariable name where the target agent's result is stored (sync mode only).
timeoutMsnumberMaximum time in milliseconds to wait for the target agent's result. Only applies in sync mode.

Sync vs. async mode

In sync mode (waitForResult: true), the current flow pauses at this node until the target agent completes its run or the timeout expires. The target agent's output is captured in the outputVariable, which downstream nodes can reference via {{ outputVariable }}.

In async mode (waitForResult: false), the node dispatches the target agent and immediately continues to the next step. The target agent runs in the background. Use this when you do not need the result in the current flow -- for example, triggering a logging agent or a notification agent.

Input variable mapping

Map variables from the current flow into the target agent's context. Each entry in inputVariables specifies a sourceVar (a variable name in the current conversation) and a targetVar (the variable name the target agent will receive). This lets you pass collected data -- such as a user's email, order ID, or preferences -- into the target agent without that agent needing to re-collect it.

Limits and safeguards

  • Each triggered agent consumes its own credits independently.
  • Recursion is limited to 3 levels deep. If Agent A triggers Agent B, which triggers Agent C, which triggers Agent D, the fourth-level trigger will fail. This prevents runaway chains.

Example use case

A main shopping assistant agent collects the user's preferences and triggers a specialized "Product Matcher" agent with those preferences as input variables. The main agent waits for the result (sync mode, 15-second timeout) and then displays the matched products to the user.

Connection behavior

The Trigger Agent node has a single output. In sync mode, the flow continues after the target agent completes (or the timeout expires). In async mode, the flow continues immediately.


Call Agent

The Call Agent node calls another agent with full context sharing. It is richer than Trigger Agent because it can pass conversation history, visitor metadata, and the parent run ID to the target agent, enabling seamless handoffs between specialized agents.

Configuration

PropertyTypeDescription
targetAgentIdstringThe ID of the agent to call.
callModestringThe execution mode for the call (e.g., inline, background).
callInputMappingRecordKey-value mapping of variables to pass to the target agent. Keys are target variable names, values are source variable names or expressions.
callOutputMappingRecordKey-value mapping of variables to capture from the target agent's result. Keys are local variable names, values are target agent output fields.
timeoutMsnumberMaximum time in milliseconds to wait for the target agent to complete.
includeContextobjectControls which context is shared with the target agent.

Context sharing

The includeContext object has three fields:

  • conversationHistory -- When enabled, the full conversation history up to this point is passed to the target agent. The called agent can read what the user has already said and responded to, avoiding repetitive questions.
  • visitorMetadata -- When enabled, visitor metadata (browser info, page URL, referrer, UTM parameters) is shared with the target agent.
  • parentRunId -- When enabled, the parent agent's run ID is included, allowing the target agent to link its execution back to the originating conversation for analytics and debugging.

When to use Call Agent vs. Trigger Agent

Use Call Agent when the target agent needs to understand the full conversation context -- for example, handing off from a general support agent to a billing specialist who should know what the user already described. Use Trigger Agent when the target agent operates independently and only needs specific input variables -- for example, triggering a report generator with a date range.

Example use case

A general support agent determines that the user has a complex billing dispute. It uses a Call Agent node to hand off to a billing specialist agent, sharing the full conversation history and visitor metadata. The billing agent picks up where the general agent left off, already aware of the issue details. When the billing agent completes, its resolution summary is mapped back into the parent flow via callOutputMapping.

Connection behavior

The Call Agent node has a single output. The flow pauses until the target agent completes or the timeout expires, then continues to the connected node.


Handoff

The Handoff node transfers the conversation from the automated flow to a human agent. It marks the conversation for human review and optionally displays contact information to the user.

Configuration

PropertyTypeDescription
messagestringA message shown to the user when the handoff occurs (e.g., "Let me connect you with our team.").
contactEmailstringOptional email address displayed to the user.
contactPhonestringOptional phone number displayed to the user.
contactUrlstringOptional URL (e.g., a support portal link) displayed to the user.
showContactInfobooleanWhen enabled, the contact details (email, phone, URL) are shown to the user in the chat.

How it works

When the conversation reaches a Handoff node:

  1. The configured message is displayed to the user.
  2. If showContactInfo is enabled and contact details are provided, those details are shown as clickable links.
  3. The conversation is flagged for human review in the Conversations dashboard.
  4. The automated flow stops at this node.

The Handoff node is a terminal node -- it ends the automated portion of the conversation. The diagnostics engine will warn if a Handoff node has no contact target configured.

Example use case

A customer support agent detects that the user's issue requires human intervention (e.g., a refund over the automated limit). The Handoff node displays "I'm connecting you with our support team for a closer look" and shows the support email. The conversation appears in the review queue for a human agent to pick up.

Connection behavior

The Handoff node is terminal. It has no output -- the flow ends here. If you need the flow to resume after human intervention, use a Handoff End node in a separate branch or downstream section.


Handoff End

The Handoff End node marks the end of a human handoff period and returns the conversation back to the automated flow. Use it when a human agent has resolved their portion of the issue and the conversation should continue through the remaining journey nodes.

Configuration

PropertyTypeDescription
messagestringA message shown to the user when the automated flow resumes (e.g., "Thanks for waiting -- I'm back to help with the next steps.").
contactEmailstringOptional email address displayed to the user.
contactPhonestringOptional phone number displayed to the user.
contactUrlstringOptional URL displayed to the user.
showContactInfobooleanWhen enabled, contact details are shown to the user.

How it works

The Handoff End node signals that the human handoff period is complete. When this node is reached:

  1. The configured message is displayed to the user.
  2. The conversation is no longer flagged for human review.
  3. The automated flow resumes from the next connected node.

This is the counterpart to the Handoff node. While Handoff pauses the automated flow, Handoff End resumes it.

Example use case

A support flow hands off to a human agent for a complex billing dispute. After the human resolves the issue, the Handoff End node fires with the message "Great, that's sorted. Let me help you with anything else." The flow then continues to a Quick Reply node offering further assistance options.

Connection behavior

The Handoff End node is terminal in the graph sense (the diagnostics engine treats it as a valid endpoint), but it can have outgoing connections. If connected to a downstream node, the flow continues there after the handoff period ends.