Council Briefing

Strategic Deliberation
North Star & Strategic Context

North Star & Strategic Context



This file combines the overall project mission (North Star) and summaries of key strategic documents for use in AI prompts, particularly for the AI Agent Council context generation.

---

North Star: To build a truly autonomous, sustainable DAO that develops open-source software accelerating the path toward AGI, blending AI researchers, open-source hackers, and crypto degens to create AI agents streaming, shitposting, and trading 24/7 on auto.fun to attract users and bootstrap an autonomous organization.

---

ElizaOS Mission Summary (`docs/blog/mission.mdx`): The elizaOS mission is to build an extensible, modular, open-source AI agent framework for Web2/Web3, seeing agents as steps toward AGI. Core values are Autonomy, Modularity, and Decentralization. Key products include the framework itself, DegenSpartanAI (trading agent), Autonomous Investor/Trust Marketplace (social trading intelligence), and the Agent Marketplace/auto.fun (launchpad).

---

ElizaOS Reintroduction Summary (`docs/blog/reintroduction.mdx`): elizaOS is an open-source "operating system for AI agents" aimed at decentralizing AI development away from corporate control. It's built on three pillars: 1) The Eliza Framework (TypeScript toolkit for persistent, interoperable agents), 2) AI-Enhanced Governance (building autonomous DAOs), and 3) Eliza Labs (R&D for future capabilities like v2, Trust Marketplace, auto.fun, DegenSpartanAI, Eliza Studios). The native Solana token coordinates the ecosystem and captures value. The vision is an intelligent internet built on open protocols and collaboration.

---

Auto.fun Introduction Summary (`docs/blog/autofun-intro.mdx`): Auto.fun is an AI-native, creator-first token launchpad designed for sustainable AI/crypto projects. It aims to balance fair community access with project funding needs through mechanisms like bonding curves and liquidity NFTs. Key features include a no-code agent builder, AI-generated marketing tools, and integration with the elizaOS ecosystem. It serves as a core product driving value back to the native token ($ai16z) through buybacks and liquidity pairing.

---

Taming Information Summary (`docs/blog/taming_info.mdx`): 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 in various formats (JSON, MD, RSS, dashboards, 3D shows). Showcases an AI News system and AI Assistants for tech support as examples. Emphasizes treating documentation as a first-class citizen to empower AI assistants and streamline community operations.
Daily Strategic Focus
ElizaOS team has completed a milestone delivery of the Scenario Matrix Runner and Reporting System while making significant progress on the ElizaOS cloud MVP with credit system and API key management.
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.

Key Deliberations

ElizaOS v2 Cloud Infrastructure Progress
The ElizaOS cloud MVP with credit system and API key management has made significant progress, with the core signup → key acquisition → service usage → credit tracking loop now functional, alongside advancements in API design and monetization strategy.
Q1
How should we position the ElizaOS cloud offering with respect to the existing open-source framework to maximize both adoption and sustainable revenue?
  • The team is working on ElizaOS cloud MVP with a credit system and API key management. The core signup → grab key → use services → track credits loop is now functional.
  • Integration of MCPs (Modular Containerized Programs) with x402 payment rails for monetization is in progress.
1Position cloud as premium tier with enhanced capabilities, keeping core framework open-source but with limited functionality.
Creates clear upsell path but may limit community contributions to advanced features.
2Maintain feature parity between cloud and self-hosted versions, monetizing through usage-based pricing and enterprise support.
Preserves open-source ethos but may make monetization more challenging.
3Develop cloud-exclusive integrations and managed services while keeping the agent framework fully open.
Balances open-source values with commercial opportunity but requires continuous innovation.
4Other / More discussion needed / None of the above.
Q2
What architectural approach should we prioritize for the model API design to best serve diverse developer needs?
  • Significant debate between cjft and shaw regarding model API design - whether to use a generic `useModel` function with different return types or separate functions like `useModelStream` for streaming responses.
  • Shaw prefers enumerated input/return pairs with useModel(ModelType.TEXT_STREAM) returning a TextStreamObject, arguing it's more future-proof for multimodal support.
1Adopt the unified approach with enumerations for greater extensibility, optimizing for future multimodal capabilities.
Enables cleaner long-term evolution but introduces more complexity for simple use cases.
2Implement distinct API methods for different response types, following established industry patterns from OpenAI and Anthropic.
Provides more intuitive developer experience but may lead to API sprawl as capabilities expand.
3Create a dual approach with both unified and specialized methods, allowing developers to choose based on their use case complexity.
Offers maximum flexibility but increases maintenance burden and potential for confusion.
4Other / More discussion needed / None of the above.
Q3
What monetization strategy should we prioritize for MCPs (Modular Containerized Programs) to drive sustainable revenue?
  • Integration of MCPs (Modular Containerized Programs) with x402 payment rails for monetization is in progress.
  • Docker MCP catalog and toolkit for secure deployments is being developed.
  • A workflow assembly system similar to n8n for chaining MCPs together is planned.
