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

# Deploying & versioning

> How deploys create versions, how the knowledge base stays fixed, and how in-flight runs stay stable.

Agents use numbered deploy snapshots, giving you an auditable history of deployed configurations. Deploying is how a runtime configuration becomes a version; name and status edits do not create versions.

## How versions work

<Steps>
  <Step title="Create the agent">
    Creating an agent is its **first deploy** — version 1. From that point on it can be run interactively, called through the API, or scheduled.
  </Step>

  <Step title="Edit and deploy again">
    Change the configuration and deploy again, and the version number increments. Each deploy is a new, distinct version with its own settings.
  </Step>

  <Step title="Update without a new version">
    You can update just the **name** or **status** without creating a new version — handy for relabeling or pausing an agent without touching its configuration.
  </Step>
</Steps>

<Note>
  Versions provide history, but the current API does not expose rollback or selection of an older version. To restore an earlier configuration, deploy that configuration again as a new version.
</Note>

<Info>
  Deploys are **validated up front** — connected apps must be reachable, the schedule must be valid, and any delegates must be attachable. If validation doesn't pass, the deploy doesn't go through and your previous version stays exactly as it was.
</Info>

## The knowledge base is fixed at creation

An agent's knowledge base is chosen when you create it and stays fixed for the life of that agent. This keeps every version of the agent grounded in the same source of truth, so results stay comparable across deploys.

To build on a **different** knowledge base, use **Copy (fork)**:

<Steps>
  <Step title="Copy the agent">
    Forking creates a brand-new agent from the current configuration.
  </Step>

  <Step title="Choose a knowledge base">
    The copy can start on a new knowledge base of your choice.
  </Step>

  <Step title="Review the copied schedule">
    Any schedule is copied as a **disabled draft**, so the new agent never fires unexpectedly. Enable it when you're ready.
  </Step>
</Steps>

<Tip>
  Copy (fork) is also the clean way to experiment: branch an agent, iterate on the copy, and leave the original untouched.
</Tip>

## In-flight runs stay stable

Versioning is designed so that improving an agent never disrupts work already underway:

* A **running conversation stays pinned** to the agent version it started on, so in-flight work finishes with the settings it began with.
* **New runs use the latest version**, so improvements take effect the next time the agent is started.
* **Skills and callable agents always resolve to their latest version** at run time, so shared building blocks stay current everywhere they're used.

## Archiving

Archiving an agent takes it out of active use while keeping its history intact:

* Its **schedule is disabled**, so no further background runs fire.
* Its **run history is kept**, so you can still open and review past runs.

<Note>
  Archiving keeps the agent record and its runs. If a delegate you call becomes archived, calling agents receive a graceful message and continue. See [Delegation](/agents/delegation).
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Schedule the agent" icon="clock" href="/agents/scheduling">
    Set a cadence for automatic background runs.
  </Card>

  <Card title="Run it and review history" icon="list-check" href="/agents/running">
    Start runs and open the chats they produce.
  </Card>
</CardGroup>