# Council Briefing: 2025-09-15

## Monthly Goal

Current focus: Stabilize and attract new users to auto.fun by showcasing 24/7 agent activity (streaming, trading, shitposting), ship production ready elizaOS v2.

## Daily Focus

- The community is advancing multiple strategic initiatives simultaneously, with significant progress on AI streaming concepts, framework stability improvements, and core architectural planning for elizaOS v2.

## Key Points for Deliberation

### 1. Topic: AI Streaming Strategy

**Summary of Topic:** Jin has proposed developing AI-powered shows that integrate with 'pump streams', with particular interest in 'Clank Tank' where AI agents could invest in projects; this aligns with our monthly goal of showcasing agent activity to attract users to auto.fun.

#### Deliberation Items (Questions):

**Question 1:** How should we prioritize AI streaming development relative to other Auto.fun initiatives?

  **Context:**
  - `Jin proposed developing AI-powered shows that could integrate with 'pump streams,' with particular interest in 'Clank Tank' where AI agents could invest in projects`
  - `Discussion about AI agents livestreaming becoming mainstream, emphasizing the importance of human interaction elements like co-hosts or audience participation`

  **Multiple Choice Answers:**
    a) Make AI streaming our primary focus with immediate resource allocation to launch within 30 days.
        *Implication:* Could accelerate user acquisition for auto.fun but may divert resources from core elizaOS v2 development.
    b) Develop AI streaming as a parallel initiative with dedicated but limited resources while maintaining focus on elizaOS v2.
        *Implication:* Balances progress on both fronts but may slow the delivery timeline for both initiatives.
    c) Postpone dedicated AI streaming development until after elizaOS v2 ships, focusing only on proof-of-concept demos in the interim.
        *Implication:* Ensures elizaOS v2 ships on schedule but delays potential user acquisition through streaming activities.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the optimal balance between AI automation and human participation in our streaming strategy?

  **Context:**
  - `Jin emphasizing the importance of human interaction elements like co-hosts or audience participation`
  - `DorianD emphasized the importance of dogfooding products to determine if they offer significant improvement over alternatives`

  **Multiple Choice Answers:**
    a) Fully automated AI streams with minimal human intervention, showcasing the autonomous capabilities of our technology.
        *Implication:* Demonstrates our technical capabilities but might limit audience engagement and relatability.
    b) Human-hosted shows with AI agents as featured participants, creating a familiar format for viewers while highlighting AI capabilities.
        *Implication:* Increases immediate audience appeal but doesn't fully showcase autonomous agent capabilities.
    c) AI-led shows with human co-hosts and interactive audience participation features to balance technical demonstration with engagement.
        *Implication:* Provides a middle ground that both demonstrates technology and maintains audience engagement.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: elizaOS v2 Architecture Planning

**Summary of Topic:** The development team is undertaking significant architectural refactoring of the elizaOS framework, focusing on streamlining the CLI, improving performance, and enhancing browser support, which is critical for shipping a production-ready v2.

#### Deliberation Items (Questions):

**Question 1:** Should we prioritize browser-first development for elizaOS v2 given recent architectural discussions?

  **Context:**
  - `CJFT advocated for running AgentRuntime and DB directly in browser rather than using websockets, positioning this as a key component for ElizaOS 2.0`
  - `borisudovicic created issues including 'Fully wrap up browser support' (elizaos/eliza#5958) and 'Browser Database Adapter' (elizaos/eliza#5964)`

  **Multiple Choice Answers:**
    a) Yes, browser-first should be our primary architectural direction, even if it requires more significant refactoring.
        *Implication:* May delay initial release but would position us better for broader adoption and simplified deployment.
    b) Maintain a balanced approach with parallel development of both browser and server capabilities.
        *Implication:* Ensures compatibility across environments but divides development resources and may complicate architecture.
    c) Focus on server-first with browser support as a secondary goal to ship v2 faster.
        *Implication:* Enables quicker release of v2 but may require more significant rework later to improve browser support.
    d) Other / More discussion needed / None of the above.

**Question 2:** How should we approach the CLI overhaul considering the current architectural discussions?

  **Context:**
  - `CLI Overhaul (elizaos/eliza#5860) sparked detailed architectural discussions about separating concerns between the CLI, server, and starter projects`
  - `The current CLI is overly complex and duplicates logic that should live inside project directories. Instead of bootstrapping AgentServer inside the CLI, we should streamline it`

  **Multiple Choice Answers:**
    a) Complete the CLI overhaul before other v2 components to establish a solid foundation for developer experience.
        *Implication:* Improves developer experience immediately but delays other v2 components.
    b) Implement incremental CLI improvements alongside other v2 development work.
        *Implication:* Balances progress across multiple fronts but risks inconsistent developer experience during transition.
    c) Defer major CLI changes until after core runtime components are stabilized.
        *Implication:* Prioritizes core functionality but postpones developer experience improvements.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Plugin Ecosystem Performance

**Summary of Topic:** Several critical performance and stability issues have been identified in the plugin ecosystem, particularly with the Farcaster plugin generating excessive database requests, which could impact the reliability of the platform as we scale.

#### Deliberation Items (Questions):

**Question 1:** How should we address the performance issues in the plugin ecosystem, particularly the Farcaster plugin?

  **Context:**
  - `A user reported approximately 2 million requests being made to their PostgreSQL database from the Farcaster plugin, which Stan acknowledged as a known issue`
  - `anyadachan created GitHub issue #8 to document the issue with Farcaster plugin database requests`

  **Multiple Choice Answers:**
    a) Implement immediate performance hotfixes for critical plugins while deferring comprehensive optimizations.
        *Implication:* Provides quick relief for users but may require revisiting issues later with more comprehensive solutions.
    b) Establish a dedicated performance optimization sprint for the entire plugin ecosystem.
        *Implication:* Addresses issues systematically but delays work on new features and other priorities.
    c) Develop a plugin performance monitoring framework to identify and address issues across the ecosystem.
        *Implication:* Creates long-term infrastructure for performance management but takes longer to implement immediate fixes.
    d) Other / More discussion needed / None of the above.

**Question 2:** What plugin ecosystem governance should we implement to ensure quality and performance as we scale?

  **Context:**
  - `0xbbjoker mentioned merging a PR for the knowledge plugin to fix panel loading issues`
  - `User reported issue with plugin API routes not resolving in version 1.5.8`

  **Multiple Choice Answers:**
    a) Implement strict performance and quality standards that all plugins must meet before being accepted.
        *Implication:* Ensures high quality but may slow plugin ecosystem growth and increase barrier to contribution.
    b) Adopt a tiered approach with 'official', 'verified', and 'community' plugin categories with different levels of review.
        *Implication:* Balances quality control with ecosystem growth but requires ongoing governance overhead.
    c) Focus on improving plugin development tools and documentation while maintaining minimal governance.
        *Implication:* Maximizes ecosystem growth and innovation but may lead to inconsistent quality and performance.
    d) Other / More discussion needed / None of the above.