> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asteroid.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Output Node

> Terminate the workflow and return results with a custom outcome label

The **Output Node** marks the end of your agent's execution.
When your agent reaches an Output Node, it:

<CardGroup cols={2}>
  <Card title="End Execution" icon="stop" horizontal>
    Terminates the workflow and closes the browser
  </Card>

  <Card title="Outcome Label" icon="tag" horizontal>
    Assign a custom, meaningful end-state
  </Card>

  <Card title="Structured Result" icon="database" horizontal>
    Return JSON data using a custom schema
  </Card>

  <Card title="Workflow Clarity" icon="flag" horizontal>
    Clearly define how and why a run finished
  </Card>
</CardGroup>

Every workflow should have at least one Output Node to properly conclude execution. Additionally, every AI Task node should be connected to an output node to handle failures.

***

## Configuration

### Outcome Labels

**Outcome Labels** define the possible states your execution can end in.
They work like exit codes or status tags that answer: *“How did this run finish?”*

By default, we return `success` or `failure`, but you can define custom Outcome Labels that reflect your real business logic.

#### Common Patterns

* **Default:**
  `success`, `failure`

* **Business Logic States:**
  `item_purchased`, `out_of_stock`, `login_required`

* **Decision Outcomes:**
  `approved`, `rejected`, `needs_review`

#### Example Outcome Labels

For an e-commerce checkout agent, you might define:

* `purchase_completed`
* `payment_failed`
* `item_unavailable`
* `session_expired`

#### Best Practices for Outcome Labels

* Use clear, descriptive names (e.g., `payment_completed` instead of `done`)
* Define all realistic end states your agent might encounter
* Keep naming consistent across similar workflows
* Use `snake_case`

***

### Result Schema

Alongside an Outcome Label, an Output Node can return **structured data** using a **Result Schema**. This is a custom JSON Schema that defines the shape of the data you expect when this Output Node is reached.

Using Result Schemas ensures outputs are predictable and machine-readable, and makes it easy to consume execution results via API or SDKs.

Our schema format follows [OpenAI Structured Outputs](https://platform.openai.com/docs/guides/structured-outputs) specification (a subset of JSON Schema).

#### When to Use a Result Schema

Use a custom Result Schema when:

* You need structured data in a specific format
* Other services or downstream systems expect defined fields
* You want consistent outputs across executions and environments
* You’re extracting multiple values (prices, names, URLs, IDs, etc.)

#### Example Result Schema

A possible schema for a product-scraping agent:

```json theme={null}
{
  "type": "object",
  "properties": {
    "product_name": {
      "type": "string",
      "description": "The name of the product"
    },
    "price": {
      "type": "number",
      "description": "The product price"
    },
    "in_stock": {
      "type": "boolean",
      "description": "Whether the product is available"
    }
  },
  "additionalProperties": false,
  "required": ["product_name", "price", "in_stock"]
}
```

#### Result Schema Requirements

When defining a Result Schema, follow these rules:

* All **object types** must include `"additionalProperties": false`
* All properties should be listed in the `"required"` array
* Use the `"description"` field to guide the AI in populating values correctly

***

## Tips

* **Start Simple:**
  Begin with Outcome Labels only. Add a Result Schema once you know what data you need to return.

* **Plan End States First:**
  Think through all the ways your agent might finish (success, partial success, failures, edge cases) and design Outcome Labels accordingly.

* **Test Outcomes:**
  Run test executions to verify the workflow can reach each defined Outcome Label.

* **Validate Your Schema:**
  Use the examples in the docs as a reference and ensure your JSON Schema is valid before relying on it in production.

***

## API / YAML Reference

When configuring an Output node via the API, SDK, or MCP, use the following type identifier:

| Field     | Value    |
| --------- | -------- |
| Node type | `output` |

Example `settings.yaml`:

```yaml theme={null}
label: "Result"
type: output
outcomes:
  - success
  - failure
```

The node's result schema (if any) is stored in a separate `schema.json` file in the same directory.
