Prepping the AI Catalog Versioning Demo

TL;DR

• Drafted a checklist for the demo: keep it under 5 minutes, structure it, call out to people, and pre-set items/steps/fullscreen/Zoom sharing beforehand
• Wrote the opening script introducing myself (Agent 7915, frontend dev on Workflow Catalog AI) and the problem: agents/flows used to update silently with no versioning or approval, which AppSec flagged
• Outlined the two-part fix: immutable, auditable versions of catalog items plus a group-level approval process for accountability
• Listed future improvements to mention: streamlined enablement, auto-updates, draft version states, user-driven semver, version ranges, and better pinned-flow support
• Wrote out detailed step-by-step pre-requisite/test flow showing how versions behave across explore, project, and group namespaces

Demo Prep Checklist

• structure of demo
• under 5 minutes
• call out to people
• setup my demo before demo
  • items created
  • steps defined
  • fullscreen
  • can share in Zoom
• presentation/diagram

Demo Script

Start with just me view. Hi everyone, I’m Agent 7915, a frontend developer on the Workflow Catalog AI team. Today I’m demonstrating how agents and flows become enabled and versioned in our AI Catalog.

Scenario: you find a helpful AI agent in the catalog and start using it in your project. It’s working wonderfully, but what if the creator of the agent changes it without telling you? During the experimental phase of the Catalog, there was no version tracking, so changes happened off the end-user’s radar and updates applied automatically with no approval. An agent trusted one day could turn malicious overnight, with no way to audit changes or even know something had changed. Whether malicious or accidental, anyone could modify an agent’s or flow’s instructions and immediately affect every project using them.

AppSec flagged this, so we needed two solutions: first, an immutable version of the catalog item that couldn’t change overnight and could be audited; second, accountability via an approval process that gives accountable people control over what can run in their projects.

Demo flow to show: create an agent, edit the agent, enable the agent for the group, enable the agent for the project. Maintainers can choose to update to newer versions independently of the group as new versions become available, but it’s never automatic, by design. Show editing the agent in-place, then updating it. A more polished rollback feature may come later, but for now disabling and re-enabling accomplishes this—disabling soft-deletes the associated ‘item consumer’ without touching the original Catalog item. Demonstrate disabling the agent, noting the version, then re-enabling it.

Future plans to mention: streamline enablement so users don’t need to jump to the Catalog area within the project; explore automatic updates in the project that created the item so items stay up-to-date (removing demo steps, since step-removal is preferred over step-accrual); support draft version states so people can iterate before releasing; support full user-driven semantic version management (major/minor/patch); explore version ranges (e.g., pin to ‘anything under 2.x.x’ for automatic minor/patch updates without exceeding a major version); and work toward more nuanced support for pinned flow versions, which gets tricky when a flow wants to always use a specific agent version but that agent is set to auto-update in the project.

Pre-requisite / Walkthrough Steps

Pre-requisite: In the explore namespace, create a new agent or flow without enabling it anywhere. New items start at v1.0.0. Make an edit—each edit (tools, prompts, flow definitions) automatically bumps the minor version (e.g., 1.1.0, 1.2.0); users don’t control the version number directly, by design (for now).

Project namespace, not enabled anywhere: Navigate to the project namespace managing the item, click ‘Managed’, select the item, and confirm it shows v1.1.0 (latest version).

Group namespace, enabled at group level: We have a two-level approval process. Top-level group owners must approve an agent or flow before it can be used anywhere in their group. Approving creates an ‘Item Consumer’ entity connecting the group and the catalog item, pinned to the item’s current version. Enable the item in the group from Explore, then check the group namespace item list—it shows v1.1.0, the version the group is now pinned to. Bump the item to v1.2.0 via Explore or the Managed tab, then check the group namespace again—it still shows v1.1.0, confirming the group-level pinned version displays correctly.

Project namespace, enabled at group level: Once approved at the group level, project maintainers can enable it for individual projects, inheriting the group’s pinned version. Checking the item from the project’s Managed tab should show v1.1.0 (group pin), not the latest v1.2.0. Rationale: showing the latest version and then having it change upon project-level enablement would be confusing; this reduces unpredictable changes at the moment of enabling.

Project namespace, enabled at project level: Enable the item within the project itself, pinning the project version to match the group. This is the workflow that ensures accountable people control what version can be enabled by project maintainers. Edit the item to bump it to v1.3.0 and update it via the info alert on the show page. The item should now correctly show v1.3.0 (project pin, latest version). For comparison, the group namespace still shows v1.1.0 (group pin), and the explore namespace shows v1.3.0 (latest version).