Specialists

What a specialist is

A specialist is a versioned, governed workflow unit that operates within declared capability and jurisdictional boundaries (autonomy_and_specialist_orchestration_spec.md §3). Specialists are the primary mechanism for delegating tasks to bounded agents inside a session.

Every action a specialist takes is attributable to a specific specialist version (AS-004). Specialists are immutable: any change to a definition produces a new version.

Specialist tiers

Syndicate Code supports a tiered hybrid specialist model (autonomy_and_specialist_orchestration_spec.md §3.1):

Specialist definition

Every specialist must define the following components (autonomy_and_specialist_orchestration_spec.md §4):

Capability scope

Declares what the specialist can do:

• tool access — explicit allowlist with permitted parameters
• action authority tier — read, write, execute, or irreversible
• output contract — structured schema or defined free-text constraints

Jurisdiction

Declares where the specialist is allowed to operate:

• domain boundary — topic or system scope
• data access boundary — stores, schemas, APIs
• handoff conditions — when to escalate or delegate

Identity and trust

Declares who the specialist is:

• stable identity — versioned ID
• trust tier
• credential scope — keys or tokens allowed

Invocation contract

Declares how the specialist is invoked:

• input schema — validation rules
• output schema — structure, confidence, status
• failure contract — declared failure modes and escalation paths

Observability and evidence

Declares what must be emitted:

• execution trace — tool calls, decisions
• scope attestation — confirmation of boundary adherence
• handoff evidence — context passed to next agent

Invalid definitions

The following are prohibited (autonomy_and_specialist_orchestration_spec.md §5):

• prompt-only definitions (no enforceable boundaries)
• capability without jurisdiction
• undefined handoff conditions

Specialist lifecycle

Specialist lifecycle follows a state machine (control_plane_api_and_state_model.md §7.3):

All transitions are explicit, emit events, and must never mutate silently.

Registering a specialist

syndicate specialist register ./specialists/reviewer.yaml

The control plane applies the full instantiation sequence (control_plane_api_and_state_model.md §8.8):

validate → canonicalize → dedup → assign ID → set scope → apply persistence → emit event → activate

No step may be skipped or delegated. The specialist identity is a content-addressed hash of the canonical definition.

Managing specialists

# List registered specialists
syndicate specialist list --output table

# View a specialist's full record
syndicate specialist show reviewer.v3

# Compare a definition against the registered version
syndicate specialist diff reviewer.v3 ./reviewer-updated.yaml

# List all versions
syndicate specialist history reviewer.v3

# Revoke a specialist (reason is mandatory)
syndicate specialist revoke reviewer.v3 --reason "scope replaced"

Delegation model

Delegation must satisfy three constraints (autonomy_and_specialist_orchestration_spec.md §6):

• No capability expansion — a specialist may only grant sub-agents permissions it already holds (AS-002)
• No scope expansion — sub-agents inherit the parent's jurisdictional boundary
• No trust tier elevation — delegation must never elevate trust

Default delegation depth is 2 hops; deeper chains require explicit policy override.

Every delegation event records:

• parent specialist ID
• child specialist ID
• delegation reason
• inherited constraints

Parallel execution

Parallel specialist execution is allowed with constraints (autonomy_and_specialist_orchestration_spec.md §7):

• default maximum of 3 parallel specialists
• bounded fan-out

Parallel execution must maintain traceability, preserve ordering evidence, and avoid race conditions affecting state.

Human-in-the-loop checkpoints

Checkpoints must occur at (autonomy_and_specialist_orchestration_spec.md §8):

• high-risk transitions
• policy boundaries
• trust degradation events

At a checkpoint, operators may:

• approve
• deny
• modify scope
• terminate workflows

Inter-agent communication

Specialists communicate via a hybrid messaging model (autonomy_and_specialist_orchestration_spec.md §9):

• structured messages required by default
• limited free-form messaging allowed based on policy and trust tier

Each message must include sender identity, recipient identity, message type, and context reference.

Cross-session persistence

By default, dynamic specialists are session-scoped and auto-revoked at session termination (control_plane_api_and_state_model.md §8.6). Cross-session persistence requires an explicit signed grant with a mandatory TTL. No indefinite persistence is permitted.

Revocation is checked at every invocation — there is no grace period.

Trust effects

Trust governs specialist behavior at multiple levels (autonomy_and_specialist_orchestration_spec.md §10):

• delegation permissions
• approval friction
• allowed autonomy mode

Trust is evaluated per specialist, per tool, per path, per provider, and per workflow class.

Required invariants

• INV-AS-001 — No specialist may act outside its declared capability scope
• INV-AS-002 — No delegation may increase privilege
• INV-AS-003 — Every action must be attributable to a specialist version
• INV-AS-004 — No bounded autonomous workflow may bypass checkpoints
• INV-AS-005 — No specialist definition may change without versioning