=====================

Current Behavior:

=====================

Workshop items (agents, workflows, apps, etc.) exist as flat, independent items with no built-in versioning or organizational hierarchy. There is no native way to track changes over time, roll back to a previous state, or create experimental branches of an item without duplicating it entirely.

When iteration or testing is needed, the only option is to manually create a copy of the item and give it a distinct name to differentiate it from the original. Over time, this results in a workshop cluttered with items like "Daily Briefing - New," "Daily Briefing - v2," "Daily Briefing - Teams Message," etc., with no clear relationship between them and no way to roll back or merge changes.

=====================

Desired Behavior:

=====================

Workshop items should support built-in versioning so that changes can be tracked, named, and rolled back to a prior state directly within the interface. Ideally, this would also include branching, the ability to create a separate variant of an item (e.g., for testing a different approach or a new feature) that is still tied to the original item rather than existing as a completely independent copy.

Additionally, folders or some other grouping/organizational mechanism should be available in the workshop so that items can be logically grouped without relying solely on naming conventions.

=====================

Use Case:

=====================

When iterating on a complex agent or workflow, it is common to want to test a significant change without losing the working version. Today that requires duplicating the item and managing the naming manually, which quickly makes the workshop hard to navigate.

With versioning, a user could make changes confidently knowing they can roll back if something breaks. With branching, they could develop and test an alternate version of an item (e.g., a Teams-specific variant of a Daily Briefing agent) while keeping it associated with the canonical item. With folder organization, related items — including any branches or archived versions — could be kept together rather than scattered across a flat list.

This is complementary to a separate feature request for exporting workshop items as code, and depending on how versioning and structure are implemented, the two features together could provide a fairly complete solution for managing workshop item lifecycle and organization.

A change log and version restore option within apps would make it easier to track updates and recover from unintended modifications. When adjustments are made to improve an app or troubleshoot behavior, it can be difficult to remember exactly what changed between versions. Having a clear record of edits each time the app is saved would give users the visibility they need to understand how the app has evolved.

A built-in option to revert to a previous version would also help when a recent change causes unexpected results. Users could roll back to a known working state or reference earlier prompts directly from the change log. This would reduce the time spent trying to manually recreate older logic and provide a more reliable workflow for testing and iterating on app designs.