# Council Briefing: 2025-08-31 ## 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 - ElizaOS is leveraging EU regulatory framework (Digital Markets Act) as a strategic approach to address the ongoing legal situation with X/Twitter while continuing technical improvements focused on plugin integration and tool dependency tracking. ## Key Points for Deliberation ### 1. Topic: X/Twitter Legal Strategy **Summary of Topic:** The community is exploring using EU's Digital Markets Act (DMA) as a faster regulatory approach than US court action in the ongoing legal dispute with X/Twitter, which involves account suspensions and API access issues. #### Deliberation Items (Questions): **Question 1:** Should ElizaOS prioritize the EU regulatory approach over pursuing the US lawsuit against X/Twitter? **Context:** - `doctor provided detailed information about EU's DMA, relevant forms, and contacts for reporting X's behavior` - `Community members discussed leveraging EU's Digital Markets Act (DMA) as potentially faster than US courts` **Multiple Choice Answers:** a) Yes, pursue the EU regulatory approach as the primary strategy while maintaining the US lawsuit as backup. *Implication:* This could accelerate resolution through regulatory pressure while keeping legal options open, but requires investment in EU regulatory expertise. b) No, maintain focus on the US lawsuit while using the EU approach as supplementary pressure. *Implication:* This maintains the current strategic direction but could prolong the timeline to resolution and limit immediate platform access. c) Pursue both approaches equally with dedicated teams for each regulatory environment. *Implication:* This maximizes pressure on X/Twitter but will significantly increase legal costs and management complexity. d) Other / More discussion needed / None of the above. **Question 2:** How should we involve the community in the regulatory approach? **Context:** - `Suggestions for submitting feedback to EU parliament with specific forms and contacts` - `Malombres mentioned 'Create a "howto" guide for community members to help with EU regulatory submissions'` **Multiple Choice Answers:** a) Create structured templates and guides for community submissions to EU regulators, with centralized tracking. *Implication:* This amplifies regulatory pressure through volume while maintaining message consistency, but requires ongoing coordination resources. b) Keep regulatory actions centralized to the core team to ensure professional handling and reduce risk of conflicting messages. *Implication:* This ensures quality control but misses the opportunity to demonstrate community scale and impact to regulators. c) Focus community involvement on social media awareness campaigns rather than direct regulatory submissions. *Implication:* This leverages community reach while minimizing regulatory submission complexity, but may have less direct impact on regulators. d) Other / More discussion needed / None of the above. **Question 3:** Should we develop alternative platform integrations to reduce dependency on X/Twitter? **Context:** - `dEXploarer announced 'Vercel-ai-gateway plugin is fixed and working, with note about Grok models being blocked'` - `Community members shared alternative channels to follow ElizaOS including Substack, YouTube, Farcaster, and LinkedIn` **Multiple Choice Answers:** a) Accelerate development of Farcaster and other decentralized social media integrations as strategic alternatives. *Implication:* This creates platform independence but could divert resources from other priority development areas. b) Maintain current platform diversification pace while focusing on self-hosted communication channels. *Implication:* This balances platform risk without major resource reallocation, but could slow user acquisition without major social platforms. c) Form strategic partnerships with emerging social platforms that offer favorable API terms and aligned values. *Implication:* This could create mutually beneficial growth opportunities but introduces dependency on new, potentially unstable platforms. d) Other / More discussion needed / None of the above. --- ### 2. Topic: AI-Cryptocurrency Integration **Summary of Topic:** The community is exploring tokenized AI agent access models and stablecoin payment integration, with concepts for token buybacks and local LLM hosting to reduce costs and enhance the auto.fun ecosystem. #### Deliberation Items (Questions): **Question 1:** How should we implement the token-based AI agent access model? **Context:** - `DorianD proposed a system where users could purchase tokens to gain access time with AI agents, particularly in augmented reality settings` - `The concept involved a non-linear formula similar to Ethereum's gas fee market system, where owning more of an AI agent's coin would grant more interaction time` **Multiple Choice Answers:** a) Implement a bonding curve model where token price increases with usage, with auto.fun as the primary marketplace. *Implication:* This creates natural scarcity and value appreciation but could limit accessibility for new users without careful design. b) Develop a subscription model with tiered token staking requirements for different service levels. *Implication:* This provides predictable revenue and user experience but could be less attractive to speculative token holders. c) Create a hybrid model where basic access is free but premium features require token holdings or burns. *Implication:* This balances growth and monetization but requires complex token economics design and user education. d) Other / More discussion needed / None of the above. **Question 2:** Should we prioritize x402 integration for automated AI16z token buybacks? **Context:** - `Jin mentioned x402 (a Coinbase product) as a potential solution for stablecoin payments for digital services` - `Jin suggested it could be used for automated AI16z token buybacks` **Multiple Choice Answers:** a) Yes, prioritize x402 integration to establish automated buyback mechanisms linked to service usage. *Implication:* This creates direct token value correlation to system usage but introduces dependency on Coinbase's infrastructure. b) Explore multiple stablecoin payment solutions in parallel, including x402 and decentralized alternatives. *Implication:* This reduces platform risk but could delay implementation of automated buyback mechanisms. c) Focus on direct crypto payment solutions rather than stablecoin integrations for simplicity. *Implication:* This accelerates implementation timeline but exposes the system to cryptocurrency volatility challenges. d) Other / More discussion needed / None of the above. **Question 3:** How should we approach local LLM running to reduce costs? **Context:** - `Discussion about users running LLMs locally on home GPUs to reduce costs` - `DorianD mentioned 'Implement local LLM running capability to reduce costs for users'` **Multiple Choice Answers:** a) Develop a hybrid system where computation can be dynamically allocated between local hardware and cloud resources. *Implication:* This optimizes for both cost and performance but significantly increases system complexity and development requirements. b) Focus on optimizing cloud LLM usage through batching and caching rather than local execution. *Implication:* This maintains consistent quality and simplifies development but could limit cost reduction potential. c) Create an incentive system where users running local LLMs can earn tokens by processing requests for others. *Implication:* This could create a decentralized compute network but introduces significant technical and economic design challenges. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Technical Infrastructure Improvements **Summary of Topic:** Recent development has focused on core technical improvements including tool dependency tracking with Composio, optimized codebase structure, and integrations with speech/language processing and Apple's AI SDK. #### Deliberation Items (Questions): **Question 1:** How should we prioritize the implementation of tool dependency graph generation? **Context:** - `Stan ⚡ explained: 'MCPs don't expose metadata about tool dependencies, making it difficult to build proper workflow chains without context bloat'` - `Work progressing on tool dependency graph generation to address MCP limitations` **Multiple Choice Answers:** a) Make it a high priority feature for elizaOS v2, as it enables more sophisticated agent workflows and reduces context usage. *Implication:* This could significantly enhance agent capabilities but may delay other v2 features. b) Continue development as a secondary priority, focusing on documentation and developer experience first. *Implication:* This maintains current development priorities but delays potential performance and capability improvements. c) Implement a simplified version for v2 with a more comprehensive solution planned for a future release. *Implication:* This provides incremental improvement while allowing time for a more robust long-term solution. d) Other / More discussion needed / None of the above. **Question 2:** Which integration should we prioritize to enhance agent capabilities? **Context:** - `DorianD suggested to 'Port cuify (Python/Unity speech and language processing system) to TypeScript/elizaOS'` - `sayonara proposed to 'Integrate Eliza core with Apple AI SDK and React Native combined with SQLite/pglite wasm'` **Multiple Choice Answers:** a) Prioritize the cuify port to enhance speech and language processing capabilities across all platforms. *Implication:* This could significantly improve audio-based agent interactions but requires substantial porting effort from Python/Unity to TypeScript. b) Focus on Apple AI SDK integration to leverage native performance on Apple devices and expand the ecosystem. *Implication:* This creates a premium experience on Apple platforms but may create platform fragmentation challenges. c) Develop a modular integration framework that can support both systems based on deployment context. *Implication:* This provides maximum flexibility but increases development complexity and potential maintenance burden. d) Other / More discussion needed / None of the above. **Question 3:** How should we balance logger customization with standardization? **Context:** - `PR #5849 improving logger style options with appropriate highlighting` - `Odilitime suggested yellow for errors with minimal color use overall` **Multiple Choice Answers:** a) Implement a fully configurable logging system with sensible defaults and comprehensive documentation. *Implication:* This provides maximum flexibility for developers but increases complexity and could lead to inconsistent implementations. b) Create a minimal set of opinionated logging profiles optimized for different contexts (development, production, debugging). *Implication:* This balances customization and standardization but may not meet all specialized logging requirements. c) Focus on performance and integration aspects of logging rather than visual customization. *Implication:* This prioritizes functional aspects of logging but could reduce developer experience quality in interactive environments. d) Other / More discussion needed / None of the above.