# Council Briefing: 2025-04-01 ## Monthly Goal December 2025: Execution excellence—complete token migration with high success rate, launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability and clear documentation. ## Daily Focus - Stability and developer trust are being reforged through rapid v2 hardening (Telegram + plugin workflows + provider integrations), while recurring ecosystem confusion (token messaging, social reliability) threatens perceived reliability if not resolved decisively. ## Key Points for Deliberation ### 1. Topic: V2 Reliability & Developer Experience Hardening **Summary of Topic:** Engineering momentum is high (new providers, embedding model selection, plugin publishing workflow improvements), but field reports show persistent friction: installation/platform quirks, unclear v2 architecture docs, and agent lifecycle/storage confusion—directly impacting developer trust. #### Deliberation Items (Questions): **Question 1:** What is the Council’s definition of “v2 launch-ready” under Execution Excellence: feature-complete, or failure-intolerant stable for common paths (create → run → deploy → observe)? **Context:** - `Discord (Dev): “V2 Architecture Migration… ‘clients’ have been replaced with ‘plugins + services’” (mekpans helping standard, 2025-03-31)` - `Discord (Dev School): confusion on “where agents created via CLI are stored in v2dev” (mindxploit, 2025-03-31)` - `GitHub Daily Update (2025-04-01): “Improved plugin publishing workflow to enhance the developer experience” (#4132)` **Multiple Choice Answers:** a) Define launch-ready as stability for the top 3 developer journeys (local dev, plugin install, social client run) with strict error budgets. *Implication:* Focuses the fleet on reliability and documentation, increasing trust even if some features slip. b) Define launch-ready as parity with v1 capabilities plus new v2 architecture, even if rough edges remain. *Implication:* Maximizes feature narrative but risks churn if first-time runs fail or docs diverge from reality. c) Define launch-ready as “dogfooding-only” for a fixed burn-in period; publicly label as preview until metrics are met. *Implication:* Protects reputation while enabling iteration, but may slow ecosystem adoption and partner timelines. d) Other / More discussion needed / None of the above. **Question 2:** Which single DX bottleneck should be elevated to a “mission-critical blocker” to preserve developer trust: installation/CLI behavior, plugin import resolution across OSes, or documentation alignment for v2? **Context:** - `Discord (Dev): “Plugin import errors… workaround… replace `@import` with hardcoded paths” (Tiki, 2025-03-30)` - `GitHub Issues: “How to run Eliza CLI?” (#4159) and “Quickstart doc issues” (#4336)` - `Discord (Main): “Recommended installation method changed… npm global → git clone v2-develop + bun” (2025-03-29/30)` **Multiple Choice Answers:** a) Make CLI/installation determinism the blocker (single blessed install path; consistent start/dev commands). *Implication:* Reduces onboarding failure rate fastest and lowers community support load. b) Make cross-platform plugin import/module resolution the blocker (Linux/WSL/macOS parity). *Implication:* Prevents silent ecosystem fragmentation and hard-to-debug community failures. c) Make docs/implementation alignment the blocker (v2 architecture, agent storage, plugin registry policy). *Implication:* Improves comprehension and self-serve support, but may not stop immediate runtime failures. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should we expand model/provider integrations (Kluster AI, Mem0, DeepSeek) versus consolidating around a smaller “golden path” for reliability? **Context:** - `GitHub Daily Update (2025-04-01): “Integrated Kluster AI as a model provider” (#3938) and “Added Mem0 as an AI SDK provider” (#3927)` - `Discord (Dev): “How to use DeepSeekAI for V2… use DEEPSEEK_API_KEY env var” (loyce.eth / Sashimikun, 2025-03-31)` - `Discord (Coders): repeated provider issues (Anthropic rate limits; OpenRouter ‘hacky’ plugin) (2025-03-30/31)` **Multiple Choice Answers:** a) Consolidate: bless 2–3 providers and harden docs/tests/telemetry before expanding further. *Implication:* Raises reliability and simplifies support, but slows composability narrative. b) Expand: keep integrating providers rapidly, but enforce plugin conformance tests and version gates. *Implication:* Maintains open/composable leadership while containing blast radius via tooling. c) Hybrid: expand providers only via community-maintained plugins, while core maintains a strict golden path. *Implication:* Scales ecosystem without overloading core team, but may produce uneven quality perception. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Social Surfaces Stability (Twitter/Telegram) as Trust Multipliers or Reputation Hazards **Summary of Topic:** Telegram capabilities improved materially (community manager, middleware docs, sync fixes), while Twitter remains a reliability and cost sink (redundant checks, mention handling, account suspensions). These surfaces shape public perception more than core commits. #### Deliberation Items (Questions): **Question 1:** Should the Council treat Twitter and Telegram as “flagship reliability surfaces” requiring tighter release gates than other plugins, given their outsized reputation impact? **Context:** - `GitHub Daily Update (2025-04-01): Telegram upgrades—community manager (#4134), middleware docs/sync (#4128)` - `GitHub New Issue (2025-04-01): “Twitter plugin… redundant checks… unnecessary API calls” (#4127)` - `Discord (Partners/Main): “ai16zNEWS Twitter account was suspended… posts reaching 100k views” (2025-03-31)` **Multiple Choice Answers:** a) Yes—treat as flagship surfaces with stricter CI, canary releases, and required observability. *Implication:* Reduces public failures and cost blowups, strengthening “trust through shipping.” b) Partially—tighten Telegram (utility) but keep Twitter experimental due to X platform volatility. *Implication:* Preserves momentum while acknowledging platform risk, but may weaken marketing automation. c) No—keep equal treatment; prioritize core runtime and let community iterate on social plugins. *Implication:* Speeds core development but increases likelihood of public-facing failures and confusion. d) Other / More discussion needed / None of the above. **Question 2:** What is the preferred mitigation strategy for API rate limits and “cost spikes” causing agent crashes: multi-provider failover, smarter prompt budgets, or throttled job queues? **Context:** - `Discord (Coders): “Anthropic API rate limit… causing agent crashes… switch providers/reduce prompt length” (2025-03-30/31)` - `GitHub Daily Update (2025-04-01): multiple refactors/bugfixes, but still surface-level instability in social usage` - `Discord (Coders): VRAM issues and local model struggles affecting reliability (2025-03-30/31)` **Multiple Choice Answers:** a) Implement multi-provider failover with priority routing and graceful degradation. *Implication:* Improves uptime but adds complexity and testing burden across providers. b) Enforce prompt budgets and structured outputs to reduce token pressure and retries. *Implication:* Lowers costs and rate-limit risk while improving predictability, possibly at quality cost. c) Adopt throttled queues/backpressure (and clearer user-facing errors) to prevent crashes. *Implication:* Stabilizes runtime under load, but may slow responsiveness and require UX messaging. d) Other / More discussion needed / None of the above. **Question 3:** How should we handle “undesired interactions” and safety controls (blocking accounts, preventing promotion of questionable projects) without turning ElizaOS into a closed system? **Context:** - `GitHub Issues Summary: “HOW do we block and ban interactions with specific accounts???” (#4117, closed)` - `Discord (Partners): “Improve AI prompting to prevent agents from promoting questionable projects” (jin, 2025-03-31)` - `Discord (Dev): “Security concerns… potential scam links” (Veight assisting ElizaBAO, 2025-03-31)` **Multiple Choice Answers:** a) Ship first-class policy and safety primitives (blocklists, verification hooks, provenance checks) in core. *Implication:* Raises baseline safety and trust, but increases scope and governance over defaults. b) Provide reference plugins/patterns only; leave enforcement to deployers (opt-in safety). *Implication:* Preserves openness and composability, but increases risk of public incidents by novices. c) Create “safe mode” profiles (strict defaults) with an explicit switch for advanced users. *Implication:* Balances safety and freedom while giving clear expectation management to builders. d) Other / More discussion needed / None of the above. --- ### 3. Topic: auto.fun Launch Readiness & Token/DAO Narrative Coherence **Summary of Topic:** Auto.fun is framed as imminent (“two weeks,” ~Apr 14) with 15 launch partners and ai16z buyback utility, yet community confusion persists on token relationships and DAO status. Narrative incoherence is now a strategic risk to developer and holder trust. #### Deliberation Items (Questions): **Question 1:** What is the Council’s canonical public narrative for the token and platform relationship (ai16z ↔ ElizaOS ↔ auto.fun), and how will it be enforced across docs/social/AMA? **Context:** - `Discord (Main): “There will not be a new token, the token stays $ai16z.” (7OROY, 2025-03-31)` - `Discord (Main): “Profits from auto.fun will be used to buy back ai16z tokens” (jin, 2025-03-31)` - `Discord (Main): Confusion after “auto.fun has no native token” messaging (2025-03-29)` **Multiple Choice Answers:** a) Publish a single “Token Relationship & Value Flow” spec (diagram + FAQ) and treat it as source of truth. *Implication:* Reduces confusion and rumor cycles, improving trust and partner onboarding. b) Keep messaging minimal until launch; answer only when asked to avoid over-commitments. *Implication:* Avoids premature promises but allows confusion to persist and compound. c) Split narratives: developer-facing ElizaOS neutrality; holder-facing ai16z utility via auto.fun buybacks. *Implication:* Clarifies audiences but risks perception of misalignment if not tightly coordinated. d) Other / More discussion needed / None of the above. **Question 2:** How should progressive decentralization be staged given we are “not a DAO (yet)” but operate in DAO-adjacent spaces (daos.fun), and what near-term governance tools are acceptable? **Context:** - `Discord (dao-organization): “We’re not a DAO (yet). Weaving a community is a delicate art and science.” (vincentpaul, 2025-03-31)` - `Discord (dao-organization): references to MetaDAO/MNTDAO decision markets as models (Ka_yari, 2025-03-31)` **Multiple Choice Answers:** a) Publish a phased decentralization roadmap (milestones, powers, guardrails) and begin with information governance (summaries, proposals). *Implication:* Builds legitimacy through transparency while keeping execution centralized enough to ship reliably. b) Delay formal governance; focus solely on shipping auto.fun + v2 reliability, revisit DAO framing later. *Implication:* Maximizes execution focus but may frustrate community members seeking clarity and participation. c) Pilot limited decision markets/bounties for specific modules (plugins, docs) while explicitly excluding treasury control. *Implication:* Tests governance primitives safely, but requires careful scoping to avoid “DAO theater” accusations. d) Other / More discussion needed / None of the above. **Question 3:** Given upcoming previews (HK/Paris) and launch partners, what is the acceptable launch risk posture: ship on time with known rough edges, or delay for a higher reliability threshold? **Context:** - `Discord / Daily Summary: “@autodotfun is ready to launch with partners in two weeks… previewed in Hong Kong and Paris” (2025-03-31)` - `Discord (Main): “Why delay?” and launch-day uncertainty questions appear repeatedly (2025-03-31)` **Multiple Choice Answers:** a) Ship on schedule with a tight scope and clear limitations; prioritize uptime and incident response readiness. *Implication:* Captures momentum and partner timelines while containing blast radius through scope control. b) Delay until reliability metrics are met (successful launches, monitoring, rollback plans validated). *Implication:* Protects long-term trust but risks narrative damage and partner churn if delays compound. c) Stage the launch: private/partner-only mainnet first, then public launch after a measured burn-in. *Implication:* Balances deadlines and quality, but requires disciplined access control and communications. d) Other / More discussion needed / None of the above.