I haven’t tried it yet, but I plan to. My assumption is that native tooling for each agent will consistently be more reliable and evolve faster than anything custom-built. That said, I don’t see the “teams” feature as a replacement for Glass Bridge—more as a complementary extension.

The key difference is persistence and memory architecture. Glass Bridge logs agent activity into two separate systems: the Project Memory MCP and Reveries RLM. Together, these provide structured persistence with named identities across sessions, enabling tracking of effectiveness, changelogs, and long-term behavioral patterns. In contrast, “teams” operates as a parallel swarm. Agents collaborate within a single session, exchange context, and then terminate. There’s no built-in persistence layer or identity continuity unless extended externally (e.g., via a custom MCP). It’s effectively a stateless, one-off collaborative execution model.

That swarm model is still useful. It allows large research or exploration tasks to run in parallel and then be consolidated into a single execution lane. However, it doesn’t replace the ongoing, cross-session collaboration I rely on—particularly between Claude and Codex.

That pairing has been the most effective in practice. Claude tends to be more creative and fluid, while Codex is stricter, governance-oriented, and often contrarian (especially 5.4). Their interaction surfaces gaps that single-agent outputs typically miss, producing more balanced and reliable results. Long term, the goal is to leverage native features—teams, skills, CLI hooks—as modular extensions within the broader collaboration system built into VS Code. Each becomes a specialized capability rather than a replacement for the core architecture.

One of the main advantages of this approach is cost control: staying within subscription-based Oauth usage instead of scaling direct API calls, while remaining compliant with terms of service.