# Council Briefing: 2025-03-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 - The fleet advanced core stability (Ollama modularization, smaller Docker images, stronger test coverage) but a critical DX breach persists: unclear/under-annotated APIs and install pathways are still generating user confusion and trust drag. ## Key Points for Deliberation ### 1. Topic: V2 Installability & API Clarity (Developer Trust Gate) **Summary of Topic:** Operational signals show recurring friction in installation, plugin discovery, and API understanding; this is now a strategic threat to our "Execution Excellence" and "Developer First" principles. Issue #4119 flags insufficient API annotations, compounding confusion already visible in Discord support loops and npm dependency mismatches. #### Deliberation Items (Questions): **Question 1:** Do we declare "installability and API clarity" as a release-blocking quality gate for the next public v2 milestone? **Context:** - `2025-03-31.md: "[elizaos/eliza#4119] ... lack of annotations in the API ... causing user confusion"` - `completed_items / issues: "npm install -g @elizaos/cli@latest fails ... @elizaos/plugin-sql@^0.25.6 ... cannot be found"` **Multiple Choice Answers:** a) Yes—treat install success + annotated API surfaces as a hard gate before any launchpad/marketing push. *Implication:* Optimizes for long-term developer trust, but may delay visible milestones and external hype. b) Partial gate—block only on install/CLI critical path; defer deeper API annotation to a rolling docs sprint. *Implication:* Balances shipping with trust-building, but risks continued support burden and fragmented mental models. c) No—ship features and rely on community/Discord support to patch comprehension gaps. *Implication:* Maximizes short-term velocity, but converts Discord into a permanent support desk and erodes DX reputation. d) Other / More discussion needed / None of the above. **Question 2:** What is our canonical distribution path for v2 during the transition period (CLI stable vs beta, git clone workflow, etc.)? **Context:** - `completed_items: "Workaround identified: using the beta tag: npm install -g @elizaos/cli@beta"` - `Discord 2025-03-30 (💻-coders): "The v2-develop branch appears to be more stable than other branches."` **Multiple Choice Answers:** a) Declare @beta as canonical until dependency graph stabilizes; update quickstart and CLI output accordingly. *Implication:* Reduces onboarding failures immediately, but formalizes 'beta' optics until the release train catches up. b) Freeze on a pinned git tag/commit with a blessed 'git clone + bun' path; CLI install becomes optional. *Implication:* Improves reproducibility for builders, but increases friction for newcomers expecting a one-command CLI. c) Push a rapid hotfix to make @latest correct again and forbid alternative paths in docs. *Implication:* Restores simple onboarding if executed flawlessly, but risks repeated breakage if packaging is still in flux. d) Other / More discussion needed / None of the above. **Question 3:** How should we operationalize 'docs as code' so AI agents (and humans) can reliably self-serve without Discord escalation? **Context:** - `Daily Report 2025-03-30: "'docs as code' philosophy is gaining importance ... AI can read documentation much faster than humans"` - `Discord 2025-03-30 (🥇-partners): "more streamlined source of truth for technical and project progress" (Patt)` **Multiple Choice Answers:** a) Implement a single source-of-truth pipeline: versioned docs, llms.txt, and automated 'known issues' pages tied to CI. *Implication:* Turns documentation into an executable artifact, improving onboarding and reducing repeated Discord triage. b) Ship a lightweight 'FAQ + flowchart' layer first, then evolve toward full docs-as-code automation later. *Implication:* Quickly reduces confusion for common paths, but deeper correctness may lag behind code changes. c) Rely on community summaries and ad-hoc Discord answers, with periodic doc cleanups. *Implication:* Lowest immediate cost, but ensures drift between reality and documentation—undermining trust-through-shipping. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Core Stabilization: Modularity, Efficiency, and Test Sovereignty **Summary of Topic:** The codebase exhibited strong forward motion on reliability: Docker image optimization, expanded tests, and a key architectural decoupling (Ollama split from LocalAI). This aligns with composability, but also increases the need for compatibility matrices and clear model/provider selection behavior. #### Deliberation Items (Questions): **Question 1:** Do we formalize provider modularization (e.g., separate Ollama plugin) as the standard pattern for all model runtimes going forward? **Context:** - `2025-03-31.md: "Added a separate Ollama plugin ... Removed obsolete Ollama code from localai"` - `PRs: #4121 "feat: add separate ollama plugin" and #4122 "remove ollama code from localai"` **Multiple Choice Answers:** a) Yes—standardize: one provider per plugin, strict interfaces, and explicit compatibility versioning. *Implication:* Improves maintainability and composability, but requires disciplined registry governance and documentation. b) Hybrid—keep a minimal 'local-ai umbrella' with optional submodules for common providers. *Implication:* Reduces plugin sprawl, but risks reintroducing entanglement and confusing dependency behavior. c) No—prefer monolithic local runtime bundles to simplify onboarding. *Implication:* May simplify initial setup for some users, but increases long-term complexity and slows reliable shipping. d) Other / More discussion needed / None of the above. **Question 2:** How do we convert recent test improvements into a dependable shield against regressions in CLI + plugins? **Context:** - `2025-03-31.md: "Updated code to resolve failing CLI test cases" (PR #4100)` - `2025-03-31.md: "Added a comprehensive test suite for the project-starter directory" (PR #4089)` **Multiple Choice Answers:** a) Adopt 'release train' CI gates: install tests, plugin smoke tests, and golden-path agent runs on every merge. *Implication:* Prevents repeated onboarding failures, but increases CI cost and demands stable test fixtures. b) Focus tests on core only; treat plugins as best-effort and validate them via community feedback. *Implication:* Protects core velocity, but plugin instability will still be attributed to ElizaOS as a platform. c) Move to periodic nightly integration suites only, keeping merge checks lightweight. *Implication:* Speeds merges, but allows regressions to ship and forces reactive incident response. d) Other / More discussion needed / None of the above. **Question 3:** Should we prioritize operational efficiency wins (e.g., Docker size reductions) as a strategic lever for Cloud readiness and cost control? **Context:** - `2025-03-31.md: "Reduced Docker image size, optimizing resource usage" (PR #4120)` - `Discord summaries: recurring local setup issues (VRAM problems, provider configuration) increasing the need for smoother deployment paths` **Multiple Choice Answers:** a) Yes—treat footprint/boot-time as first-class metrics; publish targets and track regressions. *Implication:* Improves Cloud unit economics and perceived reliability; supports the 'seamless UX' principle. b) Only optimize when it unblocks a specific incident; otherwise focus engineering on features. *Implication:* Avoids premature optimization, but may allow Cloud costs and deployment friction to compound. c) Defer efficiency work until after v2 is feature-complete. *Implication:* Risks shipping a platform that is expensive to run and harder to adopt at scale. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Auto.fun / ai16z Narrative Coherence (Governance & Trust Surface) **Summary of Topic:** Community discourse shows confusion about Auto.fun's token relationship and launch timeline, amplifying uncertainty around contributor value capture and governance credibility. This is a reputational risk that competes directly with our mandate to build trust through consistent delivery and clear documentation. #### Deliberation Items (Questions): **Question 1:** What is the Council-approved canonical message on Auto.fun’s relationship to ai16z (no native token vs fee buybacks) and where does it live as a permanent source of truth? **Context:** - `Discord 2025-03-29: "Shaw's tweet stating 'auto.fun has no native token' caused confusion"` - `Discord 2025-03-29/30: "fees generated will be used to buy ai16z" (witch / eskender.eth)` **Multiple Choice Answers:** a) Publish a single signed 'Token Relationship Spec' (docs + FAQ + infographic) and link it everywhere. *Implication:* Reduces rumor-driven volatility and aligns the ecosystem around a durable narrative. b) Keep messaging flexible (tweets/Discord) until launch mechanics finalize; avoid hard commitments. *Implication:* Preserves optionality, but extends confusion and weakens trust-through-shipping. c) Delegate messaging to community members and rely on organic clarification. *Implication:* Low effort for the core team, but increases misinformation risk and fractures governance legitimacy. d) Other / More discussion needed / None of the above. **Question 2:** How should we handle launch timeline signaling (countdowns, 'two weeks', specific dates) to avoid credibility damage? **Context:** - `Discord 2025-03-30 (discussion): "Launchpad coming April 14th" (Borko)` - `Discord 2025-03-30 (🥇-partners): Auto.fun launching "in two weeks" (implied from context)` **Multiple Choice Answers:** a) Adopt a policy: no dates unless backed by a published checklist with owners and go/no-go gates. *Implication:* Decreases hype volatility but increases credibility and delivery discipline. b) Keep approximate timelines publicly ('~2 weeks') while holding exact dates internally. *Implication:* Maintains momentum, but still risks repeated slippage narratives. c) Lean into aggressive public dates to maximize attention and liquidity interest. *Implication:* May spike short-term engagement, but failures become permanent trust debt. d) Other / More discussion needed / None of the above. **Question 3:** Does the current two-pool buyback model sufficiently respect contributor value creation, or do we need an explicit contributor-aligned accrual mechanism? **Context:** - `Discord 2025-03-30 (🥇-partners): "Witch explained a two-pool system ... fees ... buy back ai16z"` - `Discord 2025-03-30 (🥇-partners): "DorianD expressed concerns ... potentially undervaluing contributors' work"` **Multiple Choice Answers:** a) Add explicit contributor accrual (e.g., rev-share or emissions tied to verified contributions) alongside buybacks. *Implication:* Strengthens long-term ecosystem labor supply, but increases tokenomics complexity and governance load. b) Keep buybacks as the primary mechanism; handle contributors via bounties/grants only. *Implication:* Simplifies tokenomics, but may reduce sustained high-skill contribution if incentives feel indirect. c) Defer contributor alignment decisions until after launchpad revenue is proven. *Implication:* Avoids premature design, but risks losing key builders during the highest-leverage growth window. d) Other / More discussion needed / None of the above.