Have separate Duo Agent Platform feature flags for SaaS and non-SaaS instances

Duo assisted rewrite of Jessie braindump

Currently, the ai_duo_agent_platform_ga_rollout feature flag controls when Duo Agent Platform features transition from beta to GA (generally available) across all SaaS. We are using this feature flag somewhat inconsistently and sometimes use it for all instances but it should really just be used for SaaS. SaaS and self-managed instances have different release schedules, making a single flag inflexible.

Problem

• SaaS (gitlab.com) rolls out changes on its own schedule
• Self-managed instances typically go GA at code cutoff (about a week before SaaS rollout)
• A single feature flag doesn't accommodate these different timelines

Proposed Solution

Create a second EE feature flag called ai_duo_agent_platform_ga_rollout_self_managed that:

• Defaults to disabled (like the existing SaaS flag)
• Controls GA rollout for self-managed and dedicated instances only
• If this feature flag is enabled, show the feature even if instance_level_ai_beta_features_enabled is false for the instance (we only care about this setting on non-SaaS instances, the namespace setting is SaaS specific)
• Allows independent GA timing for each instance type

Implementation

Throughout the codebase, check:

• ai_duo_agent_platform_ga_rollout for SaaS instances
• ai_duo_agent_platform_ga_rollout_self_managed for self-managed instances

Jessie braindump

Right now, we use a feature flag called ai_duo_agent_platform_ga_rollout that was created so that we can move various Duo Agent Platform feature and funtionality to the "GA" state. Moving to "GA" means on the backend that we make these features available to namespaces where experiment_features_enabled is set to false because once these features are "GA" (generally available) they are no longer considered experimental. On the frontend, moving to "GA" often means removing labeling that indicates a feature is a beta feature.

The intention of this feature flag was to be used for SaaS (gitlab.com) only because we will always roll out changes to gitlab.com and other instances at different times. For all other instances, we want to make features "GA" at the time of a code cut-off, which is usually a week before we would want to roll out to gitab.com. So, the feature flag specifically for SaaS gives us the flexibility to roll out later. For other instances, we can roll out GA "immediately" when the release is cut.

There has been a lot of back and forth on the timing of GA. The approach so far has been to just move them to GA. To make it easier to "turn on" GA for self-managed, I propose creating a new feature flag called ai_duo_agent_platform_ga_rollout_self_managed that we use only for non-SaaS instances. This feature flag will be an EE feature flag and default disabled just like ai_duo_agent_platform_ga_rollout. But, throghout the codebase, we check ai_duo_agent_platform_ga_rollout_self_managed for self-managed instances and ai_duo_agent_platform_ga_rollout for gitlab.com. If the feature flag for that instance is rolled out, the feature is generally available (GA). If it is not rolled out, the feature remains in the beta state.

This should be applied to Duo Agent Platform features that are current beta only. To see which ones those are, look for existing references to ai_duo_agent_platform_ga_rollout