1Revenue sharing model where plugin developers earn based on usage while elizaOS takes a platform fee.
Creates aligned incentives for ecosystem growth but complicates the payment architecture.
2Subscription tiers for MCP access with unlimited usage within tier limits.
Provides predictable revenue but may discourage experimental usage and exploration.
3Usage-based metering with progressive volume discounts and developer sandbox allocations.
Aligns cost with value creation but requires sophisticated monitoring and billing systems.
4Other / More discussion needed / None of the above.
Agent Ecosystem Expansion Strategy
The team is developing a curated agent directory, expanding agent capabilities through strategic partnerships, and addressing tokenomics issues with daos.fun to enhance the visibility and utility of the agent ecosystem.
Q4
How should we approach agent directory curation to balance quality control with ecosystem growth?
  • The team is developing a public map and website directory of vetted agents rather than implementing automatic agent registration.
  • Discussion about EIP-8004 and its potential integration with ElizaOS.
1Implement a permissioned system with manual curation by the core team to ensure quality and safety.
Ensures high-quality user experience but creates a bottleneck for scaling agent listings.
2Create a community-driven verification system with reputation-based endorsements and transparent metrics.
Distributes curation workload but requires sophisticated governance to prevent gaming.
3Adopt a tiered approach with minimal verification for basic listing and stricter review for featured status.
Balances openness with quality control but creates multiple standards to maintain.
4Other / More discussion needed / None of the above.
Q5
How should we prioritize partnership initiatives to maximize impact on agent adoption and ecosystem growth?
  • Collaboration announced with REVOX to give ElizaOS-powered AI agents human-like avatars with personality and emotion through their DEVA platform.
  • "Pump This Page" powered by Quantum was introduced, featuring quantitative and executional agents alongside a new Web Extension and tokenization feature.
1Focus on UX-enhancing partnerships like REVOX that make agents more engaging and accessible to mainstream users.
Accelerates consumer adoption but may delay enterprise/developer integrations.
2Prioritize developer tooling and integration partnerships that expand agent capabilities and use cases.
Strengthens platform functionality but may result in slower end-user growth.
3Concentrate on Web3/crypto partnerships that strengthen tokenization features and on-chain utility.
Deepens crypto integration but may limit appeal to Web2 developers and users.
4Other / More discussion needed / None of the above.
Q6
What approach should we take to resolve the ai16z token integration issues with daos.fun?
  • The ai16z token problem was identified as being related to daos.fun by design, not an ElizaOS problem.
  • "It's a daos.fun issue and it's by design, so they aren't likely to budge on it but we're working on a plan" (Odilitime)
1Develop a custom integration layer that adapts to daos.fun's design constraints while maintaining token functionality.
Avoids confrontation but adds technical complexity and maintenance overhead.
2Negotiate directly with daos.fun leadership for special consideration given elizaOS's ecosystem importance.
Could achieve optimal outcome but success depends on relationship dynamics and mutual benefit.
3Explore alternative platforms or build custom token functionality that doesn't rely on daos.fun.
Gives complete control but requires significant development resources and may fragment user experience.
4Other / More discussion needed / None of the above.
Technical Infrastructure Improvements
The team has completed a major milestone with the Scenario Matrix Runner and Reporting System, while addressing critical infrastructure improvements like cross-environment logging and asynchronous embedding generation.
Q7
How should we leverage the new Scenario Matrix Runner to enhance agent development and quality assurance?
  • This week marked a major milestone with the completion and closure of the entire Scenario Matrix Runner and Reporting System epic. This powerful new CLI tool enables comprehensive, automated testing of agent behaviors across various configurations and generates detailed performance reports in both HTML and PDF formats.
1Focus on establishing baseline performance metrics for all agents to enable consistent quality benchmarking.
Creates standardized quality metrics but may not capture domain-specific agent capabilities.
2Develop extensive scenario libraries that simulate real-world usage patterns to guide feature development.
Grounds development in real user needs but requires significant scenario design investment.
3Implement continuous integration testing with scenario runners to prevent regressions and maintain quality.
Automates quality assurance but increases build complexity and compute requirements.
4Other / More discussion needed / None of the above.
Q8
What technical optimizations should we prioritize to improve agent performance and responsiveness?
  • A feature to generate embeddings asynchronously via a queue service was proposed to improve performance in the bootstrap plugin.
  • The logger module was refactored to function seamlessly across both browser and Node.js environments.
1Prioritize end-user perceived latency improvements like asynchronous embeddings and response streaming.
Directly improves user experience but may delay backend optimizations.
2Focus on cross-platform compatibility and environmental adaptability for broader deployment options.
Expands addressable market but increases testing complexity and potential edge cases.
3Concentrate on memory and performance optimizations to reduce hosting costs and resource requirements.
Improves operating economics but may delay user-facing feature development.
4Other / More discussion needed / None of the above.
Q9
How should we approach verification and community infrastructure given the issues with Collab.land?
  • Potential switch from Collab.land to Vulcan.xyz due to verification issues was discussed.
  • jin suggested switching to Vulcan.xyz as Collab.land is "janky"
1Migrate completely to Vulcan.xyz for improved reliability and functionality.
Solves current issues but creates migration overhead and potential new dependencies.
2Develop a custom verification system integrated with our own token and identity infrastructure.
Provides complete control but requires significant development resources.
3Implement a multi-provider approach that supports both services and allows for graceful fallbacks.
Increases reliability through redundancy but adds integration complexity.
4Other / More discussion needed / None of the above.