> For the complete documentation index, see [llms.txt](https://docs.limio.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.limio.com/ai/limio-agents/outcomes.md). # Outcomes 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`, `@build_checkout_link`, `@data_capture`. A configuration panel appears for each referenced tool that takes settings. 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 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: ```yaml 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. 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](#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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.limio.com/ai/limio-agents/outcomes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.