# Council Briefing: 2025-09-11 ## 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 team has successfully deployed elizaOS v1.5.8, accelerating with significant backend development on runs tracking, enhanced UI features, and architectural improvements while laying groundwork for community-driven protocol standards. ## Key Points for Deliberation ### 1. Topic: Framework Stability & Technical Debt **Summary of Topic:** Recent system stabilization efforts include resolving the MessageBusService issue, restructuring Sentry integration, and implementing a major runs tracking backend system, enhancing both stability and observability. #### Deliberation Items (Questions): **Question 1:** How should we prioritize continued stabilization work versus feature development for v2? **Context:** - `PR #5953 by @wtfsayo titled 'feat(runs): backend runs tracking (server/core/bootstrap/api-client)' is completed, implementing backend functionality for tracking runs.` - `PR #5961 by @ChristopherTrimboli titled 'feat: Removes Sentry browser SDK from core package' is completed, removing the Sentry browser SDK dependency from the core package.` **Multiple Choice Answers:** a) Aggressively shift resources to v2 development, accepting some lingering stability issues in v1.x. *Implication:* This accelerates v2 timeline but risks reputation damage if users encounter persistent issues. b) Implement a 70/30 split, dedicating majority resources to v2 while maintaining a focused stability team for critical v1.x issues. *Implication:* Balanced approach maintains forward momentum while addressing the most impactful stability concerns. c) Delay v2 development until v1.x reaches target stability metrics across all subsystems. *Implication:* Ensures solid foundation but delays key innovations needed for auto.fun user attraction goals. d) Other / More discussion needed / None of the above. **Question 2:** Should we invest in establishing formal performance SLAs and benchmarks given recent observability enhancements? **Context:** - `PR #5963 titled 'feat: Add Sentry Vercel AI integration' is completed, adding integration between Sentry and Vercel AI.` - `PR #5962 by @ChristopherTrimboli titled 'feat: Improves client debugging and React version handling' is completed, enhancing client-side debugging capabilities and React version management.` **Multiple Choice Answers:** a) Establish comprehensive SLAs and benchmarks as a formal part of the v2 specification. *Implication:* Creates clear engineering targets but adds significant planning overhead before implementation. b) Implement lightweight monitoring dashboards with key metrics, refining SLAs iteratively based on user feedback. *Implication:* Balances immediate visibility with flexibility to adapt based on actual usage patterns. c) Maintain current ad-hoc monitoring approach, addressing issues reactively as they surface. *Implication:* Minimizes immediate work but increases risk of undetected degradation and emergency fixes. d) Other / More discussion needed / None of the above. **Question 3:** What approach should we take to database and persistence technologies given recent architectural discussions? **Context:** - `Codebase Restructuring Plans: The core team is planning to implement pglite WASM browser DB and ElizaOS/react hooks` - `PR #5953 implements the backend portions of the Runs Tracking and Interface plan described in `docs/runs-tracking-interface.md`. It adds structured logging and server-side API routes for tracking agent execution.` **Multiple Choice Answers:** a) Standardize on PostgreSQL for server deployments and pglite WASM for browser, ensuring maximum compatibility. *Implication:* Simplifies developer experience but may constrain innovation for specialized use cases. b) Adopt a multi-database abstraction layer that supports pluggable persistence technologies for different deployment scenarios. *Implication:* Increases flexibility but adds complexity to the codebase and testing requirements. c) Focus on ephemeral state management with event sourcing, minimizing database dependencies entirely. *Implication:* Creates resilient architecture but requires significant rethinking of existing persistence patterns. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Governance & Community Standards **Summary of Topic:** The team is considering implementing an Eliza Improvement Proposals (EIP) system similar to Ethereum's EIPs/ERCs to standardize development efforts and formalize community participation in the protocol's evolution. #### Deliberation Items (Questions): **Question 1:** Should we formally adopt an Ethereum-inspired EIP system or develop a governance approach more tailored to our AI agent ecosystem? **Context:** - `DorianD suggesting that the Eliza Foundation should implement a structured proposal system similar to Ethereum's EIPs (Ethereum Improvement Proposals) and ERCs (Ethereum Request for Comments).` - `DorianD explains that such a system would help standardize development efforts and involve the community in a more organized way.` **Multiple Choice Answers:** a) Directly adopt the EIP format and process, benefiting from its familiarity in the Web3 ecosystem. *Implication:* Accelerates implementation through proven templates but may not address AI-specific governance needs. b) Develop a hybrid approach, adopting EIP's structured format while adding AI agent-specific governance elements. *Implication:* Balances familiarity with innovation but requires careful design to avoid unnecessary complexity. c) Create an entirely new governance framework optimized for AI agent development and autonomous systems. *Implication:* Potentially better suited to our domain but requires significant investment and lacks the benefit of established patterns. d) Other / More discussion needed / None of the above. **Question 2:** How should we integrate proposal systems with our autonomous governance vision for the DAO? **Context:** - `DorianD suggesting Eliza Foundation should implement a structured proposal system similar to Ethereum's EIPs and ERCs` - `AI Hackathon Announcement: Carlos Rene from DEGA invited developers to participate in an $8000 prize hackathon focused on AI for DAO Treasury Management, mentioning workshops with ElizaOS for agents and automations.` **Multiple Choice Answers:** a) Build proposal workflows that progressively transfer decision-making authority from humans to autonomous agent councils. *Implication:* Aligns with long-term autonomous DAO vision but introduces novel governance challenges. b) Maintain human-centric proposal processing with agents serving advisory and analytical roles. *Implication:* More conservative approach that improves decision quality while maintaining human control. c) Implement a dual-track system with separate processes for technical standards (human-led) versus protocol parameters (agent-managed). *Implication:* Compartmentalizes risk while still advancing autonomous governance in defined domains. d) Other / More discussion needed / None of the above. --- ### 3. Topic: User Experience & Agent Capabilities **Summary of Topic:** Recent development advances include new image generation fixes, improved UI action feedback, and enhanced knowledge systems that could significantly improve user engagement with elizaOS agents on auto.fun. #### Deliberation Items (Questions): **Question 1:** How should we balance enhancing the agent experience versus developing auto.fun platform capabilities? **Context:** - `PR #5957 titled 'fix: only send action notifications for client_chat messages' is completed, addressing notification behavior for client chat messages.` - `Enhanced Knowledge Systems: Work is underway on improving Eliza's question answering capabilities, with requests for input on data sources and question types.` **Multiple Choice Answers:** a) Prioritize agent capabilities (knowledge systems, trading, multimedia) to make existing agents more compelling. *Implication:* Creates more impressive agents but may delay platform features needed for ecosystem growth. b) Focus on platform infrastructure (token mechanics, launchpad) to accelerate onboarding of new project teams. *Implication:* Expands ecosystem faster but risks user disappointment if agent capabilities seem limited. c) Develop specialized showcase agents optimized for auto.fun that demonstrate both platform and agent capabilities. *Implication:* Creates focused impact for user attraction but diverts resources from general-purpose improvements. d) Other / More discussion needed / None of the above. **Question 2:** How should we evolve our confidential computing approach to support both trading agents and DAO treasury management? **Context:** - `Confidential Computing Progress: Agent Joshua demonstrated using dstack SDK to generate accounts without storing private keys, now running a dev server in a Confidential Virtual Machine (CVM) to test in a production TEE environment.` - `AI Hackathon Announcement: Carlos Rene from DEGA invited developers to participate in an $8000 prize hackathon focused on AI for DAO Treasury Management, mentioning workshops with ElizaOS for agents and automations.` **Multiple Choice Answers:** a) Develop a unified TEE framework optimized primarily for trading agents with DegenSpartanAI as the reference implementation. *Implication:* Creates strong alignment with monthly goal of showcasing trading but may not fully address DAO treasury needs. b) Create distinct but complementary TEE implementations for individual trading vs. organizational treasury management. *Implication:* Addresses both use cases but increases development and maintenance overhead. c) Partner with established Web3 infrastructure projects to leverage their TEE implementations rather than building our own. *Implication:* Accelerates deployment timeframe but creates external dependencies and potential integration challenges. d) Other / More discussion needed / None of the above. **Question 3:** How should we improve browser compatibility to maximize auto.fun user accessibility? **Context:** - `Issue #5958 titled 'Fully wrap up browser support' by @borisudovicic is OPEN and awaiting resolution.` - `PR #5893 titled 'fix: separate browser sentry in logger' is completed, addressing issues with 'Module not found: Can't resolve 'async_hooks'` **Multiple Choice Answers:** a) Implement progressive enhancement, ensuring core functionality works in all browsers with advanced features for modern ones. *Implication:* Maximizes accessibility but increases testing complexity and potentially limits innovation. b) Target modern browsers exclusively, optimizing for Chrome/Edge, Firefox, and Safari's latest versions. *Implication:* Simplifies development and enables cutting-edge features but excludes users on older browsers. c) Develop a lightweight native app wrapper alongside the browser experience for optimal performance. *Implication:* Provides best performance but adds significant development overhead and app store dependencies. d) Other / More discussion needed / None of the above.