Introduce Agent Versioning and lifecycle management

Agent Studio’s canvas is where an AI builder assembles an agentic workflow. For eg, a Clinical Research Associate (CRA) responsible for monitoring a set of trials can build an agent, connect it to their organisation’s data sources, and put it to work without involving engineering.

Currently, editing an agent simply overwrote it and the changes went live immediately. As a result, there was no way to implement any governance which allowed customers to validate the changes before releasing it.

This was blocking implementation of agent studio at big pharma companies and CROs.

Before diving into ideation, I studied an existing pattern for status change in

Study Studio (another product in the Medable platform) to see if I can use it in the context of agents. I found it inadequate for agents because…

1. More UI manoeuvring: A builder will receive updates on dependencies frequently. To change the status first, and then accept the new update would be intrusive UX.
2. Misleading Mental modal: Changing status from published to draft doesn’t unpublish the agent (unlike the study, which becomes unavailable). For agents, changing state to draft is expected to create an identical version of the agent which user can modify, while the previous version stays published and available for use simultaneously.

I began by mapping how versioning will change the existing workflow for AI builders based on my product knowledge of agent studio.

After versioning, whenever a dependency is modified, the agent using it receives an update. I arrived at the following requirements for them.

1. They should be able to view it
2. They should be able to accept it only if they want to
3. In case the update is mandatory, they shouldn’t be able to update the agent without accepting it
4. They should be able to rollback to a previous agent version

While ideating how to visualise agent’s lifecycle, I realised the version number is not important. The version can be v237. Therefore, user’s mental model should be anchored in canvas state so that it’s clear which actions are allowed.

Therefore, the experience of versioning boils down to helping the user:

1. identify which state they are in currently, and as a result what they can do
2. clearly show when the state has changed
3. understand they have to republish for changes to take effect

The dependency card was already crucial for editing the configuration of a dependency. Now versioning was adding another layer of complexity.

To keep it simple, I began with a simple Y/N affordance to accept of dismiss updates (iteration 1). But on viewing it with the user lens, it fell short because it didn’t…

1. give any info to decide whether the new update was important
2. afford editing while it was also showing an update
3. accommodate multiple files under each dependency type

These points became the requirements for the 2nd iteration. But now the component felt too busy. So for iteration 3, I took out the current version thinking it didn’t add any value.

But on user testing iteration 3 with internal users, I learnt that they confused the version number shown to be the existing version, not the new version. This was rectified in the final iteration, which handled all requirements and scaled to all dependency types.

Mandatory updates are crucial for security, and made by workspace admins, hence builders have to accept it.

The key UX driver here was when to bring the mandatory updates up and doing it without being intrusive. If the user doesn’t accept them on the canvas, instead of highlighting it, the more thoughtful way to enforce it would be to bring them up at the point of publish so that the user can accept them all in one shot.

I also debated whether mandatory updates should be highlighted on the canvas, exploring various layouts like accordions and grids to list them. Finally, I decided the optimal UX was to accept all mandatory updates in one go at the time of publish. A carousel works best because it does not force the user to see all the updates, yet does not prevent them to go through them if they want — progressive disclosure.

Regarding versions, I knew the list could grow long, that’s why I opted to navigate user to a modal, where I can show large numbers of versions.

The meta data on version card was decided based on what users want to know—when was the version created and by whom.

At first, I decided not to put the “published” tag assuming it would be obvious that the version on top of the pile is the published, but during stakeholder discussion, I realised the topmost version could be draft.

The content of each version was arranged in tabs for the following reasons:

1. make it easy for users (likely auditor or builder) to find what they are looking for
2. to avoid long scroll

I wanted to convey important information to the user about updates and state changes on the canvas in a subtle way without demanding too much cognition from them. I achieved this using…

1. accent border to visually differentiate nodes with updates, making it easier to scan for updates.
2. a floating tab to convey total updates and accept all updates in one go.
3. a banner moving at the top when canvas changes to draft, clearly giving feedback of state change.

Engineering assessed the complete design (including the side panels) would take longer than the release deadline. Instead of pushing the dates, I was asked for a middle ground.

They agreed the side panel was better UX, but because it involved new components, implementing it within the deadline wasn’t possible.

So I cut the settings side panel designed to fix consistency issues because it wasn’t crucial to versioning. Consequently, I had to redesign the dependency card again to fit it to the inconsistent modal design.

Post launch feedback revealed the version cards were breaking in production because double-digit version numbers were bleeding out of their borders. Even the draft tag looked too cramped.

I didn’t involve devs because this was a purely frontend change. I opened a branch in cursor, tried a few iterations directly in code, finalised one and raised a merge request in under an hour.