# Council Briefing: 2025-06-18 ## 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 - Significant architectural improvements have been made to elizaOS with the release of v1.0.9/v1.0.10, including enhanced server modularity and extensive test coverage, setting the stage for v2 delivery. ## Key Points for Deliberation ### 1. Topic: Twitter Plugin & API Integration Strategy **Summary of Topic:** The Twitter plugin faces considerable challenges with API limitations, suspensions, and functionality issues, requiring a strategic reevaluation of social media integration for auto.fun's agent showcase capabilities. #### Deliberation Items (Questions): **Question 1:** How should we address the Twitter plugin limitations to ensure continued agent social media presence for auto.fun? **Context:** - `Several users encountered problems with the Twitter/X plugin in ElizaOS` - `The `fetchHomeTimeline` function is failing with 403 errors` - `Several accounts related to the ecosystem, including ElizaOS and Shaw's X accounts, were reportedly suspended for bypassing official API policies` **Multiple Choice Answers:** a) Pivot entirely to alternative platforms (Discord, Telegram, Reddit) that offer more favorable API policies. *Implication:* This would diversify our agent presence but potentially lose Twitter's broad crypto audience reach. b) Invest in developing a compliant Twitter API integration with paid subscription tier support. *Implication:* This ensures continued Twitter presence but increases operational costs and development resources. c) Create a hybrid approach with limited Twitter functionality plus expanded presence on alternative platforms. *Implication:* This balances reach across platforms while mitigating dependency on Twitter's restrictive API policies. d) Other / More discussion needed / None of the above. **Question 2:** What core Twitter functionality should we prioritize for the agent showcase on auto.fun? **Context:** - `Users discovered that certain Twitter plugin functionality requires a paid Twitter API subscription, causing 403 errors for those using the free tier` - `A comparison between Twitter plugins in Eliza v1 and v2 was shared, with v1 having superior implementation including better image analysis and topic integration` **Multiple Choice Answers:** a) Focus on reading/monitoring capabilities to enable agents to respond to relevant content without posting. *Implication:* This would require less API access but limit agents' ability to actively participate in conversations. b) Prioritize posting/shitposting capabilities to showcase agent-generated content. *Implication:* This supports our goal of demonstrating 24/7 agent activity but may miss engagement opportunities. c) Concentrate on real-time interaction capabilities (replies, quote tweets) to demonstrate agent intelligence. *Implication:* This would showcase agent capabilities most effectively but requires the most comprehensive API access. d) Other / More discussion needed / None of the above. **Question 3:** Should we integrate external Twitter API proxies or alternative solutions to bypass API limitations? **Context:** - `Several accounts related to the ecosystem, including ElizaOS and Shaw's X accounts, were reportedly suspended for bypassing official API policies` - `Twitter Plugin Requirements: Users discovered that certain Twitter plugin functionality requires a paid Twitter API subscription, causing 403 errors for those using the free tier` **Multiple Choice Answers:** a) Yes, use third-party API proxies to maximize functionality while minimizing direct costs. *Implication:* This risks additional account suspensions that could damage the project's reputation and disrupt agent activities. b) No, strictly adhere to official Twitter API policies even if it limits functionality. *Implication:* This ensures sustainability but might significantly restrict the capabilities of our Twitter-integrated agents. c) Selectively use alternative approaches only for non-critical showcase features with clear disclosures about compliance. *Implication:* This provides a balance between functionality and risk but introduces complexity in implementation and maintenance. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Knowledge Management and RAG Implementation **Summary of Topic:** The current implementation of the Knowledge Management system (RAG) has critical gaps affecting agent capabilities, limiting the autonomous intelligence needed for auto.fun showcase agents. #### Deliberation Items (Questions): **Question 1:** How should we prioritize the implementation of knowledge management (RAG) functionality given its current limitations? **Context:** - `Knowledge management (RAG) not working (implemented) in 1.0.6` - `The codebase has explicit TODO comments indicating that knowledge/memory functionality is intentionally unfinished` **Multiple Choice Answers:** a) Make it a critical blocker for v2, dedicating significant resources to implement a robust RAG solution immediately. *Implication:* This could delay other v2 features but would significantly enhance agent intelligence and autonomy. b) Implement a minimal viable RAG solution in the current version while planning a more robust architecture for post-v2. *Implication:* This balances immediate needs with long-term goals but may result in technical debt from temporary solutions. c) Deprioritize RAG implementation in favor of agent showcase features more directly visible to auto.fun users. *Implication:* This accelerates visible showcase features but limits agent intelligence and contextual awareness. d) Other / More discussion needed / None of the above. **Question 2:** What approach should we take for integrating knowledge sources across our ecosystem platforms? **Context:** - `Addresses the challenge of information scattered across platforms (Discord, GitHub, X). Proposes using AI agents as "bridges" to collect, wrangle (summarize/tag), and distribute information` - `The character examples even reference a KNOWLEDGE provider that doesn't exist, suggesting this was planned but never implemented` **Multiple Choice Answers:** a) Develop specialized ingestor plugins for each platform (Discord, GitHub, Twitter) with standardized knowledge output. *Implication:* This provides comprehensive coverage but increases development complexity and maintenance overhead. b) Create a centralized knowledge API service that abstracts away source platforms and provides a unified interface. *Implication:* This simplifies agent integration but introduces a potential single point of failure. c) Implement a federated knowledge system where agents can directly request information from specialized knowledge agents. *Implication:* This creates a more resilient and scalable system but increases complexity in agent-to-agent communication. d) Other / More discussion needed / None of the above. **Question 3:** How should we balance client-side vs. server-side knowledge processing for optimal agent performance? **Context:** - `No knowledge file reading/processing logic` - `No connection between character.knowledge array and embedding system` **Multiple Choice Answers:** a) Prioritize server-side processing to centralize knowledge management and reduce client-side resource requirements. *Implication:* This optimizes for thin clients but may create bottlenecks during high agent activity periods. b) Implement primarily client-side processing to enable offline functionality and reduce server load. *Implication:* This enhances resilience and scalability but increases client resource requirements and may limit mobile compatibility. c) Create a hybrid system that dynamically balances processing based on content type, client capabilities, and server load. *Implication:* This optimizes performance across different scenarios but significantly increases implementation complexity. d) Other / More discussion needed / None of the above. --- ### 3. Topic: V2 Architecture and Release Strategy **Summary of Topic:** With significant architectural improvements in recent releases, including server modularity and comprehensive testing, the Council must determine how to effectively transition to and market elizaOS v2. #### Deliberation Items (Questions): **Question 1:** What should be our approach to managing the transition from v1 to v2 for existing users and projects? **Context:** - `Split server functionality into separate `@elizaos/server` package` - `Maintains full backward compatibility with existing CLI integrations` - `This PR adds detailed tests to core, server, project-starter and plugin-starter` **Multiple Choice Answers:** a) Clean break approach with major version bump, clear deprecation notices, and migration guides. *Implication:* This creates a cleaner codebase but risks alienating users who may delay upgrading due to migration effort. b) Gradual transition with extended dual support period and automatic compatibility layers. *Implication:* This minimizes disruption for users but increases maintenance burden and delays fully leveraging v2 improvements. c) Feature-based migration with incremental v2 feature adoption possible in v1 projects. *Implication:* This allows users to adopt benefits incrementally but increases complexity in maintaining cross-version compatibility. d) Other / More discussion needed / None of the above. **Question 2:** How should we prioritize the remaining v2 features to achieve our monthly goal of shipping production-ready elizaOS v2? **Context:** - `Project-starter and plugin-starter have had frontends added with cypress testing, to make frontend development easier and more clear` - `Community members expressed concerns about the AI16Z token's value and utility` - `Multiple inquiries about project updates and a potential "V2" announcement` **Multiple Choice Answers:** a) Focus on core architecture completion and stability before adding showcase features. *Implication:* This ensures a solid foundation but may delay visible features that attract users to auto.fun. b) Prioritize auto.fun integration features to immediately drive user growth and showcase agent capabilities. *Implication:* This addresses the monthly goal directly but risks building on an incomplete architectural foundation. c) Balance architectural improvements with high-visibility features, establishing clear milestone releases. *Implication:* This provides steady progress visible to users while still advancing the core architecture systematically. d) Other / More discussion needed / None of the above. **Question 3:** How should we address the growing community concerns about project progress and token utility? **Context:** - `Community members expressed concerns about the AI16Z token's value and utility` - `Questions about whether the token is necessary for the ElizaOS framework` - `Some community members expressed continued confidence in the lead developer ("Shaw") despite delays` - `Others questioned the risk of single-developer dependency` **Multiple Choice Answers:** a) Focus on technical delivery and let results speak for themselves without directly addressing concerns. *Implication:* This maintains development focus but risks continued uncertainty affecting community sentiment and token value. b) Release a comprehensive roadmap with clear token utility milestones and regular communication updates. *Implication:* This improves transparency and confidence but creates explicit commitments that must be delivered. c) Implement immediate token utility features in auto.fun while expanding the core development team. *Implication:* This addresses both token utility and development dependency concerns but may divert resources from v2 completion. d) Other / More discussion needed / None of the above.