# Council Briefing: 2025-04-05 ## 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 - Core stability advanced via merged CLI/plugin-bootstrap and Twitter-interaction fixes, but Council attention is still required to resolve v2 onboarding/config confusion and protect the public trust surface against scams and reliability regressions. ## Key Points for Deliberation ### 1. Topic: Execution Excellence: CLI + Plugin System Hardening (V2 Readiness) **Summary of Topic:** Engineering throughput is strong (13 PRs / 8 merged on Apr 4–5), with concrete improvements to plugin installation management, bootstrap test coverage, and CLI reliability—directly serving the Council’s mandate of developer trust through seamless setup. #### Deliberation Items (Questions): **Question 1:** What is the Council’s release gate for the v2 beta: feature parity with v1, or a narrower stability-and-DX threshold aligned to the North Star? **Context:** - `GitHub summary: "From 2025-04-04 to 2025-04-05, elizaos/eliza had 13 new PRs (8 merged)"` - `Daily Report - 2025-04-04: "Better plugin installation management was implemented (PR #4177)"` **Multiple Choice Answers:** a) Gate on stability + installation success rate (CLI, plugin bootstrap, core flows), defer parity gaps behind clear docs and issue labels. *Implication:* Maximizes reliability and trust-through-shipping, but requires disciplined scope control and crisp messaging about what’s not ready. b) Gate on v1 feature parity (social + DB + deployment behaviors) before expanding distribution of v2 beta. *Implication:* Reduces migration pain, but risks delaying the reliability narrative and slowing the ecosystem’s transition. c) Gate on a “golden path” reference stack only (OpenAI + SQL + one social client), officially treating other paths as experimental. *Implication:* Creates a predictable developer experience quickly, but may frustrate builders expecting broad provider/plugin compatibility. d) Other / More discussion needed / None of the above. **Question 2:** Should SQL be treated as a required default dependency for new agents in v2 to reduce common startup failures? **Context:** - `Discord (2025-04-03): "Cannot read properties of undefined (reading 'init')" due to missing SQL plugin; px: "getTasks() is part of the sqlplugin, which is required but not installed by default."` - `Action Items (2025-04-03): "Fix SQL Plugin Integration - Ensure SQL plugin is automatically installed with new agents"` **Multiple Choice Answers:** a) Yes—make SQL auto-installed for new agents and warn loudly before removal. *Implication:* Improves first-run success and reduces Discord support load, reinforcing Execution Excellence. b) No—keep it optional, but add a startup preflight that detects missing required plugins based on chosen features. *Implication:* Preserves modularity while preventing silent failure, at the cost of additional CLI/UI complexity. c) Conditional default—auto-install SQL only when memory/tasks/knowledge features are enabled in the character config. *Implication:* Balances composability with UX, but requires clearer configuration semantics and robust dependency inference. d) Other / More discussion needed / None of the above. **Question 3:** How should we reduce v1/v2 plugin confusion without sacrificing openness and composability? **Context:** - `Issue #4164: "only plugins in the /packages directory of the v2-develop branch are fully compatible with v2... plugins shown on the documentation website are still v1"` - `Discord (2025-04-04): repeated questions about plugin installation vs .env-only configuration for Twitter` **Multiple Choice Answers:** a) Clearly label docs with v1/v2 compatibility badges and auto-hide incompatible plugins by default. *Implication:* Preserves openness while protecting DX; requires disciplined doc metadata and publishing workflow. b) Temporarily remove v1 plugin listings from v2 docs entirely until compatibility is restored. *Implication:* Minimizes confusion quickly, but risks shrinking perceived ecosystem breadth and discouraging experimentation. c) Maintain a single unified plugin catalog but enforce runtime compatibility checks that block installs with actionable errors. *Implication:* Turns confusion into guided onboarding, but increases engineering burden in registry/CLI validation. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Social & Provider Reliability: Twitter/Telegram Stabilization and Model Fallbacks **Summary of Topic:** Twitter integration remains a high-visibility trust vector: fixes landed for interaction fetching and client startup ordering, yet Discord signals continued user pain around authentication, timing controls, and embedding handler errors—suggesting we need a single “known-good” operational profile and clearer fallbacks. #### Deliberation Items (Questions): **Question 1:** Do we prioritize a fast Twitter client hotfix release cadence, or a deeper redesign to eliminate recurring timing/auth and reply-loop failures? **Context:** - `PR #4167: "Fixed an issue with the Twitter client where the service was starting before the agent was created"` - `PR #4192: "Fixed Twitter interaction functionality" / removed duplicate fetch` - `Discord (2025-04-04): "Twitter integration in v2 is currently experiencing issues that developers are actively working to fix" (jin)` **Multiple Choice Answers:** a) Hotfix cadence: ship incremental fixes weekly with tight regression tests and a public status page for the Twitter client. *Implication:* Restores external confidence through visible shipping, but risks whack-a-mole without architectural cleanup. b) Redesign: pause feature expansion and refactor Twitter service lifecycle, auth flow, and rate control as a cohesive subsystem. *Implication:* Higher near-term cost, but likely reduces long-term support load and reputation risk. c) Hybrid: define a minimal supported Twitter feature set (read/mentions/reply) and freeze advanced behaviors until core is stable. *Implication:* Provides a dependable baseline fast while preventing new failure modes from spreading. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s official stance on provider defaults and fallbacks when users hit Anthropic rate limits or embedding handler gaps? **Context:** - `Discord (2025-04-04): "Several users experiencing Anthropic rate limiting issues, with some switching to OpenAI as an alternative"` - `Discord (2025-04-04): "Error: No handler found for delegate type: TEXT_EMBEDDING" (kandizzy)` **Multiple Choice Answers:** a) Declare OpenAI embeddings as the default “safe mode” for v2; document how to swap providers for chat vs embeddings. *Implication:* Improves reliability quickly, but may be seen as less provider-neutral unless clearly framed as a temporary safety rail. b) Implement explicit multi-provider routing in core (separate providers for chat/completions/embeddings) as a top priority. *Implication:* Advances composability and resilience, but shifts effort away from near-term stabilization tasks. c) Keep provider behavior strict: no automatic fallback; instead show actionable errors and a guided setup wizard. *Implication:* Preserves predictability and transparency, but increases user friction and support burden. d) Other / More discussion needed / None of the above. **Question 3:** How do we prevent “social spam” behaviors (e.g., ignoring poll intervals or reply limits) from damaging brand trust? **Context:** - `Discord (2025-04-03): "Fix Twitter Reply Timing... ignoring TWITTER_POLL_INTERVAL" and "Restore MAX_REPLIES_PER_TWEET Functionality"` - `Discord (2025-04-04): action item "Implement proper time intervals between Twitter replies" (Abderahman)` **Multiple Choice Answers:** a) Enforce hard rate-limit guards in the Twitter client (server-side), independent of character prompts or LLM output. *Implication:* Protects reputation via deterministic controls; slightly reduces flexibility for power users. b) Keep it configuration-only but add a ‘TWITTER_DRY_RUN’ + ‘compliance simulator’ test mode to validate behaviors pre-launch. *Implication:* Improves DX and reduces accidents, but relies on users to run the simulator. c) Move social behaviors into an audited policy layer (actions/evaluators) with default conservative settings and override approvals. *Implication:* Aligns with governance ambitions and safety, but increases implementation complexity. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Trust Surface: Documentation, Onboarding, and Security Controls **Summary of Topic:** The community is explicitly associating project credibility with documentation quality (“docs as code”) while simultaneously reporting active scam attempts; together these define a single trust frontier where better onboarding and stronger Discord security posture are immediate force multipliers. #### Deliberation Items (Questions): **Question 1:** Should the Council treat “docs-as-code” as a first-class product deliverable with ownership, SLAs, and automation (e.g., doc deploy on merge) rather than an auxiliary effort? **Context:** - `Twitter (dankvr): "the manual is the machine" and "docs as code" framing documentation as the path to autonomous organizations` - `Discord (2025-04-03/04-04): repeated user confusion: Twitter setup, character.json examples, migration steps; links to quickstart and characters repo shared repeatedly` **Multiple Choice Answers:** a) Yes—formalize docs as a product: owners, release checklists, automated deployments, and quarterly doc debt targets. *Implication:* Directly advances Developer First + Trust Through Shipping, reducing support load and increasing adoption. b) Partially—focus on “golden path” docs only (quickstart, migration, Twitter/DB setup) until v2 stabilizes. *Implication:* Delivers immediate impact with limited scope, but may leave long-tail confusion unresolved. c) No—keep docs community-driven and concentrate core team on code; rely on DevRel agents and community curation. *Implication:* Maximizes engineering velocity, but risks continued onboarding friction and reputational drag. d) Other / More discussion needed / None of the above. **Question 2:** What security posture should Discord adopt immediately to counter scam attempts without undermining open community growth? **Context:** - `Discord (2025-04-04): "Multiple scam attempts reported"; suggestion: "disable posting links except for team and moderators"` - `Osint warning: "don’t reply... may contain wallet draining exploits"` **Multiple Choice Answers:** a) Immediate containment: restrict links to trusted roles + add automated scam detection + strengthen mod playbooks. *Implication:* Reduces acute risk and protects newcomers, but increases moderation overhead and may slow legitimate sharing. b) Soft controls: allow links but auto-quarantine them (preview disabled, click-through warning, new-user cooldowns). *Implication:* Balances openness and safety, but may not stop high-skill social engineering attacks. c) Community-driven defense: keep links open and focus on education posts, pinned warnings, and reporting workflows. *Implication:* Preserves openness, but leaves higher exposure and relies on users noticing threats in time. d) Other / More discussion needed / None of the above. **Question 3:** How should we address external perception gaps (token sentiment and lack of public progress visibility) while staying aligned with execution excellence? **Context:** - `Discord (partners): concerns about "AI16Z token price decline"; HoneyBadger: "No major KOL shilling... competitors... shorting"` - `Discord (spartan_holders): "concern about lack of communication regarding development progress"; suggestion to restore/create a new DegenAI X account` **Multiple Choice Answers:** a) Adopt a disciplined comms rhythm: weekly ship log + monthly roadmap delta + release notes tied to reliability metrics. *Implication:* Builds trust without hype, making progress legible to outsiders and reducing rumor-driven narratives. b) Increase reach via partnerships/KOLs and events (roadshow/meetups) timed around stable releases and Cloud milestones. *Implication:* May accelerate adoption and token confidence, but risks distraction if the product isn’t stable enough. c) De-prioritize market optics; focus solely on shipping and let product quality speak later. *Implication:* Maximizes engineering focus, but may allow negative narratives to harden and slow ecosystem growth. d) Other / More discussion needed / None of the above.