TASIP-009: Agent labels & grouping

[ryw]

Status: Draft — open for input · Category: Enhancement

Summary

Group the agents list and dashboards by label (sales, support, compliance) so a large agent footprint stays navigable, and use labels to scope things like which Slack app can launch which agents. Labels already exist on agents; this adds the group-by views.

Why

Past ~20 agents, a flat list stops working. Teams think in terms of function and ownership, and the UI should let them slice by that.

Sketch

• A group-by toggle on the agents inventory and dashboard, keyed on labels.
• Filters and saved views by label.
• Reuse labels for access/launch scoping where it helps.
  (Provisional — the shape changes based on the discussion.)

Open questions

• One label or many per group view?
• Should labels drive permissions, or stay purely organizational?
• Default grouping for a new workspace?

How to help

React 👍 if you want this, and comment with your use case, constraints, or pushback. This is a draft Tembo Agent Studio Improvement Proposal (TASIP); your input shapes it before it becomes scheduled work.

[kevine824-alt]

@ryw

Great addition especially as we land larger accounts. Carefeed is well past the flat-list point: some members own 20 to 40+ agents, and subagents sit in the same list as the agents people actually run.

A few thoughts:

• Namespaced labels would answer the "one or many" question. Something like team:cx, function:billing, type:subagent. Agents carry many labels, and a view groups by one namespace at a time.
• Treat subagents as shared components, not children of one agent. At Carefeed the same Outlook and HubSpot subagents serve several agents across teams, so nesting under one parent would hide them from everyone else. Give them their own group with a "used by" list of every agent that calls them. That also shows the reach of a change: editing a shared subagent changes every agent that calls it, so the owners of those agents should get a notice when it changes.
• A lifecycle label (draft, active, paused, retired) would make monthly governance reviews much easier, and give retired agents somewhere to live without being deleted. We keep old definitions on purpose because they record decisions.
• Label conventions matter as much as the feature. Our labels today are inconsistent across agents, so a suggested starter set for new workspaces would help more than a blank field.

On the open questions:

• One or many - many per agent, grouped by one namespace at a time.
• Permissions - keep labels organizational by default. Access to sensitive agents and their runs should come from connections and roles (the approach in the policy template discussion), since labels are easy to change and anyone who can relabel could grant access. Labels are fine for convenience scoping like which Slack app can launch which agents. If a label ever does drive access, changing it should need the same approval as any other change that expands reach.
• Default grouping - by team, with shared subagents in their own group showing who uses them.