Versions
Every tool, agent, and manager on Autessa is versioned. You iterate freely in a draft sandbox, publish a snapshot when it's ready, and roll back instantly if a release misbehaves — so nothing you're experimenting with ever reaches a customer by accident.
What it's for
LLM workflows have nondeterminism baked in, and model or prompt changes can shift behavior in ways you only discover in production. Versioning gives you deterministic control over what your end customers actually run:
- Safe iteration — everything you do in the sandbox never impacts a customer until you hit publish.
- Deterministic releases — a published version is an immutable snapshot; it doesn't change when you keep editing the draft.
- Instant rollback — if a published version doesn't work so great in production, point the published pointer back at a previous release and the change takes effect immediately.
Navigating here
Versioning isn't a separate page — it lives on each resource's detail page. Open any tool (Agentic Workflows → Tools), agent (Agentic Workflows → Agents), or multi-agent (Agentic Workflows → Multi-Agents) and you'll find the version selector and publish controls on its detail view.
Key concepts
Draft (sandbox) vs published
Each resource has one draft version — the sandbox where all your edits land — and zero or more published versions, which are numbered, immutable snapshots. API consumers and end customers get the currently published version by default; the draft is only visible to builders testing in the platform.
The lifecycle looks like this:
| Action | Draft (sandbox) | Published (what customers get) |
|---|---|---|
| Create resource | v1 draft | — (nothing published yet) |
| Edit and save | v1 draft changes | — |
| Publish | new draft opens (v2) | v1 |
| Edit and save | v2 draft changes | v1 (unaffected) |
| Publish | new draft opens (v3) | v2 |
| Rollback to v1 | v3 draft (unaffected) | v1 |
| Publish | new draft opens (v4) | v3 |
Two things to notice: publishing freezes the current draft as the next numbered version and opens a fresh draft on top of it, and rolling back only moves the published pointer — your in-progress draft keeps its edits, so you can continue development and publish it when it's ready.
A rollback never deletes versions. Every published version stays browsable, so you can compare releases and re-publish forward again at any time.
Access levels
Resources are shared with per-user access levels: READ, WRITE, PUBLISH, and ADMIN. Anyone with WRITE can edit the draft, but publishing or rolling back requires PUBLISH or ADMIN access on that resource. This lets a team iterate on drafts while a smaller group controls what ships.
How to publish a version
- Open the resource's detail page and make sure the draft is saved.
- Test the draft — drafts are fully testable without affecting the published version.
- Click Publish. The draft is frozen as the next version number and becomes the published version customers receive.
- Keep editing — your changes now accumulate in a fresh draft.
How to roll back
- On the resource's detail page, open the version list to see all previously published versions.
- Browse a prior version to review its configuration and confirm it's the one you want.
- Choose to roll back the published version to it. The change takes effect immediately for all consumers.
- Fix the problem in your draft at your own pace, then publish again when ready.
Versioning over the API
Everything above is also scriptable. Publishing, rollback, and version listing live in the Poweruser API for each resource type — see Agents, Tools, and Multi-Agents — so you can wire releases into your own CI or admin tooling.