Done

No bulk delete for teams: 1,100+ disposable teams, and each MCP teams_delete takes ~18 minutes

From AzyraDone 2 weeks ago

We need a way to delete many teams at once.

Our project reached 1,161 project teams in about two weeks. The only ways to delete them are the Teams panel (Configure > Delete) and the teams_delete MCP tool, one team at a time. Every save re-uploads the whole team list (about 10.4 MB for us). One teams_delete call ran for over 15 minutes, and the delete reached the app about 18 minutes after the call. Deleting by hand in the Teams panel goes faster, but it is still one team at a time, for about 900 teams.

How we got here. This may not be how teams were meant to be used, but it was an honest path:

We run many agents on one project. At first we handed work between agents by mail. A check mailed to a busy agent never ran and went unnoticed for about 11 hours: the agent hit its usage cap, and nothing tracked the request. Long threads also hit the mail limits (12 sends per 10 minutes, and a cap per pair of agents per subject).
So every build, check and review became a team run: tracked, with handoffs and a check gate.
Each task got its own small team (build, check, blind review), with that task's full brief in the step instructions (about 9 KB per team, up to 28 KB).
Editing an existing team sometimes ran the old copy, so we made a NEW team for every change or restart instead.
To us these teams were disposable, but nothing disposes of them. We made 80 to 200 a day, and the list reached the server's ~10 MiB limit: creating a team now fails with "INVALID_JSON" (ticket 525429e2).

Meanwhile we are deleting teams by hand and creating no new ones. If there is a better pattern for one-off agent pipelines, we would welcome the guidance.

AgentsRoom diagnostics

App version: 1.195.1
OS: linux 6.18.33.2-microsoft-standard-WSL2 (x64)
Agent CLI: claude
App language: system

Problem to solve

Teams can only be deleted one at a time. Each delete re-uploads the whole project team list, so on a large list every delete is slow (one MCP teams_delete took about 18 minutes to land), and clearing hundreds of unused teams is impractical. Nothing shows the list's size until saves start failing at the server's ~10 MiB limit.

Proposed behavior

Multi-select delete in the Teams panel, and teams_delete accepting a list of ids, saved in one upload. 2) Filters to find dead teams: last run date, never run, created by an agent, older than N days. 3) A run-once or archived team that does not grow the team list, or removes itself after its run is finished. 4) Show the list's team count and size, and warn before the limit. 5) Save or delete one team on the server instead of re-uploading the whole list.

Who benefits

Anyone who drives AgentsRoom with agents over MCP: coordinators that create a team per task, and large projects that run many team pipelines a day.

Acceptance criteria

We can clear about 900 unused teams in minutes instead of days, the list stays far below the server limit, and creating teams works again.

Replies

The team2 weeks ago

Thank you for this report and for explaining how you got there, it made every point easy to act on.

Already fixed in 1.198.0 (you are on 1.195.1, so updating helps right away):

Teams are saved and deleted one at a time on the server. A save or a delete no longer re-uploads the whole list, so the very slow teams_delete and the INVALID_JSON error on create are gone.
A run always starts from the latest saved version of its team. Editing a team no longer runs an old copy, so you can edit and reuse a team instead of creating a new one.
A list that is really too large is refused with a clear message instead of INVALID_JSON.

Coming in the next update, covering the rest of your proposal:

Bulk delete. In the Teams panel: Configure > Select > Select all > Delete, any number of teams in one request. Over MCP, teams_delete accepts teamIds (up to 5,000 per call, sent in one request). Ids that match no team come back in notFound. If one of the teams has a live run, the whole call is refused and nothing is deleted.
Filters to find dead teams, in the Configure tab: Last run (never run, or not in the last 1, 7, 30 or 90 days), Created (more than 1, 7, 30 or 90 days ago) and Created by an agent. Select all then picks exactly what the filters leave, and each team shows when it was created and when it last ran. Over MCP: teams_list({ neverRun: true, olderThanDays: 1, idsOnly: true }), also notRunForDays, createdByAgent and scope, then teams_delete({ teamIds }). Last run dates are filled in from the run history of the machine that ran the teams. "Created by an agent" only applies to teams created after the update.
One-off teams: a "Delete this team after its run" option in the team settings, or teams_save({ runOnce: true }). The team deletes itself once its run is finished or cancelled. A blocked run keeps it, so the run can still be resumed.
The Configure tab shows the team count and the size of the list against the 14 MB limit, with a warning from 80%. teams_list returns projectList, and teams_save and teams_delete add a warning past 80%.
Single-team saves and deletes on the server shipped in 1.198.0 (see above). An open Teams panel now also refreshes as soon as an agent saves or deletes teams over MCP.

About one-off pipelines: rather than a new team per task, keep one team per kind of pipeline (for you: build, check, blind review) with general step instructions, and put each task's brief in the backlog ticket that starts the run (backlog_create with teamId, then backlog_start_next). The first step receives the ticket, the run is tracked like any team run, and it always uses the latest saved team. When a task really needs its own graph, create it with runOnce: true. capabilities_get({ topic: "teams" }) now describes this under "teamList", so a coordinator agent can read it before creating teams.

To clear your current list after updating: Configure > Last run > Never run (add Created > More than 1 day ago to keep today's teams) > Select > Select all > Delete.

The team2 weeks ago

Thanks: the bug is fixed and the fix ships in the next release. If it still happens after that, tell us and we will gladly take another look.