Skip to main content
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

1

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

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

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

​
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):
1

Copy the agent

Forking creates a brand-new agent from the current configuration.
2

Choose a knowledge base

The copy can start on a new knowledge base of your choice.
3

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.
Copy (fork) is also the clean way to experiment: branch an agent, iterate on the copy, and leave the original untouched.

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

​
Next steps

Schedule the agent

Set a cadence for automatic background runs.

Run it and review history

Start runs and open the chats they produce.