Skip to content

Assync Role Pool

Purpose

A role is a permanent, provider-neutral job description — a stable identity an agent run is assigned to, never a description of which AI product performed the work. "Security Engineer" is a role. "Claude Security Engineer" is a run assignment (role + adapter), and the latter is never encoded into role identity (src/assync/roles/models.py, builtin.yaml).

Structure

The built-in role pool (src/assync/roles/builtin.yaml, loaded by roles/registry.py) defines 27 executable roles across five categories, plus one non-executable entry:

Category Roles
governance Human Governance Authority (non-executable), Project Manager, Solution Architect, Technical Reviewer, Agent Auditor
development Lead Programmer, Backend Engineer, Frontend Engineer, AI Engineer, DevOps Engineer
quality Security Engineer, QA Engineer, Performance Engineer, Reliability Engineer
specialist Documentation Engineer, UX Designer, Data Engineer, Release Manager, Compliance Officer
ai_system Agent Systems Engineer, Memory Engineer, Prompt Engineer, Conversation Engineer, Knowledge Engineer, MCP Engineer, Automation Engineer, AI Safety Engineer

Each role (Role in roles/models.py) defines: id, name, category, description, responsibilities, allowed_capabilities, forbidden_capabilities, required_evidence, conflicts_with, default_adapter, risk_level, enabled, executable.

Human Governance Authority

governance_authority is the one non-executable entry in the pool — it represents the Human Mission Commander for separation-of-duty checks and authority-model references. roles/validation.py rejects any attempt to make it executable.

Validation Rules (roles/validation.py)

The registry is rejected if it contains: duplicate IDs; ambiguous duplicate names; an allowed/forbidden capability overlap on the same role; a role that conflicts with itself; a conflicts_with reference to an unknown role; an executable Human Governance Authority; or any role whose allowed_capabilities includes push_execute, merge_execute, release_execute, production_read, production_write, or secret_read — those capabilities may only ever be reached through mission/run authorization plus a recorded human decision (see authorization-model.md), never baked into a role's permanent definition.

Separation of Duty

Role.conflicts_with declares role pairs that must never be held by the same acting identity within one mission (e.g. lead_programmer conflicts with technical_reviewer). This is enforced at role-selection time by orchestrator/selection.py::check_separation_of_duty, which compares the adapter identity assigned to each selected role, not the role definitions in isolation — see mission-orchestrator.md.

MVP Limitations

  • The 27 built-in roles are fixed at this MVP stage; there is no CLI command yet to add or edit a custom role (assync role list/show/validate are read-only).
  • default_adapter is currently informational only — the orchestrator requires an explicit run-config entry per selected role.