# Council Briefing: 2025-04-04 ## 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’s immediate bottleneck is execution excellence at the tooling layer—April 4 centered on hardening CLI/plugin installation and dynamic loading so new agents reliably boot without manual dependency archaeology. ## Key Points for Deliberation ### 1. Topic: V2 Beta Boot Reliability (CLI + Plugin Loading) **Summary of Topic:** Core engineering momentum is strong (high PR throughput), but the user-facing reality is fragile: plugin loading order, global CLI installs, and dynamic imports are still causing first-run failures and repeated setup prompts—directly eroding developer trust. #### Deliberation Items (Questions): **Question 1:** Do we mandate an "always-on baseline" plugin set (e.g., SQL + Bootstrap) for all newly created agents to eliminate first-run crashes, even if it reduces composability purity? **Context:** - `Discord 💻-coders: px notes getTasks() is part of sqlplugin and "required but not installed by default"; users hit "Cannot read properties of undefined (reading 'init')".` - `GitHub completed_items: PR #4277 "Default SQL and OpenAI Plugins for New Character" (UI-level mitigation).` **Multiple Choice Answers:** a) Yes—enforce a baseline plugin set for all new agents (SQL + Bootstrap + default model provider), with opt-out warnings. *Implication:* Maximizes first-run success and reduces support load, at the cost of a slightly heavier default footprint. b) No—keep pure composability; instead improve error messages and add an interactive "missing dependencies" wizard. *Implication:* Preserves modular philosophy, but risks continued friction during the critical activation moment for new builders. c) Hybrid—baseline only in GUI-created agents; CLI remains minimal for power users. *Implication:* Optimizes for novice UX without constraining advanced workflows, but introduces behavioral divergence across entrypoints. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s acceptable failure rate for global CLI installs, given repeated reports of plugin resolution and module path issues? **Context:** - `ElizaOS Daily Update (Apr 4): "Improved CLI update and plugin installation" (#4177) and "Fixed issues with loading required plugins in global CLI installations" (#4176).` - `ElizaOS Daily Update (Apr 4): "Addressed module path issues" (#4178) and "Improved error handling for dynamic-runtime imports" (#4179).` **Multiple Choice Answers:** a) Near-zero: treat global install parity as a release gate; block broader releases until it matches npx behavior. *Implication:* Strengthens trust-through-shipping, but may slow feature cadence and compress bandwidth for other priorities. b) Managed: allow limited issues; recommend npx as the blessed path while global install matures. *Implication:* Keeps velocity while containing expectations, but risks perception that the platform is "finicky". c) Deprioritize: focus on Cloud-managed runtimes; global CLI becomes best-effort. *Implication:* Aligns with cloud platform strategy, but could alienate the open-source/dev-first cohort that builds ecosystem gravity. d) Other / More discussion needed / None of the above. **Question 3:** Should we formalize a "beta changelog contract" (human-readable deltas per beta tag) as part of execution excellence, even if it consumes engineering time? **Context:** - `Development Discord (Apr 3): users request "changelog/release info for beta versions" (piffie).` - `Multiple Discord threads indicate confusion about v2/v1.0 beta status and migration steps.` **Multiple Choice Answers:** a) Yes—publish a concise changelog for every beta release; no exceptions. *Implication:* Reduces support churn and improves builder confidence; establishes a predictable cadence of trust signals. b) Partial—weekly digest only, bundling multiple betas into one narrative update. *Implication:* Balances time cost and transparency, but delays critical information for builders debugging daily. c) No—prioritize fixes; rely on GitHub PR lists and automated release notes. *Implication:* Maximizes engineering throughput, but keeps the system legible only to power users, undermining developer-first onboarding. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Social Integrations as Reliability Hotspots (Twitter/Telegram/Discord) **Summary of Topic:** The highest-frequency operational pain is social clients: Twitter reply timing, reply caps, client creation, and incomplete interaction reactions; Telegram and Discord also show breaks. These issues are disproportionately visible and can damage perceived reliability of the entire framework. #### Deliberation Items (Questions): **Question 1:** Do we freeze new social features until Twitter interaction/reaction handling and timing controls are fully deterministic? **Context:** - `Discord 💻-coders: reports that TWITTER_POLL_INTERVAL is ignored and MAX_REPLIES_PER_TWEET not working (tao8617).` - `GitHub new issues (Apr 4): #4181 "Interactions for Twitter are being fetched, but reactions have not yet been implemented".` **Multiple Choice Answers:** a) Yes—declare a stabilization moratorium: no new Twitter features until timing and reply-capping are correct and tested. *Implication:* Improves execution excellence and prevents reputational damage from spammy agents, but delays roadmap items. b) No—continue feature work in parallel; prioritize only crashers and obvious spam behavior. *Implication:* Maintains momentum, but leaves builders with unpredictable behavior that can get accounts rate-limited or banned. c) Segment—ship features behind a "labs" flag while enforcing safe defaults (dry-run, strict caps) in stable mode. *Implication:* Preserves innovation while protecting users, but requires clear surfacing of risk tiers in docs/UI. d) Other / More discussion needed / None of the above. **Question 2:** What is the correct product stance on Twitter setup in v2: "no plugin required" vs "explicit plugin installation"—and do we align tooling to eliminate contradictory guidance? **Context:** - `Discord 💻-coders: Ale | AutoRujira states "v2 doesn't need separate Twitter plugin installation, just .env configuration"; other users are confused and attempting plugin installs.` **Multiple Choice Answers:** a) Make Twitter setup purely .env-driven in v2; remove/redirect plugin-install paths to avoid confusion. *Implication:* Simplifies onboarding and reduces configuration drift, but constrains advanced customization patterns. b) Standardize on explicit plugin installation everywhere; .env only configures credentials. *Implication:* Improves conceptual consistency (plugins add capabilities), but adds steps and increases failure modes. c) Support both, but auto-detect and warn: if creds exist and plugin missing, prompt to enable automatically. *Implication:* Minimizes friction while retaining modularity, but increases complexity in the CLI/UI decision logic. d) Other / More discussion needed / None of the above. **Question 3:** Should we elevate "account safety" to a first-class framework concern (anti-spam defaults, rate limit governors, dry-run modes) for social agents? **Context:** - `Discord 💻-coders: users ask how to prevent unwanted tweeting; Ale recommends TWITTER_DRY_RUN=true.` - `Discord general: prior marketing Twitter account suspension discussed (impersonation risk).` **Multiple Choice Answers:** a) Yes—ship hardened safety defaults (dry-run on first, conservative reply limits, backoff, explicit allowlists). *Implication:* Reduces bans and reputational harm, strengthening trust and enabling safer mainstream adoption. b) Optional—provide safety presets as templates, but keep defaults permissive for growth hacking. *Implication:* Maximizes experimentation speed but risks user accounts and public incidents that reflect on ElizaOS. c) Defer to builders—document best practices only; avoid opinionated constraints in core. *Implication:* Preserves framework neutrality, but shifts risk to users and increases support burden when failures occur. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Migration + Documentation as Trust Infrastructure **Summary of Topic:** Migration friction (v1→v2 memory/DB transfer) and missing/contradictory docs are repeatedly blocking builders; meanwhile, the docs platform migration to eliza.how is progressing and can become the Council’s primary trust engine—if it is treated as a release artifact, not an afterthought. #### Deliberation Items (Questions): **Question 1:** Do we prioritize a canonical v1→v2 migration pathway (memories/DB/tweetcache) as a top-level milestone before additional platform launches? **Context:** - `Discord 💻-coders: "Users are struggling with transferring agent memories/databases between versions"; SMA requests migration instructions.` - `Discord: reports of disappearing conversations (FlipWhale) and persistent setup confusion.` **Multiple Choice Answers:** a) Yes—treat migration as a release blocker; ship tooling + docs that make it a one-command, reversible process. *Implication:* Directly supports execution excellence and reduces churn from early adopters stuck between versions. b) Partial—document manual steps now; build automation later once v2 stabilizes. *Implication:* Unblocks some users quickly, but keeps migration risky and error-prone during a high-visibility period. c) No—focus on v2 greenfield; communicate that migration is not guaranteed during beta. *Implication:* Speeds forward progress, but sacrifices continuity for existing users and weakens trust through perceived abandonment. d) Other / More discussion needed / None of the above. **Question 2:** How should the Council operationalize docs as a first-class citizen: enforce "docs readiness" gates per integration, or allow docs to trail code changes? **Context:** - `Discord partners: Jin migrating elizaos.ai → eliza.how via Docusaurus; video section shipped at https://eliza.how/community/videos.` - `Development Discord: request for beta changelog; multiple recurring setup questions indicate docs gaps.` **Multiple Choice Answers:** a) Enforce docs gates: no merge for user-facing changes without a docs delta and a verified quickstart test. *Implication:* Improves developer trust and reduces support load, but increases PR overhead and review time. b) Adopt "docs SLA": allow merges, but require docs completion within a fixed window (e.g., 72 hours) with enforcement. *Implication:* Balances velocity and reliability, but requires governance mechanisms to prevent SLA erosion. c) Keep docs best-effort; focus on shipping and rely on community to fill gaps. *Implication:* Maximizes speed but risks fragmented knowledge and undermines the "developer-friendly" North Star. d) Other / More discussion needed / None of the above. **Question 3:** Should we build an automated "docs drift detector" that flags documentation needing updates after PR merges, and make it part of the core workflow? **Context:** - `Development Discord (Apr 3): Jin proposes "notification system for documentation updates needed after PRs are merged".` - `Discord + GitHub: multiple issues stem from doc mismatches (CLI commands, character import, plugin behavior).` **Multiple Choice Answers:** a) Yes—implement drift detection (labels/checks) and route alerts to maintainers and a docs council queue. *Implication:* Converts documentation into maintainable infrastructure, aligning with Taming Information and Execution Excellence. b) Maybe—start with a lightweight manual triage process (weekly doc audit) before automating. *Implication:* Lower engineering cost now, but risks scaling pain as PR volume and contributor count increase. c) No—use existing GitHub practices only (CODEOWNERS, reviewers) and avoid specialized automation. *Implication:* Simplifies tooling, but likely fails under current repo velocity and community-driven PR throughput. d) Other / More discussion needed / None of the above.