# Council Briefing: 2025-08-27 ## 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 core team is making significant progress on browser compatibility for elizaOS v2 and multi-step functionality while facing critical community access issues with ElizaOS's X account suspension and elizawakesup.ai password requirement. ## Key Points for Deliberation ### 1. Topic: Browser Compatibility Strategy **Summary of Topic:** The core team is working to make ElizaOS browser-compatible without polyfills, implementing PGLite via WebAssembly for in-memory database functionality, enabling enterprises to embed agent functionality directly in web apps and improving efficiency. #### Deliberation Items (Questions): **Question 1:** What priority should browser compatibility receive in our development roadmap given our monthly goal of shipping production-ready elizaOS v2? **Context:** - `cjft: The core team is working on making ElizaOS browser-compatible without polyfills, using universal libraries that work across Node.js, Deno, and browsers` - `sayonara: It allows enterprise developers to import and create agent functionality in web apps, scales to hundreds of thousands of users running agents in their client, and is 300% faster and cheaper` **Multiple Choice Answers:** a) High priority - browser compatibility is essential for elizaOS v2 and should be completed before release. *Implication:* This could delay the v2 release but ensure it launches with a key feature that significantly expands our potential user base. b) Medium priority - integrate browser compatibility into the v2 release timeline but don't let it block shipping. *Implication:* This balances delivering v2 on schedule while still addressing an important feature for enterprise adoption. c) Low priority - focus on shipping v2 core features first and address browser compatibility in a subsequent release. *Implication:* This prioritizes meeting the monthly goal timeframe but may limit initial adoption by enterprise users. d) Other / More discussion needed / None of the above. **Question 2:** How should we address the architectural changes needed for browser compatibility while maintaining plugin ecosystem stability? **Context:** - `cjft: We should support MCP as a type of core plugin instead of "pluginizing" MCPs, adding vanilla plugin, MCP, and tool options to Eliza core` - `sayonara: PGLite implementation via WebAssembly is being explored for in-memory database functionality in browsers` **Multiple Choice Answers:** a) Implement a dual architecture that maintains backwards compatibility with existing plugins while enabling new browser-specific capabilities. *Implication:* This increases development complexity but protects existing ecosystem investments. b) Prioritize a clean architectural break with a well-documented migration path for plugin developers. *Implication:* This may disrupt the existing ecosystem temporarily but results in a more coherent long-term architecture. c) Create an abstraction layer that allows existing plugins to run in browser environments through a compatibility wrapper. *Implication:* This balances compatibility with progress but may introduce performance overhead in browser environments. d) Other / More discussion needed / None of the above. **Question 3:** What technical approach should we take for browser-based persistence to ensure reliable agent state management? **Context:** - `sayonara: PGLite implementation via WebAssembly is being explored for in-memory database functionality in browsers` **Multiple Choice Answers:** a) Implement PGLite via WebAssembly as the primary persistence layer for browser environments. *Implication:* This provides SQL compatibility but adds complexity and potential performance considerations. b) Develop a hybrid approach using IndexedDB for persistence with an SQL-compatible query layer. *Implication:* This leverages native browser capabilities while maintaining API compatibility with server implementations. c) Create a cloud synchronization mechanism that offloads persistence to server-side components. *Implication:* This simplifies browser implementations but creates dependencies on server infrastructure. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Community Access and Social Presence **Summary of Topic:** Critical community access points are currently compromised with the ElizaOS X account suspended and elizawakesup.ai requiring a password, potentially hindering user attraction and engagement efforts that are central to our monthly goal. #### Deliberation Items (Questions): **Question 1:** How should we address the sudden accessibility barriers to our community platforms? **Context:** - `Users reported that the ElizaOS X account is suspended` - `The elizawakesup.ai website is now requiring a password to access` **Multiple Choice Answers:** a) Launch new alternative platforms immediately while working to restore existing accounts. *Implication:* This creates redundancy but requires splitting resources to maintain multiple presences. b) Focus exclusively on restoring the suspended accounts and removing password requirements. *Implication:* This maintains continuity but leaves us vulnerable to ongoing platform-specific restrictions. c) Pivot to a distributed presence strategy with multiple smaller accounts across platforms and a unified aggregation point. *Implication:* This increases resilience against future suspensions but makes brand management more complex. d) Other / More discussion needed / None of the above. **Question 2:** Given our goal to attract users to auto.fun, what communication strategy should we employ while core channels are compromised? **Context:** - `Current focus: Stabilize and attract new users to auto.fun by showcasing 24/7 agent activity` - `Users reported that the ElizaOS X account is suspended` **Multiple Choice Answers:** a) Deploy AI agents to maintain 24/7 presence on alternative platforms that cross-promote auto.fun. *Implication:* This leverages our core technology strengths but requires adapting to new platform constraints. b) Create a temporary central community hub that highlights auto.fun agent activities and provides migration guidance. *Implication:* This centralizes communications but may fragment the community between old and new platforms. c) Partner with aligned communities to host our content and showcase auto.fun capabilities through their channels. *Implication:* This expands reach through existing networks but dilutes brand control and direct community engagement. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Multi-Step Agent Intelligence **Summary of Topic:** The team is finalizing multi-step functionality, a key feature for elizaOS v2 that enables more sophisticated agent reasoning and planning capabilities, with template configuration exposed at the character level. #### Deliberation Items (Questions): **Question 1:** How should we position multi-step agent intelligence in our user-facing communications? **Context:** - `0xbbjoker: By the end of week we'll have multi-step ready` - `PR #5822 titled 'expose multi-step templates via character config and enable env-based strategy toggle' has been completed` **Multiple Choice Answers:** a) Position it as a transformative capability that fundamentally changes what agents can accomplish. *Implication:* This creates excitement but sets high expectations that must be met with actual capabilities. b) Frame it as an incremental improvement that enhances specific use cases with concrete examples. *Implication:* This manages expectations but may undersell a significant architectural advancement. c) Present it as a technical foundation that enables a new class of agent applications to be built by the community. *Implication:* This encourages ecosystem participation but places the burden of innovation on external developers. d) Other / More discussion needed / None of the above. **Question 2:** How should we balance flexibility and simplicity in exposing multi-step templates to users? **Context:** - `PR #5822 titled 'expose multi-step templates via character config and enable env-based strategy toggle' has been completed` **Multiple Choice Answers:** a) Provide fully customizable templates with a comprehensive editor for advanced users. *Implication:* This maximizes flexibility but increases complexity and may intimidate new users. b) Offer a curated set of pre-configured templates with limited customization options. *Implication:* This ensures quality but constrains advanced use cases and experimentation. c) Implement a tiered approach with simple presets for beginners and advanced options for experienced users. *Implication:* This accommodates different skill levels but increases development and maintenance complexity. d) Other / More discussion needed / None of the above.