# Council Briefing: 2025-01-30 ## 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-throughput stabilization push landed across core and plugins (linting, reliability fixes, adapter/client hardening), but the Council’s strategic risk remains trust erosion from unresolved treasury/governance policy ambiguity and platform reliability pain (providers, installs). ## Key Points for Deliberation ### 1. Topic: Reliability Surge: Core + Plugin Stabilization at Scale **Summary of Topic:** Engineering velocity is exceptionally high, with a large volume of merges focused on linting, bug fixes, and integration stability (Telegram collisions, Deepgram null checks, Slack↔Postgres constraints), aligning with Execution Excellence but risking "motion without predictability" unless release discipline and test gates harden. #### Deliberation Items (Questions): **Question 1:** Do we prioritize a short-term "stability freeze" (release hardening) over continued plugin expansion to protect developer trust? **Context:** - `GitHub activity: "From January 29-30, 2025, there were 50 new pull requests with 47 merged..." (github_summary)` - `Daily update: "Resolved multiple linting issues across various plugins... Fixed a message ID collision issue in the Telegram client" (ElizaOS Daily Update Jan 30, 2025)` **Multiple Choice Answers:** a) Declare a 1–2 week stability freeze: only bugfixes, tests, docs, and release-candidate validation. *Implication:* Improves predictability and reduces regression risk, but may slow ecosystem excitement and partner integrations. b) Continue current merge velocity but enforce stricter CI gates (tests/coverage, canaries) before merge. *Implication:* Maintains momentum while raising quality, but requires tooling investment and reviewer bandwidth. c) Keep shipping broadly; accept regressions as the cost of rapid ecosystem growth. *Implication:* Maximizes feature breadth short-term, but undermines Execution Excellence and risks developer churn. d) Other / More discussion needed / None of the above. **Question 2:** What is our canonical definition of “done” for a plugin in the registry (minimum tests, docs, security posture)? **Context:** - `New issues: "need for comprehensive test coverage for the Chainbase plugin" and "lack of testing for plugin-bootstrap" (ElizaOS Daily Update Jan 30, 2025)` - `GitHub summary: "Multiple plugins received test configuration and coverage enhancements" (Recent ElizaOS GitHub Activity Summary)` **Multiple Choice Answers:** a) Require baseline tests + coverage threshold + README + example character/config before listing as "stable". *Implication:* Creates a trusted ecosystem tier, improving DX and reducing support load. b) Adopt a tiered maturity model: Experimental (no guarantees), Beta (docs), Stable (tests + audits). *Implication:* Balances openness with clarity; needs governance of labeling and enforcement. c) Keep requirements minimal (README only) to maximize contributions and iterate later. *Implication:* Increases plugin count quickly but externalizes risk to builders, harming trust through instability. d) Other / More discussion needed / None of the above. **Question 3:** Should we consolidate high-change areas (Twitter, DB adapters, model providers) into an explicit “Reliability Program” with owners and SLAs? **Context:** - `Bugfixes: "Fixed client-slack & adapter-postgres connection issues" and "Fixed tweet reply functionality" (GitHub Activity Summary)` - `Discord: recurring issues with Twitter hiding replies, auth challenges, and DB configuration confusion (elizaOS Discord 2025-01-29)` **Multiple Choice Answers:** a) Yes—establish a Reliability Program with named owners, incident triage, and regression tests for top flows. *Implication:* Creates a durable reliability moat and aligns with Execution Excellence, but requires sustained staffing. b) Partially—focus only on Twitter + Postgres + embeddings as “golden paths,” leave others best-effort. *Implication:* Targets the highest pain points quickly, but may neglect emerging critical integrations. c) No—keep reliability as a distributed responsibility without formal program structure. *Implication:* Lower process overhead, but reliability becomes inconsistent and reactive at current scale. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Provider & Platform Resilience: DeepSeek/Embeddings/Install Friction **Summary of Topic:** Operational friction persists around model provider outages (DeepSeek), embedding dimension mismatches, and Windows installation failures—directly threatening “developer-friendly” positioning and increasing support burden; mitigation requires clearer defaults, robust fallbacks, and canonical deployment guides. #### Deliberation Items (Questions): **Question 1:** How aggressively should we engineer provider failover (OpenRouter fallback, multi-provider routing) versus documenting workarounds? **Context:** - `Discord: "Deepseek has been down for several days" (Mr. Stark, 💻-coders, 2025-01-29)` - `Discord: "Use DeepSeek via OpenRouter" workaround shared (2025-01-28/27 discussions)` **Multiple Choice Answers:** a) Build first-class provider failover/routing into core runtime (automatic fallback + health checks). *Implication:* Improves reliability and Cloud readiness, but adds architectural complexity and testing surface. b) Provide an official “resilience recipe” (recommended provider stack + OpenRouter) without deep core changes. *Implication:* Faster time-to-relief for builders, but still leaves reliability uneven across deployments. c) Treat provider downtime as out-of-scope; focus on core features and let users self-manage providers. *Implication:* Reduces internal scope but conflicts with reliability-first principle and hurts trust. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s decision on the canonical embedding path to eliminate “vector dimension mismatch” failures? **Context:** - `Discord: "Vector dimension mismatch" fix suggested: "Set USE_OPENAI_EMBEDDING=TRUE" (mike🇭🇺, 2025-01-29)` - `Discord: Alternative advice: "Switch to Postgres with Supabase instead of SQLite" (2025-01-28 Q&A)` **Multiple Choice Answers:** a) Standardize on one default embedding model/dimension and enforce validation + migration tooling. *Implication:* Eliminates a major class of runtime errors, but may constrain experimentation without explicit opt-in. b) Support multiple embedding dimensions but add auto-detection, per-store metadata, and safe re-embed workflows. *Implication:* Maximizes flexibility and composability, but increases implementation and QA complexity. c) Leave embeddings as user-configured; address via documentation and FAQ only. *Implication:* Lowest engineering cost, but ongoing support churn and poor first-run experience persist. d) Other / More discussion needed / None of the above. **Question 3:** Do we treat Windows as a first-class supported environment for v1.x, or explicitly narrow support to WSL/Ubuntu until v2? **Context:** - `Discord: "Windows users experienced significant installation problems, with some switching to Ubuntu" (2025-01-29 highlights)` - `ideas-feedback-rants: Windows installation frustration reported by Shelia (2025-01-29)` **Multiple Choice Answers:** a) First-class Windows support now: dedicated guide + CI matrix + installer fixes as top priority. *Implication:* Expands developer reach and reduces friction, but diverts resources from Cloud/launchpad deliverables. b) WSL-first: officially recommend WSL/Ubuntu for Windows users with a polished WSL setup path. *Implication:* Pragmatic reliability improvement quickly, while still serving Windows-based developers. c) Defer: no formal Windows support until v2 architecture stabilizes. *Implication:* Reduces immediate workload, but risks reputational damage and lost builders during growth. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Trust & Governance: Treasury Handling, Partner Fees, and DAO Legibility **Summary of Topic:** The partner-token liquidation controversy exposed a governance and trust fault line: emergency treasury actions were taken (per Shaw) but community rejected the proposal; the Council must formalize treasury policy, implement governance mechanisms, and align the ElizaOS brand/ticker narrative to prevent repeated legitimacy shocks. #### Deliberation Items (Questions): **Question 1:** What treasury policy should govern “partner tributes” to prevent future trust breaches while preserving runway? **Context:** - `Discord: "Treasury Management Crisis... community ultimately rejected the proposal to sell partner tokens, with Shaw canceling the proposal" (2025-01-29 highlights)` - `Discord: Shaw: filtered tokens by criteria ("less than 5% holdings, under $20K value, or unknown projects") (2025-01-29 Q&A)` **Multiple Choice Answers:** a) No-sale policy: tribute tokens must be held or LP’d only; any sale requires explicit partner consent + vote. *Implication:* Maximizes partner trust, but reduces treasury flexibility during market crises. b) Programmatic partner fee model: accept fees in SOL/USDC or predefined vesting/sale schedules via contract. *Implication:* Creates predictable funding and removes ambiguity, but may reduce inbound “token tribute” partnerships. c) Discretionary treasury mandate: allow emergency sales within a published threshold and post-hoc reporting. *Implication:* Maintains crisis agility, but trust risk remains high without robust governance legitimacy. d) Other / More discussion needed / None of the above. **Question 2:** Which governance mechanism best fits our near-term execution needs: Realms deposit-based voting, an alternative voting system, or interim multisig council control? **Context:** - `Discord: "implementing a DAO voting mechanism using Realms.today, which requires token deposits for governance power" (2025-01-29 highlights)` - `Action items: "Implement a proper multisig wallet setup for treasury management" (mattyryze, 2025-01-29)` **Multiple Choice Answers:** a) Proceed with Realms deposit-based voting as planned; optimize UX and educate users on deposits. *Implication:* Fast path to on-chain governance, but may deter participation and amplify centralization concerns. b) Adopt a non-deposit governance model (snapshot-style) and delay on-chain deposit requirements. *Implication:* Increases accessibility and trust, but may be weaker against sybil/whale dynamics without safeguards. c) Interim multisig stewardship with published emergency powers; migrate to full DAO once stable. *Implication:* Improves operational speed and accountability short-term, but requires strong transparency to avoid backlash. d) Other / More discussion needed / None of the above. **Question 3:** How do we resolve brand/ticker confusion to protect developer adoption and partner negotiations? **Context:** - `Discord: "rebranded to ElizaOS (framework) while maintaining ai16z as the token ticker, causing some marketing confusion" (2025-01-29 highlights)` - `Action items: "Fix X (Twitter) handles to clearly associate ElizaOS with the ai16z token" (HoneyBadger, 2025-01-29)` **Multiple Choice Answers:** a) Maintain ticker for now; invest in clear messaging, handles, and docs linking ElizaOS ↔ ai16z. *Implication:* Minimizes disruption while improving legibility, but may not fully eliminate confusion. b) Fast-track a community vote and migration plan for a ticker change aligned with ElizaOS branding. *Implication:* Creates coherence and reduces legal/brand risk, but introduces migration complexity and market volatility. c) Decouple product from token narrative: position token as optional governance/economic layer, not identity. *Implication:* Improves enterprise/OSS neutrality, but could reduce perceived token utility and community cohesion. d) Other / More discussion needed / None of the above.