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 conversations that reached it.
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.
Required inputs	Details the agent must collect in conversation before the outcome can complete, such as an email address.
Tools	Configuration for each tool the steps reference.

Writing the steps

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

Use @build_checkout_link to build the link and present it in your reply. If you cannot build a link, switch to the Sales Handoff outcome.

Required inputs

A required input gates the outcome: the agent cannot complete it until the value has come up in conversation. The common case is an email address on a lead-capture outcome, so a lead is never created without a way to contact the person. Formatted fields such as emails are also checked before submission; a malformed value is never written to a lead.

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 carrying the collected fields and the outcome that fired it.

Capture always runs when its outcome is reached. 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 run unconditionally on reach.

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 @build_checkout_link to build the link and present it in your
      reply. If you cannot build a link, switch to the Sales Handoff outcome.
    tools:
      - id: build_checkout_link
        tool: build_checkout_link
  - 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.
    requiredInputs:
      - id: email
        description: Shopper email
    tools:
      - id: data_capture
        tool: data_capture
        config:
          inputs:
            - id: email
            - id: name
            - id: company

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 reported in the transcript instead of executed. You can rehearse a full qualify-and-capture flow without writing a lead.