# Council Briefing: 2025-09-02 ## 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 - Community discussions reveal critical gaps in CLI architecture, user onboarding documentation, and emerging opportunities for AR/VR integration, requiring strategic decisions to align technical development with user acquisition goals. ## Key Points for Deliberation ### 1. Topic: CLI Refactoring Strategy **Summary of Topic:** Issue #5860 proposes a significant refactoring of the Eliza CLI to simplify architecture and reduce complexity, addressing current technical debt while potentially improving the developer experience. #### Deliberation Items (Questions): **Question 1:** How should we prioritize the CLI refactoring in relation to our monthly goal of shipping v2 and attracting new users to auto.fun? **Context:** - `cjft: The CLI is overly complex and is doing too much. There should be a v3 redesign that simplifies its responsibilities.` - `Issue #5860: Refactor Eliza CLI - The current CLI is overly complex and duplicates logic that should live inside project directories.` **Multiple Choice Answers:** a) Prioritize CLI refactoring as a blocker for v2, allocating additional resources to complete it within two weeks. *Implication:* This may delay auto.fun user acquisition initiatives but would ensure a more stable foundation for future development. b) Implement incremental CLI improvements alongside v2 development, focusing only on critical issues that directly impact user experience. *Implication:* This balanced approach addresses technical debt without compromising short-term user acquisition goals. c) Defer CLI refactoring until after v2 release, documenting current limitations while focusing all resources on auto.fun user growth. *Implication:* This maximizes near-term user acquisition at the cost of increasing technical debt that may require larger remediation later. d) Other / More discussion needed / None of the above. **Question 2:** What architectural approach should guide the CLI refactoring to best support our long-term mission of autonomous agent development? **Context:** - `cjft: It should be simpler - just handling env/char.json config and running the starter, not executing code itself.` - `Issue #5860: Instead of bootstrapping AgentServer inside the CLI, we should streamline it to handle only configuration and delegate execution to the project's runtime.` **Multiple Choice Answers:** a) Minimize CLI responsibilities to configuration management only, with all runtime logic moved to project directories. *Implication:* This creates a cleaner separation of concerns but requires more comprehensive documentation for developers. b) Create a hybrid approach where CLI maintains core bootstrapping capabilities but with improved modularity and clearer boundaries. *Implication:* This provides backward compatibility while incrementally improving architecture, potentially easing the transition for existing users. c) Rebuild the CLI with a plugin-based architecture that allows developers to extend functionality while maintaining a simple core. *Implication:* This would create the most flexible long-term solution but requires the largest upfront development investment. d) Other / More discussion needed / None of the above. --- ### 2. Topic: User Onboarding Improvements **Summary of Topic:** Significant gaps in documentation are hindering new user onboarding, with key interfaces like the web dashboard remaining undocumented, directly impacting our ability to attract and retain new users. #### Deliberation Items (Questions): **Question 1:** How should we address the critical documentation gaps identified in Issue #5857 regarding the web UI dashboard? **Context:** - `Issue #5857: Web UI dashboard exists but is completely undocumented (users don't know how to interact with their agent)` - `The dashboard URL appears on line 65 of 108 lines of startup output - completely buried in technical logs` **Multiple Choice Answers:** a) Immediately prioritize documentation updates with a dedicated technical writer to comprehensively revise the quickstart guide. *Implication:* This ensures new users can quickly access key interfaces but requires diverting resources from development. b) Implement UI improvements that make the dashboard URL more prominent in logs and add automatic browser opening on startup. *Implication:* This technical approach addresses the immediate symptom without requiring extensive documentation work. c) Create an interactive onboarding wizard that guides new users through setup and introduces them to all available interfaces. *Implication:* This comprehensive approach would significantly improve user experience but requires substantial development effort. d) Other / More discussion needed / None of the above. **Question 2:** What broader documentation strategy should we adopt to support our monthly goal of attracting new users to auto.fun? **Context:** - `Requests for roadmap information went unanswered.` - `Questions about token price decline and utility remained unanswered.` **Multiple Choice Answers:** a) Focus exclusively on technical documentation improvements, ensuring all features are properly documented before addressing strategic questions. *Implication:* This improves the experience for developers but doesn't address community concerns about project direction and token value. b) Develop a dual-track documentation strategy with separate technical guides and transparent project/token roadmaps. *Implication:* This balanced approach addresses both developer needs and investor concerns, potentially improving community trust. c) Create auto.fun-centric documentation that emphasizes use cases and benefits rather than technical implementation details. *Implication:* This aligns closely with the monthly goal but may leave technical users without sufficient guidance for development. d) Other / More discussion needed / None of the above. --- ### 3. Topic: AR/VR Integration Opportunity **Summary of Topic:** Community discussions reveal emerging opportunities to integrate elizaOS with AR/VR technologies, potentially creating a compelling showcase for AI agents that could drive user acquisition for auto.fun. #### Deliberation Items (Questions): **Question 1:** Should we pursue AR/VR integration as a strategic priority to showcase AI agent capabilities and attract users to auto.fun? **Context:** - `jin: Exploration of using AR glasses (Meta Quest 3, Brilliantlabs, Xreal One Pro) to showcase AI-powered NPCs through Eliza` - `DorianD: Develop multi-user memories for NPCs to facilitate social connections between users` **Multiple Choice Answers:** a) Prioritize AR/VR integration as a flagship initiative, allocating significant resources to create an immersive demo experience. *Implication:* This could create a highly differentiated showcase for elizaOS capabilities but diverts resources from core v2 development. b) Develop a lightweight AR/VR proof-of-concept that demonstrates potential while minimizing resource investment. *Implication:* This balanced approach allows exploration of the opportunity without significantly impacting the v2 timeline. c) Defer AR/VR initiatives until after v2 release, documenting requirements for future integration but focusing on core platform stability. *Implication:* This maintains focus on the current monthly goal but risks missing an opportunity to create a distinctive showcase for auto.fun. d) Other / More discussion needed / None of the above. **Question 2:** How might edge computing trends for AI influence our strategy for auto.fun and elizaOS v2? **Context:** - `jin: Discussion about running AI models locally, with mentions that full models like Deepseek can already run on high-end Mac Studios with sufficient RAM.` - `jin: Insights about container-based solutions like Umbrel and CasaOS that provide app store-like interfaces for hosting AI applications locally.` **Multiple Choice Answers:** a) Pivot to prioritize local/edge computing capabilities in elizaOS v2, positioning it as a framework for self-hosted AI agents. *Implication:* This could differentiate elizaOS in the privacy-conscious market but represents a significant strategic shift. b) Develop a hybrid architecture that supports both cloud and edge deployment, allowing users to choose based on their requirements. *Implication:* This flexible approach accommodates diverse use cases but increases architectural complexity. c) Maintain cloud-first focus for v2 while documenting edge computing as a future roadmap item to be developed post-release. *Implication:* This preserves focus on the current monthly goal but may miss an opportunity to capitalize on the edge computing trend. d) Other / More discussion needed / None of the above.