The Role System — Architecture

The role is the unit of reuse; the orchestrators are just contexts a role runs in. One persona — say a senior debugger — can run several ways without being redefined: invoked solo for a quick pass, or seated into any of the three orchestrators (as a gated crew role inside a delivery relay, a panel lens in a brainstorming session, or a research verifier in a coverage sweep). Its identity lives in one place and its hard-won lessons accumulate there, regardless of which context produced them.

The roles plugin is the substrate — one role, one solo pass; the three orchestrators each compose a task-fit roster of those roles toward a different end:

roles is not an orchestrator — it is the substrate: the shared, evolving talent pool plus solo invocation (/roles:as). It’s the noun the three verbs operate on. Each orchestrator composes a task-fit roster of those roles, but they differ on every axis below.

Two properties tie them together:

Before this system, each orchestrator had exactly half of the right mechanism:

Worse, the same persona could live in both worlds with unconnected lessons — an art-historian role that learned one thing as a crew member and another as a panel seat, its knowledge split across two files that never talked. The role system gives both orchestrators both halves: dynamic formation and evolving roles, over one shared talent pool.

No surveyed public project has roles that accumulate experience across orchestration contexts. Large agent catalogs (VoltAgent’s 154, wshobson’s 192) are static libraries; dynamic-selection panels learn nothing between runs; the one pack that fuses prompts with a learning loop stores it in an opaque global database. Dynamic formation plus lane-scoped evolving roles, shared across solo / crew / panel as reviewable per-repo markdown, is — as of this writing — unique. See the full survey and rationale in the project’s decision record, docs/decisions/2026-06-12-ecosystem-review.md.