Skip to main content
Agents and workflows keep a history of versions. Exactly one version is current; runs use it unless they ask for another. This lets you change a live agent or workflow without disturbing the runs that depend on it.

The two ways to save a change

Saving a new version does not make it current. If your change seems to have no effect, check the Current badge: the new version probably still needs to be promoted.

A safe change, step by step

  1. Save as new version. It gets the next number, for example v4, while v3 stays current.
  2. Test it. In the console, pick v4 in the version selector and use the test panel. From the API, run it explicitly:
  3. Promote it. Console: Versions → Promote on v4. API:
  4. Roll back if needed by promoting v3 again. Old versions are kept until you delete them.

In the console

On an agent or workflow page:
  • the version selector (v3 (current)) chooses which version you view and test;
  • Current: vN shows which version runs use;
  • Versions lists every version with View, Promote and Delete. The current version cannot be promoted or deleted.

API

The same routes exist for agents (/floware/v1/agent-management/agents/<id>) and workflows (/floware/v1/workflow-management/workflows/<id>):

Versions and references

  • A workflow that references an agent or a sub-workflow without a version (support/triage) uses that agent’s current version at run time, so promoting the agent changes the workflow’s behaviour too.
  • Pin a reference with @<n> (support/triage@3) when a workflow must not change until you decide.
  • Functions are not versioned: updating one changes every workflow that uses it immediately.

Keeping versions in git

Treat the YAML in the app as a deployment target, not the source of truth: keep agents, workflows and functions in git, and deploy them with a script that saves a new version and promotes it. See Deploying from git.