# Council Briefing: 2025-03-14 ## 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 surged via rapid merges improving RAG knowledge loading, WebSocket/DM reliability, and UI diagnostics—yet developer trust remains gated by unresolved Docker/onboarding friction and ongoing client/plugin confusion ahead of the V2 launch window. ## Key Points for Deliberation ### 1. Topic: V2 Launch Readiness & Core Reliability **Summary of Topic:** Engineering momentum is strong (notably fixes to RAG knowledge loading, WebSocket reliability, and type safety), aligning with Execution Excellence; however, open operational risks (Docker deployment, client disconnections, plugin inconsistencies) threaten perceived reliability at release time. #### Deliberation Items (Questions): **Question 1:** Do we freeze V2 scope to reliability-only changes until post-launch, even if it delays multi-agent and multichain showcases? **Context:** - `Discord (2025-03-13): V2 planned with "multi-agent systems" and "improved multichain support" (community summary).` - `GitHub (2025-03-14): "Fixed RAG Knowledge loading" (PR #3932) and "Resolved websocket issues" (PR #3924).` **Multiple Choice Answers:** a) Yes—impose a reliability freeze (bugs, tests, docs only) until the first stable V2 tag ships. *Implication:* Maximizes Trust Through Shipping but may reduce initial wow-factor and ecosystem momentum. b) No—continue feature merges, but require release gating with must-pass integration tests and rollback paths. *Implication:* Preserves roadmap velocity while accepting higher coordination overhead and a steeper risk curve. c) Split the release: ship a minimal stable V2 core, then fast-follow with feature packs (multi-agent/multichain) as opt-in modules. *Implication:* Balances reliability and ambition, but requires crisp modular boundaries and versioning discipline. d) Other / More discussion needed / None of the above. **Question 2:** What is our release criterion for “reliable” in the eyes of developers: fewer open bugs, fewer support pings, or measurable runtime stability? **Context:** - `GitHub (2025-03-14): "Introduced stronger types" (PR #3931) and multiple UI/runtime fixes (#3926, #3925).` - `Discord (2025-03-13 coders): frequent troubleshooting for Discord/Twitter clients and disconnections (channel analysis).` **Multiple Choice Answers:** a) Define reliability via objective telemetry: crash-free sessions, reconnection rates, and CI pass rates as release gates. *Implication:* Creates a durable quality bar but requires instrumenting and reporting metrics quickly. b) Define reliability via support load: reduce repeated Discord support topics (Docker, Twitter, Discord auth) below a threshold. *Implication:* Optimizes for developer sentiment, but can be noisy and influenced by documentation gaps rather than code. c) Define reliability via issue hygiene: strict SLAs on top issues (e.g., 48–72h to close blockers) leading into release. *Implication:* Improves responsiveness optics, but may incentivize shallow fixes or premature closures. d) Other / More discussion needed / None of the above. **Question 3:** Given recurring client transport churn (WebSockets/WSS/Socket.io), should the Council mandate a single blessed realtime transport for V2 and Cloud? **Context:** - `GitHub updates: "Implemented client WSS support" (PR #3902) and "Resolved websocket issues with bun run start" (PR #3924).` - `Monthly code list: "feat: use socketio, remove wss" (PR #3946).` **Multiple Choice Answers:** a) Yes—standardize on one transport (e.g., Socket.io) across GUI, local runtime, and Cloud immediately. *Implication:* Reduces fragmentation and support burden but risks destabilizing recent fixes if rushed. b) Partially—bless one default transport but keep an escape-hatch transport behind a stable interface/adapter. *Implication:* Preserves compatibility while improving DX; requires clean abstraction and documentation. c) No—allow multiple transports to coexist until Cloud constraints force convergence. *Implication:* Maximizes flexibility but sustains ongoing confusion, duplicated fixes, and inconsistent bug surfaces. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Developer Experience: Onboarding, Docker, and Plugin Clarity **Summary of Topic:** Community signals show the same onboarding failures repeating (Docker deployment, plugin registration, branch stability confusion), directly conflicting with Developer First; recent doc cleanups help, but the operational choke points remain highly visible. #### Deliberation Items (Questions): **Question 1:** Should we prioritize a single “golden path” install (Docker or native) and treat the other as best-effort until after V2 stabilization? **Context:** - `Discord (2025-03-13): "Multiple users reported difficulties deploying Eliza on Docker" (discussion highlights).` - `Discord (2025-03-11): plugin registration now required; "wasn't clearly documented" (summary).` **Multiple Choice Answers:** a) Golden-path Docker: make Docker the canonical install for reliability and reproducibility. *Implication:* Simplifies support and Cloud alignment, but must fix current Docker pain immediately to avoid backfire. b) Golden-path native: optimize pnpm/bun local dev and provide Docker as optional. *Implication:* Improves contributor velocity but risks inconsistent user environments and more support variance. c) Dual golden paths: certify both with CI-tested recipes and explicit platform matrices. *Implication:* Best experience long-term, but demands sustained maintenance capacity and tighter release engineering. d) Other / More discussion needed / None of the above. **Question 2:** Do we enforce a hard deprecation policy for “main branch usage” to prevent support chaos and protect perceived stability? **Context:** - `Discord coders (2025-03-13): "Use version 0.25.9, not the main branch" (notorious_d_e_v).` - `Discord (2025-03-12): "Confusion exists about which branch is most stable" (highlights).` **Multiple Choice Answers:** a) Yes—make releases the only supported path; add CLI warnings and docs banners discouraging main branch installs. *Implication:* Reduces noise and increases trust, but may frustrate power users who want bleeding-edge features. b) Soft policy—keep main available but label it clearly and route support questions to a self-serve troubleshooting flow. *Implication:* Balances openness with guardrails, though repeated confusion may persist without stronger enforcement. c) No—support main as a first-class experience and invest in stabilizing it continuously. *Implication:* Ambitious and developer-friendly for early adopters, but increases reliability risk and support load. d) Other / More discussion needed / None of the above. **Question 3:** How should we operationalize “Taming Information” so troubleshooting fixes (e.g., suppressInitialMessage, debug flags) become instant, searchable knowledge rather than Discord lore? **Context:** - `Discord (2025-03-13 coders): fix for disappearing messages: set `suppressInitialMessage: true` (notorious_d_e_v).` - `Discord (2025-03-13 coders): Twitter debugging: `DEFAULT_LOG_LEVEL=debug` (notorious_d_e_v).` **Multiple Choice Answers:** a) Automate: pipe solved Discord threads into versioned docs/llms.txt with CI checks for stale guidance. *Implication:* Creates compounding documentation value but requires tooling and editorial ownership. b) Curate: weekly human-led “Top 10 fixes” digest integrated into docs and the CLI help output. *Implication:* High signal and low complexity, but depends on consistent human cadence. c) Embed: build an in-product troubleshooting assistant that detects symptoms and suggests fixes in the UI/CLI. *Implication:* Best UX and differentiation, but pulls engineering from core stabilization in the short term. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Rebrand, Token Surface Area, and Flagship Agent Trust **Summary of Topic:** Rebranding to ElizaOS is underway while token metadata and governance perceptions remain bottlenecked; flagship agent narratives (DegenAI/Spartan) are high-interest but exposed to platform risk (X suspensions, unclear utility), so credibility must be earned through shipping and transparent comms. #### Deliberation Items (Questions): **Question 1:** Should token migration/rebrand communications be treated as a product-quality deliverable (with release notes, timelines, and escalation paths), not merely a marketing update? **Context:** - `Discord (2025-03-12): ticker change "$ai16z to $elizaos" blocked by "daos.fun" metadata update bottleneck (Patt/vincentpaul).` - `Discord (2025-03-13): "We rebranded as ElizaOS https://x.com/elizaOS" (Patt).` **Multiple Choice Answers:** a) Yes—ship a formal migration playbook with SLAs, status page updates, and post-mortems for blockers like daos.fun. *Implication:* Increases trust and reduces rumor cycles, but forces tighter operational accountability. b) Partially—publish a lightweight timeline and FAQs, while keeping operational details internal. *Implication:* Improves clarity with minimal overhead, but may not satisfy transparency concerns from holders/builders. c) No—keep comms high-level until technical dependencies resolve to avoid committing to dates. *Implication:* Reduces the risk of missed timelines, but invites speculation and weakens “Trust Through Shipping.” d) Other / More discussion needed / None of the above. **Question 2:** How tightly should flagship agents (e.g., DegenAI/Spartan) be coupled to core releases, given they amplify both successes and failures? **Context:** - `Discord spartan_holders (2025-03-13): DegenAI updates may be included in V2; feature requests include "autonomous investing", "sentiment analysis", "trading database terminal" (Void).` - `Discord (2025-03-13): "DegenAI's X account was suspended" (highlights).` **Multiple Choice Answers:** a) Decouple—ship core V2 independently; treat flagship agents as separately versioned reference apps. *Implication:* Protects core reputation and enables focused agent iteration, but may reduce coordinated launch impact. b) Couple—flagship agents are the proof; require them to be stable and showcased at every core milestone. *Implication:* Maximizes narrative coherence, but makes core releases hostage to agent-specific platform risks. c) Hybrid—bundle one “boringly reliable” flagship with core, and keep experimental agents (trading/autonomy) as labs builds. *Implication:* Balances trust and ambition, with clearer expectations for riskier capabilities. d) Other / More discussion needed / None of the above. **Question 3:** What governance posture should we adopt in the near term to address community fears that “the DAO is not actually a DAO,” without stalling core execution? **Context:** - `Discord (2025-03-12): community concerns: "DAO transparency" and "holders' voices don't matter" (Patt).` - `Discord (2025-03-12): team focus: "getting the core (Labs/Studios) up and running" before expanding DAO functionality (vincentpaul).` **Multiple Choice Answers:** a) Execution-first: publish a minimal governance roadmap and defer expanded DAO mechanisms until core and Cloud stabilize. *Implication:* Protects engineering focus but may prolong legitimacy concerns and token narrative volatility. b) Parallel track: introduce limited-scope onchain votes (priorities, grants) while core continues shipping. *Implication:* Improves participation and legitimacy, but increases coordination cost and decision overhead. c) Agent-governance pilot: deploy a transparent, auditable “governance agent” to propose, summarize, and track decisions before formal voting. *Implication:* Aligns with mission (AI-enhanced governance) and taming information, but must avoid perceptions of simulated participation. d) Other / More discussion needed / None of the above.