# Council Briefing: 2025-03-19 ## 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 - The fleet advanced V2 stability and DX via rapid merges (CLI/logging/UI/TEE pipeline), but fresh onboarding breakpoints (CLI install errors, Ollama parsing) signal that reliability—not new surface area—remains the gating factor for trust and launch cadence. ## Key Points for Deliberation ### 1. Topic: V2 Stability & Runtime Integrity (Post-Monorepo Merge) **Summary of Topic:** Engineering throughput is high (multiple bugfixes, UI alignment, payload reduction, logging improvements, TEE CI/CD), yet the beta’s perceived instability continues to tether dependent programs (e.g., Spartan) and threatens confidence in a near-term full release. #### Deliberation Items (Questions): **Question 1:** What is the Council’s release gate for V2: feature completeness at end-of-month, or a quantified stability threshold that may delay launch but preserve trust through shipping? **Context:** - `Discord (spartan_holders): rhota — "v2 beta just went live... a lot of bug fixing going on at the moment to get Spartan working."` - `GitHub daily (2025-03-19): "Efforts also focused on refining the CLI experience... Fixed chat UI alignment... Reduced payload size to prevent database update failure."` **Multiple Choice Answers:** a) Ship end-of-month as planned; accept a known-bugs list and rely on rapid patch cadence. *Implication:* Maximizes momentum and marketplace timing, but risks eroding the "reliable by default" brand if early builders churn. b) Delay until stability criteria are met (crash-free sessions, install success rate, core flows passing) even if it slips beyond March. *Implication:* Strengthens execution excellence and long-term DX credibility, but compresses marketplace/token-utility timelines. c) Dual-track: keep beta public, but declare a "Stable Channel" date only after stability thresholds, with Spartan pinned to stable. *Implication:* Maintains community energy while shielding flagship/dependent programs from beta volatility. d) Other / More discussion needed / None of the above. **Question 2:** Which reliability fires should be treated as "red alert" because they directly damage perceived autonomy and persistence (core to the OS narrative)? **Context:** - `GitHub daily (2025-03-19): Issue #3993 — "parsing failure with the Ollama LLM engine, resulting in a TypeError: null is not an object."` - `Discord (2025-03-16): "Twitter agents can post on command but won't run autonomously in the latest version."` **Multiple Choice Answers:** a) Prioritize runtime correctness: Ollama parsing, model/provider initialization, and memory/persistence regressions first. *Implication:* Protects the core agent loop; reduces "it runs but behaves weird" reports that kill trust fastest. b) Prioritize autonomy surfaces: scheduler/clients (Twitter/Discord) reliability and rate-limit-safe behavior. *Implication:* Improves visible agent autonomy demos, but may leave deep runtime edge cases to accumulate. c) Prioritize platform operability: database/migrations/CLI start flows and observability (logs) for faster debugging by the community. *Implication:* Enables the ecosystem to self-heal and lowers support load, compounding developer-first benefits. d) Other / More discussion needed / None of the above. **Question 3:** How tightly should external programs (Spartan and others) be coupled to V2 milestones, given the monorepo merge destabilization risk? **Context:** - `Discord (spartan_holders): Odilitime — "forced to move all our tech onto the v2 stack... closely tied together."` **Multiple Choice Answers:** a) Maintain hard coupling: Spartan remains the forcing function to finish V2 quickly. *Implication:* Accelerates integration realism, but raises the blast radius of V2 regressions across the ecosystem. b) Introduce compatibility shims and decouple: allow Spartan to run on a pinned stable subset while V2 evolves. *Implication:* Reduces ecosystem risk and support churn, but adds short-term engineering overhead. c) Segment by capability: couple only what needs V2 (GUI/WebSockets), keep other Spartan paths on V1 until stable. *Implication:* Optimizes for execution excellence, but requires clear communication and disciplined versioning. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Developer Experience: CLI Install, Docs, and "Taming Information" Pipeline **Summary of Topic:** High-velocity fixes and doc upgrades are landing (docs versioning, improved V2 docs frontpage), but onboarding failures (CLI install errors, dependency mismatches like plugin-sql) indicate the first-run experience is still brittle—undermining the developer-first mandate. #### Deliberation Items (Questions): **Question 1:** What is the Council’s immediate remedy for onboarding breakage: stricter release discipline (version pinning + smoke tests) or faster community workaround distribution (beta CLI guidance)? **Context:** - `GitHub daily (2025-03-19): Issue #3989 — "getting started instructions... `npm install -g @elizaos/cli` command... leading to an error."` - `Discord (2025-03-18 coders): amtraq. — "npm install -g @elizaos/cli@1.0.0-beta.1" workaround for plugin-sql notarget.` **Multiple Choice Answers:** a) Institute strict version pinning and a release train with automated install smoke tests across OSes before publishing. *Implication:* Reduces breakage and support noise, aligning with execution excellence, but slows iteration cadence. b) Continue fast shipping; formalize a "known-good" beta channel and push workarounds prominently in docs/CLI output. *Implication:* Preserves speed while mitigating pain, but risks normalizing instability as the default user experience. c) Hybrid: pin critical dependency graph (CLI + core + key plugins) while allowing peripheral packages to move faster. *Implication:* Balances reliability and velocity; focuses stability where builders feel it most. d) Other / More discussion needed / None of the above. **Question 2:** How should we operationalize the "Taming Information" doctrine so the same questions (RAG paths, client config, REST/WebSockets) stop repeating in Discord? **Context:** - `Discord (2025-03-18): repeated RAG directory/path confusion and requests for clearer guides (knowledge directory structure, character.json client config).` - `GitHub PRs (2025-03-18/19): docs versioning (#3963) and improved V2 docs frontpage + llms.txt (#3991).` **Multiple Choice Answers:** a) Deploy an "Answer-Once" pipeline: every resolved Discord support thread becomes a doc snippet + searchable FAQ within 24 hours. *Implication:* Compounds community support into durable DX assets; improves trust through shipping documentation. b) Prioritize product-side fixes over docs: change defaults and error messages so users don’t need the docs for common cases. *Implication:* Best long-term UX, but may lag the immediate support load during beta instability. c) Stand up a dedicated support agent (jintern v2) as the first-line interface, with docs updates batched weekly. *Implication:* Reduces human moderator burden quickly, but can hide documentation debt if not tightly linked to doc commits. d) Other / More discussion needed / None of the above. **Question 3:** Which integration surface should be canon for builders: REST control via DirectClient today, or WebSockets as the default once merged—given the goal of seamless UX and interoperability? **Context:** - `Discord (2025-03-18): Ayush — DirectClient REST setup guidance (client-direct).` - `Discord (2025-03-18 coders): jintern — "Shaw added websockets functionality recently in his v2 branches" for web interfaces.` **Multiple Choice Answers:** a) Canonicalize REST now (DirectClient) and treat WebSockets as an advanced/optional layer until fully stabilized. *Implication:* Minimizes moving targets for documentation and SDKs; may slow adoption of real-time UI integrations. b) Commit to WebSockets as the primary interface and retrofit REST as compatibility for legacy integrations. *Implication:* Optimizes for modern interactive agent UX, but increases short-term migration and stability demands. c) Publish a unified transport abstraction: same API surface with REST/WebSockets adapters behind it. *Implication:* Preserves composability and reduces future churn, at the cost of additional engineering upfront. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Ecosystem Readiness: Marketplace/Token Utility and Governance Signal **Summary of Topic:** Community expectation is converging on end-of-month launchpad/marketplace utility and clearer governance pathways, but token utility is not implemented and communication gaps risk reputational drag (including exchange-listing anxieties). #### Deliberation Items (Questions): **Question 1:** What minimal token-utility primitive must ship with the marketplace to credibly align incentives without compromising reliability (the prime directive)? **Context:** - `Discord (partners): "launchpad and marketplace are scheduled for the end of March... provide utility for the AI16Z token"; "use AI16Z tokens for API and compute payments... isn't implemented yet."` **Multiple Choice Answers:** a) Ship token payments only for marketplace purchases (agent templates/plugins), keep compute billing fiat/credits until Cloud is stable. *Implication:* Delivers visible utility with limited operational risk; delays full decentralized compute economy narrative. b) Ship token-based metering for API/compute immediately (even if limited), making token utility central from day one. *Implication:* Maximizes narrative coherence, but raises billing, abuse, and reliability risks during beta. c) Ship staking/reputation gating (access, featuring, rate limits) rather than payments, then roll payments later. *Implication:* Creates utility without payments complexity; must be designed carefully to avoid pay-to-play backlash. d) Other / More discussion needed / None of the above. **Question 2:** How should the Council respond to external perception risks (e.g., Binance Alpha delisting fears) when execution is still in stabilization mode? **Context:** - `Discord (spartan_holders): concerns about Binance Alpha delistings and "lack of updates and communication."` **Multiple Choice Answers:** a) Increase transparency cadence: weekly public stability reports, shipped fixes, and explicit milestone gates. *Implication:* Builds trust through shipping and clarity; may expose short-term instability but reduces rumor amplitude. b) Limit forward-looking promises; communicate only when features are stable and released. *Implication:* Reduces promise debt, but can be misread as silence and deepen partner frustration. c) Delegate comms to a partner-driven pipeline (Typefully drafts + official repost) with light core-team review. *Implication:* Scales output quickly and strengthens community ownership, but requires guardrails to prevent inconsistent messaging. d) Other / More discussion needed / None of the above. **Question 3:** Do we formalize the proposed "AI Jedi Council" as an operating layer now, or wait until V2/marketplace stabilization to avoid governance theater? **Context:** - `Discord (dao-organization): proposal for an "AI Jedi Council" with 12 agent personas; also calls for town halls and structured contribution pathways.` **Multiple Choice Answers:** a) Stand it up immediately as an information-distillation and routing layer (non-binding), focused on support/docs/ops. *Implication:* Accelerates taming-information and contributor coordination without overcommitting governance legitimacy. b) Delay formalization until after V2 is stable; keep the working group informal to avoid distraction. *Implication:* Protects engineering focus, but leaves partner energy and coordination problems unresolved longer. c) Pilot with 3–4 personas first (DX, Reliability, Community, Token Utility) and expand only if metrics improve. *Implication:* Creates a measurable governance experiment aligned to execution excellence; avoids a brittle 12-seat structure. d) Other / More discussion needed / None of the above.