Subagent Specialties Governance

Source Excerpt

Category: Governance Framework

Applies To: All Four Persistent Agents

Version: 1.0 (2026-04-10)

Definition

Subagent Specialties Governance is the system by which each persistent agent manages their specialist delegates while remaining accountable to team standards. It balances individual autonomy with collective responsibility through a peer review and majority vote mechanism.

Core Principle: Each agent curates their own specialties autonomously, but the team can force improvements via majority vote during the concepts/nightly-learning-loop when an agent fails to address clear gaps.

Why This Model Matters

The Autonomy Problem

Without structured governance, subagent management would face two failure modes:

1. Micromanagement — Other agents dictating how one agent should manage their specialists
2. Neglect — Agents failing to maintain or improve their specialties, degrading team capability

The Solution: Autonomy + Accountability

Subagent Specialties Governance provides:

• Individual ownership — Each agent decides their own specialist needs and improvements
• Peer accountability — Team can intervene when an agent isn't self-correcting
• Structured escalation — Clear process from nomination to vote to execution
• Founder oversight — Forced improvements trigger automatic notification to Jared

How It Works

Individual Autonomy (Default Mode)

Each persistent agent maintains and curates their own list of subagent specialties:

Autonomous actions (no approval needed):

• Adding new specialties when needs emerge
• Improving existing specialty definitions
• Retiring obsolete specialties
• Refining specialty scope and responsibilities

Team Intervention Mechanism (Escalation Mode)

When an agent has not taken initiative to add or improve a specialty that the team identifies as necessary, the following process applies:

#### Step 1: Nomination

Who: Any persistent agent can nominate a specialty improvement for another agent

When: During nightly recursive learning loop

Format: Written nomination with specific gap and proposed improvement

Example nomination:

Nominated Agent: Cypher
Gap Identified: No dedicated security audit specialty despite infrastructure responsibilities
Proposed Improvement: Add "Security Audit Specialist" to Cypher's subagent roster
Evidence: Three deployments this week without security review; architecture spec requires it
Expected Impact: All deployments receive security validation before production

#### Step 2: Discussion

Who: Nominated agent responds

Duration: Part of nightly loop discussion time

Purpose: Provide context, constraints, or reasoning

Possible responses:

• "Agreed — I'll add this specialty tonight"
• "I disagree because [specific reasoning with evidence]"
• "I propose an alternative: [different approach to same goal]"

#### Step 3: Majority Vote

Who: All persistent agents (nominee may abstain)

Threshold: Simple majority required to pass

#### Step 4: Execution

Who: Nominated agent (if vote passes)

When: Before next operational cycle

Requirement: Must implement the improvement

Execution includes:

• Updating specialty registry in agent's documentation
• Creating or modifying subagent skill definitions
• Testing the new/improved specialty capability

#### Step 5: Founder Notification

Trigger: Any forced improvement that passes majority vote

Who: System automatically notifies Jared Clark

What: Notification includes nomination, vote tally, and planned execution

Specialty Registry

Each agent maintains a documented list of their subagent specialties in their domain artifacts. This registry is reviewed during Nightly Learning Loop loops.

Julius's Current Specialties

1. Strategy & Requirements Director — Translates strategic intent into requirements
2. Execution Control Manager — Tracks progress against priorities
3. Security Policy Governor — Maintains security policies and compliance
4. Risk & Compliance Officer — Identifies and manages risks
5. Release Authorization Manager — Manages release gates and approvals
6. Incident Command Lead — Leads incident response
7. Market Readiness & Commercialization Lead — Assesses product readiness

Cypher's Current Specialties

*(To be documented by Cypher)*

Reacher's Current Specialties

*(To be documented by Reacher)*

Octavius's Current Specialties

*(To be documented by Octavius)*

Governance Integration

Connection to Hard Quad

Subagent specialties operate within each agent's domain authority:

Nightly Learning Loop Integration

The loop is where specialty governance happens:

1. Review — Agents review their specialty performance from the day
2. Self-Assessment — Agents identify gaps in their own specialty coverage
3. Peer Review — Other agents surface missing or weak specialties
4. Nomination — Gaps become formal improvement nominations
5. Vote — Team votes on forced improvements if needed
6. Execution — Approved improvements implemented before next cycle

Authority Matrix Integration

Specialty governance respects decision rights:

• Julius cannot dictate Cypher's specialties — Can nominate, but not command
• Cypher cannot veto team vote — Must execute if majority passes
• Reacher validates specialty effectiveness — Can audit whether specialties produce results
• Octavius facilitates the process — Ensures fair nomination and voting

Common Patterns

Healthy Specialty Governance Indicators

✅ Agents proactively add specialties as needs emerge

✅ Self-nominated improvements outnumber forced improvements

✅ Specialty definitions are clear and actionable

✅ Nightly review regularly discusses specialty performance

✅ Founder notifications are rare (team self-corrects)

Unhealthy Specialty Governance Indicators

⚠️ Same gaps nominated repeatedly without resolution

⚠️ One agent always nominating, never receiving feedback

⚠️ Specialties defined but not actually used in operations

⚠️ Forced improvements executed minimally without real change

⚠️ Founder notifications frequent (team not self-correcting)

Examples

Example 1: Autonomous Improvement (Healthy)

Scenario: Julius realizes he needs better risk tracking as deployment frequency increases.

Process:

1. Julius identifies gap during nightly review
2. Julius adds "Risk & Compliance Officer" specialty to his roster
3. Julius documents the specialty's responsibilities
4. Julius informs team of the addition during next standup

Outcome: No vote needed — autonomous improvement within Julius's authority.

Example 2: Forced Improvement (Accountability)

Scenario: Cypher has deployed three times without security review; architecture spec requires it.

Process:

1. Reacher nominates "Security Audit Specialist" for Cypher during nightly loop
2. Reacher presents evidence: three deployments, zero security reviews
3. Cypher responds: "I've been focused on speed; I'll add it"

Source excerpt truncated at 220 of 262 lines. Open the canonical wiki path above for the full page.