---
title: "Feature Flag Cleanup Workflow With AI Agents | Kylon"
description: "How an engineering team runs a quarterly feature flag cleanup with weekly removal caps, compliance holds, telemetry corrections and incident freezes in one Kylon room."
url: "https://kylon.io/use-cases/feature-flag-cleanup"
language: "en"
---

[HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Feature Flag Cleanup: Stale Flags Removed at a Pace the Team Can Ship

Use Case8 min read

# Feature Flag Cleanup: Stale Flags Removed at a Pace the Team Can Ship

Flags are dispositioned under the governance rules with evidence from code, tickets, deployments and the compliance registry, removals fill each week up to the cap, and objections, telemetry fixes and incidents re-queue only what they touch.

[Get started](https://app.kylon.io/sign-up)

Kylon TeamProduct

November 6, 2026

## Flags that outlive the launch they were made for

A feature flag is cheap to add and slow to remove. The quarterly cleanup applies the governance rules: a flag fully on in production for a quarter with no recent changes is removed, an operational kill switch is kept, a flag in the compliance registry is held until compliance signs off, and a flag with no owner goes to the engineering manager. Removals are capped per week, because each one is a code change that ships.

The evidence is spread thin. Flag references and their history are in GitHub, each flag's lifecycle ticket is in ClickUp, Vercel deployments show what is actually live in production, and the compliance registry is a Notion database. The cleanup report is a Google Drive document someone writes by hand, and it is out of date the moment an owner objects or an incident freezes the service a removal was about to touch.

## Who works in the room

People

-   Engineering manager running the cleanup
    
    Owns the governance rules and the weekly cap, and approves every disposition and the week's removals
    
-   Flag owners
    
    Confirm a flag is done, object when it still gates something, and merge the removal pull requests
    
-   Compliance partner
    
    Owns the registry of flags kept for compliance reasons and signs off when one can go
    
-   Incident commander
    
    Freezes a service during an incident and lifts the freeze afterwards
    

Agents

-   NovaFlag dispositions
    
    Dispositions every flag on the list from GitHub references, ClickUp tickets, Vercel deployments and the Notion compliance registry, and re-runs flags when the evidence changes
    
    GitHubClickUpVercel[Notion](https://kylon.io/integrations/notion)
    
-   RyanRemoval queue
    
    Fills each week with cleared removals up to the cap, audits the cleanup report and pulls removals back when an incident freezes a service
    
    ClickUpGoogle Drive
    
-   AdaOwner notices
    
    Drafts notes and replies to flag owners for a person to send, and posts the week's list in Slack after approval
    
    [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack)
    

The cleanup gets its own Kylon room for the quarter. Nova is the default agent and owns dispositions, Ryan owns the weekly queue and the report audit, and Ada drafts every message to an owner, as the room guidelines set out. The queue itself is a Kylon App, a board the team and the agents both read and write, because no single connected tool holds it, and every Monday an automation opens the new week from the top of it. Engineers who use a coding agent such as Claude Code can add it to the room and ask it to write the removal pull request for a cleared flag; the owner still reviews and merges every one.

## One cleanup week, flag by flag

The quarter runs as weekly batches. Each batch follows the same stages, and nothing merges or changes a ticket until a person approves.

```mermaid
flowchart TD
  disp["<b>Nova</b> proposes remove, keep, hold<br>or owner review for every flag"]
  ok1["<b>Engineering manager</b><br>approves the dispositions"]
  week["<b>Ryan</b> fills the week with cleared<br>removals up to the cap"]
  ok2["<b>Engineering manager</b><br>approves the week's list"]
  audit["<b>Ryan</b> audits the cleanup report<br>against the queue"]
  obj["<b>Nova</b> re-runs the flag an<br>objection or sign-off names"]
  tele["<b>Nova</b> re-runs flags on<br>corrected telemetry"]
  freeze["<b>Ryan</b> pulls removals that<br>touch a frozen service"]
  reply["<b>Ada</b> drafts the<br>owner reply"]
  rebuild["<b>Ryan</b> rebuilds the week's<br>list from the queue"]
  lift["<b>Incident commander</b><br>lifts the freeze"]
  merge["<b>Flag owners</b> merge the<br>removal pull requests"]
  close["<b>Ryan</b> totals removed, kept,<br>held and queued flags"]
  sign["<b>Engineering manager</b> signs off"]
  disp --> ok1 --> week --> ok2 --> audit
  audit --> obj & tele & freeze
  obj --> reply
  tele --> rebuild
  freeze --> lift
  reply & rebuild & lift --> merge --> close --> sign
  class disp,week,audit,obj,tele,freeze,reply,rebuild,close agent
  class ok1,ok2,lift,merge,sign person
  classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712
  classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712
  classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42
```

| Stage | What happens | Who acts | Who decides |
| --- | --- | --- | --- |
| Dispositions | Every flag on the list gets remove, keep, hold or owner review, with the evidence behind it | Nova, from GitHub, ClickUp, Vercel and the Notion registry | The engineering manager approves the dispositions |
| Weekly allocation | Cleared removals fill the week up to the cap in age order, and the rest stay queued | Ryan | The engineering manager approves the week's list |
| Report audit | The cleanup report is compared, line for line, with the approved dispositions and the queue | Ryan | The report author corrects it and the manager confirms |
| Objection or sign-off | An owner's objection or a compliance sign-off re-runs only that flag | Nova, then Ada for the owner reply | The manager decides objections and compliance signs off holds |
| Telemetry correction | Corrected flag telemetry can turn a remove back into a keep, and the week's list is rebuilt from the queue | Nova, then Ryan | The engineering manager approves the reversals |
| Incident | Removals that touch the frozen service leave the week and go back to the front of the queue | Ryan | The incident commander lifts the freeze |
| Closeout | Totals for removed, kept, held and queued flags, with each queued flag carried into next quarter | Ryan, then Ada for the owner summaries | The engineering manager signs off |

Stages of a quarterly flag cleanup. Flag names, counts and the weekly cap in this example are illustrative.

## An objection, a telemetry fix and an incident in one week

Corrections arrive out of order. An owner objects in Slack that a flag still gates a partner integration, and compliance signs off on two registry flags. Then the data team reissues flag telemetry, and a flag that looked fully on still serves the off path to a slice of traffic, so a removal cleared on Monday becomes a keep. Nova re-runs only the flags each change touches and notes the reason on each card, and Ryan rebuilds the week's list from the queue so the cap still holds.

An incident outranks everything. When the incident commander freezes the payments service mid-week, Ryan pulls every removal that touches it out of the week, including ones already cleared but not yet merged, and puts them back at the front of the queue. Removals on other services keep their place. The thread shows which removal moved and on whose instruction, and nothing comes back until the freeze is lifted.

## What the checks catch

-   A ninth removal in a week capped at eight, which waits in the queue however keen its owner is
-   A flag in the Notion compliance registry that looks safe to remove from GitHub and Vercel alone
-   A removal reversed by corrected telemetry that is still sitting in the week's list
-   A removal that touches a frozen service and was cleared before the incident began

## What stays with people

-   Approving each disposition and the week's removal list before anything changes in ClickUp
-   Reviewing and merging every removal pull request, whoever or whatever wrote it
-   Signing off a registry flag, which stays with compliance
-   Sending each note to a flag owner; Ada writes the Gmail draft and a person sends it

## Integrations in this workflow

Kylon is not a feature flag service and it does not replace one. It draws on the code host, the tracker, the hosting platform and the registry the team already uses, and holds the cleanup together across all four.

-   ClickUp
    
-   GitHub
    
-   [Gmail](https://kylon.io/integrations/gmail)
-   Google Drive
    
-   [Notion](https://kylon.io/integrations/notion)
-   [Slack](https://kylon.io/integrations/slack)
-   Vercel
    

-   **GitHub** holds the flag references, their history and the removal pull requests
-   **ClickUp** carries each flag's lifecycle ticket, updated after the manager approves
-   **Vercel** shows which deployments are live in production and when each one changed
-   **Notion** holds the compliance registry that can hold a removal
-   **Google Drive** keeps the governance rules, the cap and the cleanup report
-   **Gmail** sends notes to flag owners after a person sends Ada's draft
-   **Slack** is where owners object and where incident freezes are announced

## Where to start

Try it on one service's flags for one quarter. Connect the repository and the ClickUp list where flag tickets live, give Nova read access to the Notion registry, and state one rule in the room guidelines: no agent overrides the weekly cap or the compliance registry, and every removal waits for an engineer to merge it.

> “An incident used to mean rebuilding the cleanup list by hand. Now the frozen service's removals step back and the rest of the week carries on.”

## Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.

Set-up prompt

Set up our feature flag cleanup desk in this Room. Take it one step at a time and wait for my OK before you move on.

1. Connect ClickUp, GitHub, Gmail, Google Drive, Notion, Slack and Vercel. Tell me which ones still need connecting.
2. Ask me who works this desk: the engineering manager who owns the governance rules and the weekly cap, the flag owners who confirm flags and merge removal pull requests, the compliance partner who signs off registry flags, and the incident commander who freezes and lifts services. Help me invite them to this Room.
3. Build a Flag Cleanup App with columns Queued, Cleared, Removal PR and Removed, one card per flag. Pull the flag list from GitHub, ClickUp and Vercel and fill each card with what those tools show.
4. Disposition every flag as remove, keep, hold or owner review, drawing on GitHub references, ClickUp tickets, Vercel deployments and the Notion compliance registry. Show me the evidence behind each one and surface anything that conflicts.
5. Draft Gmail notes to flag owners for a person to send, and queue the week's Slack list for approval before it posts. Write back to ClickUp only after the engineering manager approves the dispositions and the week's removal list.
6. Write our rules, the weekly cap and who approves which step into this Room's guideline so every batch follows the same order.
7. After one clean week, offer to turn the queue fill into an Automation.

Before you start, ask me for our rules one at a time.

[Get started](https://app.kylon.io/sign-up)

Your first company harness. Where humans and agents run your business together.

[Get started](https://app.kylon.io/sign-up)

## More Use Cases

[View all](https://kylon.io/use-cases)

[

### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move

Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice.

Software & SaaSEngineering operationsEmail operations

](https://kylon.io/use-cases/api-deprecation-migration)[

### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval

A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes.

Software & SaaSIT & security operations

](https://kylon.io/use-cases/backup-restore-verification)
