# Council Briefing: 2025-02-07 ## 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 executed a high-risk architectural pivot (dynamic plugin loading + Bun migration) while simultaneously surfacing build/UI regressions that now threaten reliability—our primary trust currency with developers. ## Key Points for Deliberation ### 1. Topic: V2 Plugin Architecture Pivot & Build Stability **Summary of Topic:** A sweeping plugin-system overhaul (including deleting monorepo plugins and shifting to dynamic loading) is strategically aligned with composability, but the transition is currently creating build and dependency hazards that erode DX trust. #### Deliberation Items (Questions): **Question 1:** Do we freeze further architectural refactors until the new dynamic plugin loading path is "boring-stable" for new developers (install → run → load character → UI)? **Context:** - `GitHub daily (2025-02-07): "Missing `cors` and `multer` dependencies in `@elizaos/agent` are causing build issues" (issue #3365).` - `GitHub daily (2025-02-07): "UI fails to load correctly when starting the service with a specific character file" (issue #3360).` **Multiple Choice Answers:** a) Yes—declare a stabilization window (1–2 weeks) with a hard gate: no new refactors, only build/UX blockers and docs. *Implication:* Maximizes developer trust and reduces support load, but may delay V2 feature velocity. b) Partial freeze—allow refactors only if paired with tests, migration notes, and a green e2e "golden path" workflow. *Implication:* Balances momentum with safety, but still risks churn if enforcement is inconsistent. c) No—continue the pivot at full speed and accept short-term instability as the cost of reaching V2. *Implication:* Accelerates long-term architecture, but risks reputational damage and community burnout during the transition. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s preferred operational model for plugins post-split (elizaos-plugins org): centrally curated vs federated autonomy? **Context:** - `GitHub daily summary (2025-02-06): "All plugins were deleted (#3342) to support a new dynamic plugin loading system (#3339)."` - `Discord (2025-02-06, coders): "Eliza is moving plugins to separate repositories under elizaos-plugins organization" (Odilitime).` **Multiple Choice Answers:** a) Centrally curated: strict compatibility matrix, required CI, and version pinning enforced by the core team. *Implication:* Improves reliability and DX, but increases governance overhead and slows plugin experimentation. b) Federated: minimal standards, community-owned plugins, and best-effort compatibility with fast iteration. *Implication:* Maximizes ecosystem growth, but creates fragmentation and more breakage for builders. c) Hybrid: tiered plugin registry (Core/Verified/Community) with different guarantees and automation. *Implication:* Creates a scalable trust ladder—aligns with composability while preserving execution excellence for critical paths. d) Other / More discussion needed / None of the above. **Question 3:** Should Bun adoption be treated as mandatory now, or should we maintain a pnpm compatibility lane until Cloud + framework reliability targets are met? **Context:** - `GitHub daily (2025-02-07): "Replaced pnpm with Bun" (PR #2852).` - `GitHub issues mention: "pnpm build failed" style reports persisted during this period (e.g., issue #3316 in daily rollup).` **Multiple Choice Answers:** a) Mandatory Bun now—reduce matrix complexity and optimize for the future runtime-loading roadmap. *Implication:* Simplifies core engineering but may alienate teams with locked CI/tooling or enterprise constraints. b) Dual-lane support—Bun preferred, pnpm supported via documented fallback until a defined deprecation date. *Implication:* Protects DX during migration but increases maintenance overhead and can slow stabilization. c) Rollback to pnpm temporarily—only reintroduce Bun when integration tests and installer UX are mature. *Implication:* De-risks short-term shipping but undermines architectural momentum and could confuse contributors. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Agent Reliability on Social Rails (Twitter/Embeddings/Telegram) **Summary of Topic:** High-friction operational issues—Twitter auth/lockouts, rate limits, and embedding dimension mismatches—are repeatedly blocking builders, threatening the "reliable by default" promise and increasing community support burden. #### Deliberation Items (Questions): **Question 1:** Should we temporarily de-emphasize Twitter automation (posting/mentions) in the default experience until we ship safer auth + rate-limit safeguards? **Context:** - `Discord (2025-02-06): "Twitter authentication... aggressive login attempts causing account lockouts" (rubinovitz, efiz).` - `Discord Q&A (2025-02-06): "gateway timeout error on twitter" → "That's a rate limit, give it some space to breathe" (BOSSU).` **Multiple Choice Answers:** a) Yes—make Twitter features explicitly opt-in and disabled by default; prioritize safety guardrails. *Implication:* Reduces user harm and support load, but slows growth of flagship social agents and demos. b) Keep defaults, but ship a hardened Twitter client: exponential backoff, session reuse, and clear warnings in setup. *Implication:* Maintains momentum while reducing risk, but may still fail under API volatility and enforcement changes. c) Replace with alternative-first social rails (Farcaster/Telegram/Discord) and position Twitter as experimental. *Implication:* Improves reliability perception, but may weaken market visibility where X is the primary distribution channel. d) Other / More discussion needed / None of the above. **Question 2:** How do we enforce embedding dimension consistency across providers so that RAG and social memory do not crash at runtime? **Context:** - `Discord (2025-02-06, coders): "Vector dimension mismatch errors (384 vs 1536)" (engineer).` - `Discord Q&A (2025-02-06): fix suggestion: "Try turning on and off OpenAI embeddings" (Odilitime).` **Multiple Choice Answers:** a) Hard enforcement: store dimension in DB schema + block startup if configured model and DB dimension differ; auto-migrate with explicit user confirmation. *Implication:* Strong reliability and predictability, but requires careful migrations and clearer error messaging. b) Soft enforcement: auto-detect and dynamically adapt by re-embedding silently when mismatches appear. *Implication:* Smoother UX, but risks hidden costs (compute/time) and unclear provenance for vector stores. c) Documentation-first: provide a matrix of supported embeddings and leave enforcement to developers. *Implication:* Low engineering cost, but contradicts execution excellence and keeps support load high. d) Other / More discussion needed / None of the above. **Question 3:** Do we standardize a "safe-by-default" posture for credentialed integrations (X, Telegram, others) with an explicit OPSEC workflow and dev-mode sandbox accounts? **Context:** - `Discord (2025-02-06, discussion): "Is there a way for a dev to work on the agent without me giving them my X account password?" → "never share passwords" (BOSSU).` - `Action items (2025-02-06): "Create guide for setting up secure dev environments without sharing social media credentials" (Slothify⚡Daily Gmove).` **Multiple Choice Answers:** a) Yes—ship an official "Credential Proxy / Secrets Operator" pattern + docs + sample repos as a priority. *Implication:* Builds deep trust and enterprise readiness, aligning strongly with the North Star. b) Add minimal warnings and best practices in docs, but no official workflow yet. *Implication:* Fast and low-cost, but leaves users exposed and increases reputational risk if accounts are compromised. c) Defer entirely until after Cloud launch; rely on community guidance. *Implication:* Preserves short-term focus, but violates "trust through shipping" and may slow adoption. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Governance Signal, Roadmap Clarity, and Launchpad/Tokenomics Readiness **Summary of Topic:** Leadership messaging improved with the new COO and claims of 95% completion on launchpad/tokenomics, but partners and builders still experience uncertainty; we need a tighter comms cadence and a published roadmap to convert progress into trust. #### Deliberation Items (Questions): **Question 1:** Do we set a hard public roadmap checkpoint (date + scope) even if market conditions delay tokenomics/launchpad release? **Context:** - `Discord partners (2025-02-06): "Launchpad & tokenomics... 95% complete but awaiting better market conditions" (accelxr).` - `Discord partners (2025-02-06): "A CPO is putting together a roadmap... targeting next week" (accelxr).` **Multiple Choice Answers:** a) Yes—publish the roadmap with clear dependency flags (market-sensitive vs ship-ready engineering milestones). *Implication:* Strengthens credibility and reduces rumor-driven volatility, even if releases are staged. b) Publish only engineering roadmap; keep tokenomics/launchpad timing private until conditions improve. *Implication:* Reduces speculative pressure, but may prolong partner frustration about direction and utility. c) Delay roadmap until launchpad and tokenomics can be announced together for maximum narrative impact. *Implication:* Optimizes marketing timing, but risks ongoing trust erosion and community fatigue. d) Other / More discussion needed / None of the above. **Question 2:** What is our minimum viable communications protocol to uphold "Trust Through Shipping" across Discord/GitHub/X without overloading the core team? **Context:** - `Discord partners (2025-02-06): "New protocols for communicating updates across social media are being prioritized" (accelxr, witch).` - `Action items (2025-02-06): "Establish better communication protocols for updates across platforms" (accelxr).` **Multiple Choice Answers:** a) Weekly "Council Dispatch": one canonical update repo/page auto-syndicated to Discord/X/email, with owners per domain (core, cloud, flagship agents). *Implication:* Creates a predictable heartbeat and reduces chaos, aligning with Taming Information goals. b) Daily micro-updates only when major PRs ship; otherwise keep comms ad-hoc. *Implication:* Lower overhead, but perpetuates partner uncertainty and makes the project feel directionless. c) Delegate to community curators (with token incentives) to produce summaries, with core team only approving. *Implication:* Scales communication, but requires governance controls to prevent misinformation and narrative drift. d) Other / More discussion needed / None of the above. **Question 3:** How should we sequence brand unification (ElizaOS) with token identity (ai16z) to reduce confusion while preserving continuity? **Context:** - `Discord partners (2025-02-06): "Plans to clean up scattered branding under ElizaOS while maintaining ai16z as the token name" (accelxr).` - `Discord (2025-02-05): "transitioning from ai16zdao branding to elizaOS for better clarity".` **Multiple Choice Answers:** a) Immediate brand consolidation: one website/docs identity (ElizaOS), with clear token labeling (ai16z) and migration FAQ pinned everywhere. *Implication:* Reduces onboarding friction quickly and improves developer confidence. b) Gradual migration: keep dual branding during a transition period with cross-links and a deprecation timeline. *Implication:* Minimizes shock to existing holders, but sustains confusion longer. c) Token-first narrative: lead with ai16z brand and treat ElizaOS as a sub-brand until launchpad/tokenomics ship. *Implication:* May help short-term market narrative, but conflicts with the goal of a developer-first framework identity. d) Other / More discussion needed / None of the above.