> ## 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.

# Versions & Publishing

> How agent versions, drafts, and publishing determine which instructions an execution runs

Every agent on Asteroid is versioned. Each time you edit an agent in the Builder (or Astro edits it for you), the changes are saved to a **draft version** — your **published version** keeps running untouched until you explicitly publish.

<CardGroup cols={2}>
  <Card title="Draft" icon="pencil" horizontal>
    Where edits land. Safe to iterate on — production runs are unaffected
  </Card>

  <Card title="Published" icon="rocket" horizontal>
    The stable version that API-triggered and scheduled executions run by default
  </Card>
</CardGroup>

***

## Which version does an execution run?

An execution runs exactly one version of the agent, and edits made in a draft **do not** apply until published.

| How the execution is triggered     | Version used                                                                                                                                                          |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **API / SDK** (`agentExecutePost`) | The latest **published** version, unless a `version` is passed in the request body                                                                                    |
| **Schedules & integrations**       | The latest **published** version by default ("Always Latest"); a schedule pinned to a specific version keeps running that version, even after you publish a newer one |
| **Platform UI (Run button)**       | The version you select in the run modal — including drafts                                                                                                            |

<Warning>
  If you edit an agent and your API-triggered executions don't pick up the changes, check that the new version is **published**. Test runs from the Builder can target the draft, so an agent can look correct in testing while production still runs the older published version.
</Warning>

## Running a draft from the UI

When running from the platform, the run modal has a **version selector** in the top right. Use it to run any version — including unpublished drafts — which is the recommended way to test changes before publishing.

## Running a specific version via API

`agentExecutePost` accepts an optional `version` field in the request body. Pass a version number to run that exact version — published or not — for example to smoke-test a draft programmatically before publishing it. When omitted, the latest published version is used.

## Publishing

Publishing promotes a version to be the default used by API, schedule, and integration triggers (schedules pinned to a specific version keep it):

* In the **Builder**, click **Publish** once you're happy with the draft.
* Programmatically, use the `workflowPublish` MCP tool or the corresponding API endpoint.

Already-running executions are never affected by publishing — each execution keeps the version it started with.

## Version history

The Builder shows the agent's version lineage and which version is currently published. Any version that has been published or executed is kept permanently, so you can always inspect exactly which instructions a past execution ran; only unpublished drafts with no executions can be deleted.
