# Council Briefing: 2025-01-31 ## 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 - A high-velocity stabilization push (tests, linting, and bug fixes) is underway, but it competes directly with an escalating trust-and-governance rupture around treasury behavior and partner tributes that risks undermining “Trust Through Shipping.” ## Key Points for Deliberation ### 1. Topic: Framework Reliability Under Hyper-Throughput **Summary of Topic:** GitHub velocity is extreme (Jan 2025: 1039 PRs / 401 issues / 694 contributors), and the team is landing meaningful fixes (vision provider handling, Telegram message collisions, service double-start prevention), yet recurring breakpoints (Windows installs, provider auth failures, Twitter client bugs) threaten the reliability narrative required for developer trust. #### Deliberation Items (Questions): **Question 1:** Do we formally shift from “feature absorption” to a stability gate (release train + stricter merge criteria) until core install and provider reliability meet a defined threshold? **Context:** - `GitHub monthly metrics: "1039 new PRs (735 merged), 401 new issues, and 694 active contributors." (elizaos/eliza, 2025-01-01..02-01)` - `Discord: "Installation challenges persist, particularly on Windows systems, with many users recommending Ubuntu instead." (2025-01-30 highlights)` **Multiple Choice Answers:** a) Yes—declare a 2–4 week “Stability Corridor” with a release train, freeze non-critical features, and enforce CI/test coverage for core + top clients. *Implication:* Improves perceived reliability quickly, but may slow ecosystem/plugin momentum and frustrate contributors. b) Partially—keep feature intake open, but require stability gates only for core runtime, adapters, and top-3 clients (Twitter/Discord/Telegram). *Implication:* Balances momentum and trust, but leaves long-tail breakages that can still damage brand reputation. c) No—optimize for velocity; rely on community to triage breakages and accept instability as the price of scale. *Implication:* Maximizes growth but risks violating “Execution Excellence,” driving serious builders to more stable alternatives. d) Other / More discussion needed / None of the above. **Question 2:** Which single developer-facing reliability pain should be treated as a flagship “trust repair” deliverable: Windows install, model-provider stability (DeepSeek/Anthropic/Twitter), or database/embeddings coherence? **Context:** - `Issues cited: "Twitter login failures (#3112), connection problems with the Anthropic model (#3079), authentication failures with the Deepseek API (#3013)." (repo issues summary)` - `Discord: "Fix the issue with embedding dimension mismatch (384 vs 1536)." (action items, 2025-01-30 coders)` - `Discord: "Improve ElizaOS Windows installation process" (Shelia, ideas-feedback-rants, 2025-01-30)` **Multiple Choice Answers:** a) Windows installation (and WSL2) as the primary trust repair target, with an official supported path and CI coverage. *Implication:* Broadens adoption and reduces onboarding friction, improving DX at the top of the funnel. b) Model-provider stability (Twitter auth + Anthropic/DeepSeek) as primary, because it affects running agents in production. *Implication:* Reduces public-facing agent failures and reputational damage, reinforcing “reliability” claims. c) Database/embeddings coherence (Postgres/Supabase schemas, dimension mismatches) as primary, because it impacts persistence and RAG correctness. *Implication:* Strengthens the “agent OS” foundation, but may be less visible to new developers than installation fixes. d) Other / More discussion needed / None of the above. **Question 3:** How should we contain plugin ecosystem entropy (huge plugin surface area, frequent lint/test churn) while preserving composability? **Context:** - `Daily GitHub: "A significant number of PRs were dedicated to fixing linting issues across various plugins" (2025-01-30 repo updates)` - `Discord action item: "Add configuration to select only needed plugins" (v1xingyue, 2025-01-30)` **Multiple Choice Answers:** a) Introduce “Core vs Registry” tiering: core ships only a minimal stable set; everything else moves to registry with versioned compatibility. *Implication:* Reduces breakage risk and install size, but requires governance and tooling for compatibility guarantees. b) Keep monorepo breadth, but enforce automated lint/test + a plugin CI matrix and deprecate noncompliant plugins. *Implication:* Improves quality without changing structure, but increases CI cost and maintainer burden. c) Adopt a “curated presets” approach: ship stable bundles (e.g., social, trading, governance) and let advanced users assemble custom stacks. *Implication:* Improves DX while keeping composability, but adds product surface area that must itself be maintained. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Treasury Conduct, Partner Tributes, and Governance Legibility **Summary of Topic:** A treasury management incident (selling donated/tribute tokens) triggered a legitimacy crisis; leadership justified emergency measures (protecting ai16z liquidity, funding $3–4M/year burn), but partners/community demanded clearer constraints. DUNA and Realms-based governance are emerging as structure, alongside a proposal for retroactive contributor airdrops using a basket of treasury tokens. #### Deliberation Items (Questions): **Question 1:** What treasury doctrine should be encoded for “tribute” tokens to prevent recurring partner conflict while preserving operational runway? **Context:** - `Discord: "Significant controversy emerged when Shaw ... sold tokens ... donated to the ai16z treasury" (2025-01-30 highlights)` - `witch: "Is the tribute system working properly? A: No, it's broken and needs to be fixed" (🥇-partners, 2025-01-30)` - `shaw: emergency measures to fund development ($3–4M/year) and protect token/liquidity (discussion/associates, 2025-01-29..30)` **Multiple Choice Answers:** a) Hard non-sale covenant for tributes (unless explicit partner contract allows), defaulting to holding or LP provisioning only. *Implication:* Maximizes partner trust but may constrain treasury flexibility during crises. b) Contractualized partner fee/tribute program: partners choose a predefined policy (sell/hold/LP/streamed vest) at tribute time. *Implication:* Creates clarity and reduces social conflict, but requires legal/contract engineering and enforcement. c) Treasury discretion retained, but with mandatory public policy + post-trade reporting and community veto windows. *Implication:* Preserves flexibility, but ongoing ambiguity may continue to erode partner confidence. d) Other / More discussion needed / None of the above. **Question 2:** Should DUNA be accelerated as a “trust anchor” now, even if it introduces operational overhead and forces faster policy decisions? **Context:** - `Rabbidfly: "DUNA ... protects DAOs while allowing for-profit activities and reasonable compensation" (2025-01-30 partners)` - `Discord: "The DAO is pursuing a DUNA legal structure in Wyoming" (2025-01-29..30 highlights)` **Multiple Choice Answers:** a) Yes—prioritize DUNA immediately to establish legal clarity, fiduciary norms, and partner confidence. *Implication:* Stabilizes external relationships and governance narrative but consumes leadership bandwidth. b) Proceed in parallel at moderate speed while first fixing tribute policy and operational transparency controls. *Implication:* Reduces immediate friction while still moving toward legal structure without derailing product execution. c) Defer DUNA until after core product milestones (Cloud + stability) to avoid governance process drag. *Implication:* Maximizes shipping velocity now, but leaves governance legitimacy exposed during further treasury events. d) Other / More discussion needed / None of the above. **Question 3:** How should retroactive contributor rewards be structured to strengthen developer-first incentives without creating perceived pay-to-play token complexity? **Context:** - `shaw: "retroactive airdrop system ... developers would receive a basket of treasury tokens" (🥇-partners, 2025-01-30)` - `Discord: ongoing confusion about partner requirements and token narratives (associates/discussion, 2025-01-29..30)` **Multiple Choice Answers:** a) Implement basket-based retroactive airdrops with simple scoring (merged PRs/reviews/issues), plus clear disclosure and opt-out. *Implication:* Aligns contributors with ecosystem projects while maintaining openness if explained well. b) Use stable, single-asset contributor grants (or salaries) and keep partner tokens separate from developer compensation. *Implication:* Reduces complexity and controversy, but weakens alignment between devs and partner ecosystem. c) Hybrid: small stable grants + optional “alignment allocation” of partner tokens for contributors who opt in. *Implication:* Balances clarity and alignment, but requires more administrative and technical machinery. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Taming Information: Automated Comms, Q&A Extraction, and Trust Through Documentation **Summary of Topic:** Information infrastructure is becoming a strategic lever: Jin’s AI news aggregator and Discord Q&A extraction efforts can reduce support load and improve agent quality, but reliability gaps (aggregator daily.json not updating) and unclear official messaging (ElizaOS vs ai16z token identity) threaten confidence. #### Deliberation Items (Questions): **Question 1:** Should the Council treat “Information Taming” systems (news aggregator + Q&A pipeline) as a core product deliverable with SLOs, rather than an auxiliary community project? **Context:** - `jin: "demonstrated an AI-powered news aggregator that automatically generates ecosystem newsletters" (🥇-partners, 2025-01-30)` - `boom: "Fix the AI news aggregator that's not updating its daily.json file" (3d-ai-tv action items, 2025-01-30)` - `dankvr: shared process for extracting Q&A from dev channels to enhance documentation for LLMs (Twitter activity summary, 2025-01-30)` **Multiple Choice Answers:** a) Yes—promote it to a core reliability target with uptime/refresh SLOs and an owner, because it feeds docs and agent correctness. *Implication:* Strengthens DX and reduces support overhead, but diverts resources from framework runtime work. b) Partially—support it as a reference implementation (flagship internal agent) but do not guarantee SLOs yet. *Implication:* Keeps momentum without binding commitments, but failures may still reflect poorly if treated as “official.” c) No—keep it community-run until core platform stability is achieved; focus on docs improvements directly in the repo. *Implication:* Protects core roadmap focus, but misses an opportunity to operationalize “documentation as a first-class citizen.” d) Other / More discussion needed / None of the above. **Question 2:** How do we resolve identity confusion (ElizaOS brand vs $ai16z token) to reduce onboarding and marketing friction during rebrand and token-related operations? **Context:** - `Discord: "rebranded to ElizaOS ... while maintaining ai16z as the token ticker, causing some marketing confusion" (2025-01-29 highlights)` - `Smedroc: "It's definitely not $Eliza... ai16z until further notice" (associates, 2025-01-30)` - `Action item: "Complete X account rebranding ... and clearly indicate $ai16z as the token" (HoneyBadger/Burtiik, 2025-01-30)` **Multiple Choice Answers:** a) Adopt a strict naming schema across all surfaces (docs, X bios, website): “ElizaOS (framework/cloud), $ai16z (token)” with a single canonical explainer. *Implication:* Reduces confusion quickly and reinforces credibility, but may constrain future ticker changes. b) Accelerate ticker/name change to unify brand and token identity, even if it introduces coordination risk. *Implication:* Long-term coherence improves, but execution risk is high and may amplify short-term confusion. c) Defer messaging cleanup until post-launchpad/tokenomics release; tolerate ambiguity for speed. *Implication:* Minimizes immediate work, but ongoing confusion undermines trust and partner/business development. d) Other / More discussion needed / None of the above. **Question 3:** What is the Council’s stance on converting Discord support patterns into “agent-readable doctrine” (FAQ/RAG-ready docs), and how aggressively should we automate it? **Context:** - `jin: "extracted questions and answers from chat history going back to 12-10-24" (discussion/associates, 2025-01-30)` - `dankvr: "extracting Q&A from developer channels to enhance documentation for LLMs" (Twitter activity summary, 2025-01-30)` - `Discord recurring issues: Windows install, embeddings mismatch, provider config questions (💻-coders, 2025-01-30)` **Multiple Choice Answers:** a) High automation: nightly ingestion + dedup + human review queue; publish as versioned FAQ datasets for agents and docs. *Implication:* Rapidly improves support and agent performance, but requires editorial governance to prevent misinformation. b) Moderate automation: weekly curated releases only, prioritizing the top 20 recurring issues and official fixes. *Implication:* Maintains accuracy and trust, though slower to capture emergent edge cases. c) Manual-only: keep Q&A extraction as ad hoc human documentation work to minimize accidental policy drift. *Implication:* Ensures tight control, but scales poorly and undermines the “Taming Information” strategic advantage. d) Other / More discussion needed / None of the above.