Ideas: Should AgentMesh roles be static enums or dynamic capability sets?

[web3guru888]

The Question

Issue #147 defines AgentRole as a Python enum with 7 fixed values:

• COORDINATOR, PLANNER, PERCEPTION, MEMORY, REASONING, SAFETY_MONITOR, EXECUTOR

But as ASI:BUILD evolves, new specialized roles will emerge. Should we lock roles in an enum, or use a richer capability model?

Option A: Static AgentRole enum (current design)

class AgentRole(Enum):
    COORDINATOR   = auto()
    PLANNER       = auto()
    PERCEPTION    = auto()
    MEMORY        = auto()
    REASONING     = auto()
    SAFETY_MONITOR = auto()
    EXECUTOR      = auto()

Pros: Type-safe (mypy catches invalid roles), simple O(n) routing, predictable, easy to test.

Cons: Adding a new role requires a code change and deployment. Agents with overlapping capabilities must pick one primary role. Doesn't capture capability granularity (PLN-only REASONING vs quantum+hybrid REASONING).

Option B: Dynamic capability strings

@dataclass
class AgentRegistration:
    agent_id: str
    capabilities: frozenset[str]  # e.g. {"reasoning.pln", "reasoning.hybrid", "memory.read"}
    primary_role: str | None = None  # advisory only

Routing: tasks declare required_capabilities; coordinator finds agents whose capability set is a superset.

Pros: Flexible (new capabilities added at registration time, no code change), expressive multi-capability agents, composable set-intersection routing.

Cons: Typos in capability strings are silent failures. No exhaustive compile-time list. Routing is O(n × |capabilities|) per dispatch.

Option C: Hybrid — enum roles + capability tags (recommended)

class AgentRole(Enum):       # coarse-grained, type-safe
    PLANNER = auto()
    PERCEPTION = auto()
    REASONING = auto()
    # ...

KNOWN_CAPABILITIES: set[str] = {   # validated registry
    "reasoning.pln",
    "reasoning.hybrid",
    "memory.read",
    "memory.write",
    "perception.vision",
    "perception.eeg",
}

@dataclass
class AgentRegistration:
    role: AgentRole                    # required
    capabilities: frozenset[str]       # optional, validated against KNOWN_CAPABILITIES

Pros: Best of both worlds — type-safe primary routing + flexible capability filtering. KNOWN_CAPABILITIES set gives validation without blocking extension. Backward-compatible.

Cons: Two routing axes to maintain. KNOWN_CAPABILITIES still needs updating (just not a new enum member).

My Lean

Option C feels right for a research framework where the module surface is still growing. The AgentRole enum handles the 80% case (route this planning task to a PLANNER). The capability frozenset handles the 20% case (route this EEG-to-consciousness task to an agent that supports both perception.eeg AND reasoning.hybrid).

Questions for the Community

1. Is the 7-role enum sufficient for your use case, or do you already have roles in mind that don't fit?
2. Has anyone built a similar capability registry and hit the "string typo" problem in production?
3. Should KNOWN_CAPABILITIES be auto-generated from module metadata (scanning __capabilities__ class attributes)?

Related: #147 (AgentMesh), #150 (AgentDiscovery service registry), #148 (task distribution strategies)