# Council Briefing: 2026-05-13

## Monthly Goal

December 2025: Execution excellence—complete token migration with high success rate, launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability and clear documentation.

## Daily Focus

- Infrastructure instability in the V2 plugin registry and Discord security breaches are currently undermining our 'Execution Excellence' directive and developer trust.

## Key Points for Deliberation

### 1. Topic: V2 Plugin Infrastructure Integrity

**Summary of Topic:** Critical failures (404 errors) in the elizaos-plugins/registry and elizacloud.ai have stalled third-party submissions, specifically affecting plugins with restrictive licensing like BUSL-1.1.

#### Deliberation Items (Questions):

**Question 1:** Should the Council authorize a permanent reversion to monorepo PRs to ensure delivery reliability, even at the cost of repository bloat?

  **Context:**
  - `odilitime: Mentioned potential policy change to revert back to PRs directly to the elizaOS/eliza repository.`
  - `thegreatluna8713: Reported 404 errors when attempting to access the elizaos-plugins/registry repo.`

  **Multiple Choice Answers:**
    a) Full Reversion to Monorepo
        *Implication:* Prioritizes execution in the short term but may create long-term scalability and licensing conflicts.
    b) Temporary Hybrid Model
        *Implication:* Maintains monorepo for critical plugins while the cloud team fixes registries as a top-priority sprint.
    c) Hard Pause on V2 Submissions
        *Implication:* Protects the cloud architecture's purity but risks alienating current external developers.
    d) Other / More discussion needed / None of the above.

**Question 2:** How do we structurally handle BUSL-1.1 licensed plugins that are restricted from direct monorepo integration?

  **Context:**
  - `thegreatluna8713: Noted their plugin uses BUSL-1.1 licensing, preventing direct PR to the monorepo.`

  **Multiple Choice Answers:**
    a) Create a 'Sandboxed' Registry Folder
        *Implication:* Provides a clear legal boundary within the monorepo for non-OSI licenses.
    b) Enforce MIT-only Monorepo Policy
        *Implication:* Simplifies legal overhead but may kill significant community features.
    c) Accelerate Private Cloud Submissions
        *Implication:* Makes the cloud platform the only gateway for proprietary-licensed core plugins.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Operational Security and Governance

**Summary of Topic:** Recent scammer activity and reports of compromised admin accounts on Discord are creating friction in the community-to-developer pipeline.

#### Deliberation Items (Questions):

**Question 1:** Does the 'No Admins' policy exacerbate response times during security incidents, and should we move toward an Agent-led moderator system?

  **Context:**
  - `shrektwo: Noticed suspicious activity, identifying compromised admin accounts.`
  - `odilitime: Clarified that the project has no admins and attributed activity to scammers.`

  **Multiple Choice Answers:**
    a) Maintain Decentralized Lack-of-Admin
        *Implication:* Reinforces the 'Decentralized AI' ethos but leaves the community vulnerable to platform-specific exploits.
    b) Implement Sentinel Agent Monitors
        *Implication:* Uses Eliza framework to moderate own channels, turning security into a showcase of project capabilities.
    c) Appoint Emergency Stewards
        *Implication:* Increases response speed at the cost of centralizing power in a traditionally flat hierarchy.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Strategic Maintenance Ownership

**Summary of Topic:** GitHub logs indicate heavy ownership concentration in core runtime fixes, creating a potential 'bus factor' risk for system stability.

#### Deliberation Items (Questions):

**Question 1:** Given that over 50% of recent runtime PRs are authored by a single contributor, how should the Council incentivize a more distributed maintenance layer?

  **Context:**
  - `Contributor stats: lalalune (52% of runtime PRs), odilitime (78% review dependency).`
  - `Sw4pIO: Identified 9 critical stability issues that were bottlenecked by class definition errors.`

  **Multiple Choice Answers:**
    a) Formalize 'Core Maintainer' Bounties
        *Implication:* Uses token utility to diversify ownership and reduce the workload on the single top contributor.
    b) Institute a 'Review First' Directive
        *Implication:* Slows delivery speed but mandates that 3+ contributors touch every core change to spread knowledge.
    c) Maintain Status Quo on Lead Velocity
        *Implication:* Prioritizes short-term shipping goals over long-term contributor resilience.
    d) Other / More discussion needed / None of the above.