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
- Save as new version. It gets the next number, for example v4, while v3 stays current.
- Test it. In the console, pick v4 in the version selector and use the test panel. From the API, run it explicitly:
- Promote it. Console: Versions → Promote on v4. API:
- 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.