Outcomes

Give an agent goals: when to pursue them, the steps to follow, and the actions that run when one is reached.

An outcome is a goal the agent works towards: qualify the shopper and send a checkout link, capture a lead for sales, record that the visitor was not a fit. When the agent reaches an outcome, the conversation is recorded with that disposition and the outcome's follow-up actions run, once. Outcomes are what turn a chat transcript into something you can report on and act from.

A sales agent typically has two or three:

Outcome	Reached when	What happens
Qualified - send checkout link	The shopper is ready to buy a self-serve offer.	The agent builds and presents a checkout link.
Sales handoff	The shopper wants to buy but self-serve checkout is not an option.	A lead is captured for a human to follow up.
Not qualified - create lead	The shopper's needs fall outside what the agent can sell.	A lead is captured with their details.

Anatomy of an outcome

Field	What it is
Label and tag	How the outcome appears in the admin: the tag and colour show as a chip on the outcome's card in the agent editor, and conversations that reach it show its label.
When to use	Plain-language criteria the agent matches the conversation against. Also state when not to choose it.
What to do	The steps the agent follows once the criteria match, written as free text with tools referenced as @ mentions.
Tools	Configuration for each tool the steps reference, including the fields a capture tool records and which of them are required.

Writing the steps

Type @ in the "What to do" editor to reference a tool: @fetch_offers, @create_checkout, @data_capture. A configuration panel appears for each referenced tool that takes settings. Keep the steps short and directive:

Use @create_checkout to create the checkout and present the link in your reply. If you cannot create one, switch to the Sales Handoff outcome.

Required fields

A required field gates the tool that submits it, not the outcome. Each field on a capture tool is required unless you mark it optional; if a required field never came up in conversation, that tool's submission is skipped — so a lead is never created without a way to contact the person — and the skip is shown against the outcome in Conversations. The outcome itself is still recorded.

Give a field the type email (on the YAML tab) and its value is also format-checked before submission; a malformed address is treated the same as a missing one.

Capturing leads

Reference @data_capture in an outcome's steps and configure the fields it records (email, name, company, or your own keys). When the outcome is reached, the capture runs once and writes a lead — a data capture order in your orders pipeline, synced to Salesforce if configured — carrying the collected fields and the outcome that fired it.

Capture runs the first time its outcome is reached, provided its required fields were captured and valid. If you only want a lead in some situations, put the capture on its own outcome and route the agent there, rather than describing conditions in the steps.

Branch with outcomes, not conditions

Each outcome should be one unambiguous disposition. Conditions like "if checkout fails, capture their details instead" belong in separate outcomes, because the reached outcome is what your reporting sees, and because follow-up actions are tied to the outcome, not to conditions described in the steps.

Two things make branching reliable:

• In the steps, tell the agent when to switch: "If you cannot build a link, switch to the Sales Handoff outcome."
• In the target outcome's criteria, allow the arrival: if its criteria say "do not choose this for shoppers ready to buy", add "unless you were sent here because checkout could not be completed".

A qualified-plus-handoff pair, as it appears on the YAML tab:

outcomes:
  - id: qualified_send_link
    label: Qualified - Send checkout link
    tag: Qualified
    criteria: The shopper is ready to buy one of the offers you can sell.
    whatToDo: >-
      Use @create_checkout to create the checkout and present the link in
      your reply. If you cannot create one, switch to the Sales Handoff outcome.
    tools:
      - id: create_checkout
        tool: create_checkout
  - id: sales_handoff
    label: Sales Handoff
    tag: Handoff
    criteria: >-
      The shopper wants to buy but checkout could not be completed. You must
      have their email before completing this outcome.
    whatToDo: >-
      Tell the shopper a colleague will follow up shortly and confirm their
      email. Their details are captured automatically.
    tools:
      - id: data_capture
        tool: data_capture
        config:
          inputs:
            - id: email
              type: email
            - id: name
              required: false
            - id: company
              required: false

Capture fields are required unless marked required: false, and a field typed email is format-checked — see Required fields.

Switching outcomes

Outcomes are not terminal. A conversation records the latest outcome reached, so an agent that qualifies a shopper, hits a problem, and hands off to sales ends with the handoff as its disposition. Each outcome's follow-up actions run only the first time it is reached, so revisiting an outcome never duplicates a lead.

What you see in Conversations

Under AI → Conversations, the list shows each conversation's outcome, and opening one shows the outcome panel: the label, the details captured, and the result of each follow-up action. The transcript also carries the agent's internal working: a note the moment it starts pursuing an outcome ("pursuing qualified_send_link: confirmed 40 hires a year and a budget") and a short reason on every tool call. None of this is visible to the shopper.

Testing

In the agent's Try it panel, outcomes behave exactly as configured except that follow-up actions are dry-run — nothing is recorded — and the transcript shows which tools the agent used. You can rehearse a full qualify-and-capture flow without writing a lead.