Agent profiles and namespacing for user-level custom agents

[kabronkline]

Describe the feature or problem you'd like to solve

User-level Copilot custom agents in ~/.copilot/agents/ have two compounding issues at scale:

1. No namespacing. The .agent.md filename is the agent's identity and the key for dedupe across the documented scope chain (system > repository > organization). When multiple teams independently publish an agent named, e.g., code-reviewer.agent.md, installing more than one into ~/.copilot/agents/ causes overwrites on disk. There is no way to distinguish "Team A's code-reviewer" from "Team B's code-reviewer."

2. No user-level scoping. Every agent in ~/.copilot/agents/ is available in every copilot session regardless of the current repo or task. /agents and --agent name space become long and noisy, and subagent routing has more candidates to disambiguate than necessary. There is no per-session or per-context filter that scales beyond manually curating the directory.

Proposed solution

1. Namespacing. Add a namespace (or publisher) field to the agent YAML frontmatter, producing qualified identifiers like teamA/code-reviewer. The namespace participates in identity, dedupe, invocation (copilot --agent teamA/code-reviewer), and display. Unqualified names still work for back-compat but emit a warning on collision.

2. Agent profiles. Named profiles (e.g., work-backend, personal) that specify which user-level agents are active. The active profile could be selected via slash command (/profile work-backend), CLI flag (copilot --profile work-backend), config.json under COPILOT_HOME, and optionally auto-selected based on CWD or repo. Only agents in the active profile appear in /agents, resolve via --agent, or participate in subagent routing. All installed agents remain on disk.
   Namespacing fixes identity; profiles fix relevance. Together they give organizations a practical path at scale.

Alternatives considered

1. Rename-on-install (e.g., teamA-code-reviewer.agent.md) — works today but is ad-hoc, breaks author-intended names, and has no tooling support.
2. Per-repo installs in .github/agents/ — requires copying into every repo and doesn't fit agents that are genuinely user-scoped.
3. Org-level agents — helpful for canonical agents but doesn't address intentional diversity across teams or personal use.

Example prompts or workflows

Additional context

Related FR issue for VSCode GitHub Copilot: microsoft/vscode#311920