▶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

Core development teams are advancing critical technical infrastructure improvements for elizaOS v2 while navigating ongoing token migration challenges that impact community sentiment and exchange relationships.

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

Technical Architecture Enhancements

Development efforts are focused on critical improvements to plugin memory architecture, authentication, and streaming capabilities, with discussions about cost-effective scaling through multi-agent server hosting rather than isolated serverless instances.

How should we prioritize the implementation of streaming functionality in elizaOS v2 given its potential impact on user experience?

0xbbjoker outlined specific tasks for plugin-memory, including figuring out table migrations for cloud and tailoring architecture to specific tasks.
Odilitime suggested using a 'stream: true' parameter in the runtime.ts file for implementing streaming without rewriting the entire framework.

1Immediately implement streaming as a core feature using the suggested 'stream: true' parameter approach to enhance real-time agent interactions.

Prioritizing streaming could dramatically improve user perception of agent responsiveness but may delay other critical architecture work.

2Focus first on completing plugin-memory architecture and authentication improvements before adding streaming capability.

This approach ensures a more stable foundation but delays a feature that could significantly enhance perceived agent intelligence and responsiveness.

3Develop streaming in parallel with other architecture work by assigning a dedicated team to this specific feature.

Parallel development could accelerate delivery of all features but risks creating integration challenges between components developed simultaneously.

4Other / More discussion needed / None of the above.

Should we transition from isolated serverless instances to hosting multiple agents on fewer servers to reduce operational costs?

Discussions about hosting multiple agents on single/few elizaOS servers instead of isolated serverless instances for each user, which could potentially reduce costs.

1Transition immediately to a multi-agent server architecture to optimize costs while maintaining reasonable isolation boundaries.

Could significantly reduce operational costs but introduces new security and resource contention challenges that must be managed.

2Continue with isolated serverless instances to maintain perfect security isolation while exploring cost optimizations elsewhere.

Preserves the current security model but keeps operational costs high, potentially limiting long-term sustainability.

3Develop a hybrid model where certain agent types share servers while others (e.g., those with sensitive data) remain isolated.

Balances cost reduction with security needs but introduces complexity in deployment and resource allocation decisions.

4Other / More discussion needed / None of the above.

How should we approach the implementation of multi-user authentication in elizaOS to balance security with ease of integration?

Stan provided an update on their work introducing per-user authentication validation on the server with generic JWK provider support (including Privy).

1Standardize on the current JWK provider approach and make it the only supported authentication method.

Simplifies the codebase and security model but may limit integration options for some developers.

2Support multiple authentication methods through a plugin architecture that developers can extend.

Maximizes flexibility for different use cases but increases security review burden and potential for vulnerabilities.

3Implement a tiered authentication system with simple methods for basic use cases and more secure options for sensitive applications.

Balances ease of use with security needs but requires clear documentation of security implications for each method.

4Other / More discussion needed / None of the above.

ElizaCloud Marketplace Strategy

Discussions around ElizaCloud's business model suggest implementing a marketplace similar to Salesforce AppExchange or Apple App Store with revenue sharing from third-party developers and standardized URL structures for agents.

What revenue sharing model should ElizaCloud implement for third-party developers to balance platform sustainability with developer incentives?

Suggestions for revenue sharing with third-party developers (30% platform cut)
DorianD suggested implementing a marketplace model (like Salesforce AppExchange/Apple App Store) with revenue sharing for third-party developers

1Implement a standard 30% revenue share model similar to established app stores.

Follows proven industry models but may deter some developers who are accustomed to more favorable terms in Web3.

2Adopt a tiered model where ElizaOS takes a smaller percentage from smaller developers and increases the cut as revenue grows.

Could attract more developers initially but adds complexity to the system and may reduce predictable revenue streams.

3Implement a token staking model where developers stake ElizaOS tokens instead of paying direct revenue shares.

Creates additional utility and demand for the ElizaOS token but may make the platform less accessible to developers without tokens.

4Other / More discussion needed / None of the above.

How should we structure agent URLs and discovery in ElizaCloud to maximize user engagement and platform growth?

Proposals for standardized URL structures for agents (e.g., 'https://www.elizacloud.ai/agent/[agentname]')
DorianD also inquired about URL structures for agents on the platform.

1Implement a social network-like structure with standardized URLs and strong discoverability features.

Enhances agent discoverability and social sharing but may position the platform too similarly to existing social networks.

2Create an application-centric structure with agents organized by function rather than creator.

Emphasizes utility over social aspects and may appeal more to enterprise users seeking specific solutions.

3Develop a hybrid model with both creator profiles and functional categories, with corresponding URL structures.

Provides maximum flexibility but could create a less focused user experience and complicate SEO strategy.

4Other / More discussion needed / None of the above.

Token Migration and Exchange Relations

The ongoing migration from AI16Z to ElizaOS tokens with a 6:1 conversion ratio is creating challenges as exchanges like Kraken pause trading while evaluating support for the migration, affecting user sentiment and requiring clear communication strategies.

How should we address the exchange listing challenges for ElizaOS tokens to improve liquidity and accessibility?

Kraken exchange announced pausing AI16Z trading while evaluating whether to support the migration
Community sentiment about ElizaOS price performance was mixed, with some believing it has bottomed out while others warned of potential further decline

1Focus on supporting existing exchange relationships through enhanced communication and technical support for the migration process.

Preserves existing liquidity channels but doesn't address the need for wider exchange availability.

2Aggressively pursue new exchange listings with targeted incentives and simplified technical integration requirements.

Could expand accessibility but requires significant resources and may dilute focus from product development.

3Develop decentralized liquidity solutions through automated market makers and liquidity pools to reduce dependency on centralized exchanges.

Aligns with decentralization values but may limit access for mainstream users unfamiliar with DeFi mechanisms.

4Other / More discussion needed / None of the above.

What strategy should we implement to address community concerns about token value and migration challenges?

Some users reported issues with the migration process and were directed to support channels
Concerns about unresolved tickets regarding AI16Z tokens held on Kraken

1Create comprehensive migration guides and dedicated support resources specifically for exchange-related migration issues.

Addresses immediate pain points but doesn't solve the underlying concerns about token value and exchange support.

2Implement new utility features for ElizaOS tokens that create tangible value regardless of exchange listings.

Could improve long-term token value but doesn't solve immediate migration accessibility problems.

3Launch a community ambassador program where experienced community members help others with migration while earning rewards.

Leverages community resources to scale support while building stronger community bonds and token utility.

4Other / More discussion needed / None of the above.

Council Briefing

North Star & Strategic Context

Key Deliberations