# Council Briefing: 2025-02-28 ## 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 execution excellence by shipping critical stability and DX upgrades (notably the 0.25.8 out-of-memory repair), but a widening gap between fast-moving architecture changes and user-facing documentation continues to threaten developer trust. ## Key Points for Deliberation ### 1. Topic: Reliability Under Fire: Knowledge Memory & OOM Containment **Summary of Topic:** A critical out-of-memory fault affecting v0.25.8 (especially around knowledge/RAG usage) has been patched, yet community reports show ongoing confusion and workaround-driven behavior (disabling knowledge, increasing heap), signaling an incomplete reliability story. #### Deliberation Items (Questions): **Question 1:** Do we declare the 0.25.8 OOM fix a release-blocking reliability milestone (hotfix + comms), or treat it as an incremental patch while prioritizing other roadmap items (Cloud/token migration)? **Context:** - `GitHub PR: "Resolved an out-of-memory bug in version 0.25.8" (#3722).` - `Discord (2025-02-26): sergii.bomko workaround: "Remove the 'knowledge' field... or increase memory allocation with NODE_OPTIONS..."` **Multiple Choice Answers:** a) Treat as release-blocking: ship a reliability hotfix release, publish a prominent advisory, and verify with reproduction tests. *Implication:* Maximizes trust-through-shipping and reduces support load, but may slow feature delivery. b) Treat as incremental: merge and move on; monitor issue volume while keeping roadmap velocity. *Implication:* Maintains throughput, but risks prolonged developer churn if the field still experiences failures. c) Split-the-difference: ship the fix plus an opt-in 'knowledge/RAG stability mode' with guardrails and telemetry. *Implication:* Creates a safer default path without freezing progress, but adds short-term engineering complexity. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s canonical stance on knowledge ingestion formats (PDF vs. text) for the near term: do we support PDFs natively now, or formally narrow scope to text-first to protect reliability? **Context:** - `Discord (2025-02-27): "It didn't work with PDFs, converting to txt format worked instead" (Ale | AutoRujira).` - `Action item repeated across logs: "Implement proper PDF support for RAG knowledge" (Redvoid).` **Multiple Choice Answers:** a) Ship native PDF support immediately (core or plugin-knowledge), with test fixtures and failure-safe parsing. *Implication:* Improves UX and reduces hacks, but expands the surface area for reliability regressions. b) Adopt text-first policy: officially recommend conversion workflows and postpone PDF ingestion until v2 memory pipeline. *Implication:* Protects execution excellence today, but may frustrate builders expecting modern document support. c) Hybrid approach: provide an officially supported PDF→text preprocessor tool (CLI/plugin) rather than full PDF RAG. *Implication:* Delivers a guided, reliable path with minimal complexity while keeping full support on a later track. d) Other / More discussion needed / None of the above. **Question 3:** Should we formalize memory budgets and guardrails (chunking limits, embedding constraints, backpressure) as part of the framework contract to prevent recurrence of heap failures? **Context:** - `Discord (2025-02-25): repeated "JavaScript heap out of memory" reports tied to knowledge bases in v0.25.8.` - `GitHub PR: "fix: fix 0.25.8 oom bug... repair some block logic" (#3722).` **Multiple Choice Answers:** a) Yes—define and enforce hard limits with clear errors (max doc size, max chunks, max tokens) and safe defaults. *Implication:* Raises baseline reliability and predictability, but constrains some advanced use cases. b) No—keep limits flexible and rely on documentation + community tuning (NODE_OPTIONS, chunk sizes). *Implication:* Preserves flexibility, but keeps the platform in a 'tribal knowledge' state that harms DX. c) Partially—soft limits with warnings, plus an 'enterprise/high-memory' profile for Cloud deployments. *Implication:* Balances DX and power-users, and aligns with Cloud monetization, but requires profiling/telemetry work. d) Other / More discussion needed / None of the above. --- ### 2. Topic: DX Drift: Plugin/Client Decoupling and Migration Clarity **Summary of Topic:** The new architecture (clients as plugins, plugins moved out of core) is strategically sound for composability, but community confusion indicates the migration path and docs are lagging—undermining the Developer First principle. #### Deliberation Items (Questions): **Question 1:** Do we introduce a backward-compatibility shim (e.g., auto-mapping the legacy `clients` array to plugin packages) to protect developer trust, or enforce a clean break to accelerate the new plugin ecosystem? **Context:** - `Discord (2025-02-27): "Clients now need to be added as plugins... rather than specified in the 'clients' array."` - `Discord (2025-02-27): CARSON.ts example: "plugins": ["@elizaos-plugins/plugin-twitter", "@elizaos-plugins/client-twitter"].` **Multiple Choice Answers:** a) Add a compatibility shim for 1–2 releases, with deprecation warnings and auto-fixes in the CLI. *Implication:* Reduces breakage and support burden, preserving trust while still converging on the new model. b) No shim—strict new format only; invest in docs and migration guides instead. *Implication:* Speeds ecosystem standardization, but risks alienating builders and increasing churn. c) Selective shim—only for top clients (Twitter/Discord/Slack) while leaving niche clients as strict plugins. *Implication:* Protects the majority of users while limiting maintenance cost, but creates uneven expectations. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s minimum 'migration contract' for a breaking architecture change (docs, tooling, examples, automated checks) before declaring it complete? **Context:** - `Action items (2025-02-26/27): "Update documentation for v0.25.8 plugin and client architecture" and "Create guide for migrating from v0.1.9 to v0.25.8."` - `GitHub PR: "Improved plugin loading error handling and added JSON5 support for character files" (#3698).` **Multiple Choice Answers:** a) Require docs + migration guide + CLI lints + example characters updated before any breaking release is 'done'. *Implication:* Institutionalizes execution excellence and lowers support load, but slows breaking changes. b) Docs and examples only; keep tooling lightweight to preserve velocity. *Implication:* Maintains speed, but may fail to prevent misconfigurations at scale. c) Tooling-first: ship CLI validators and auto-migrators, then allow docs to catch up iteratively. *Implication:* Prevents common failures immediately, but requires upfront investment in CLI engineering. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should we standardize plugin packaging and discovery (registry, naming, install UX) to make 'open & composable' feel seamless for developers? **Context:** - `GitHub PR: "Enhanced CLI installation process" (#3697).` - `Discord (2025-02-27): confusion about missing clients: "Where is the slack-client in v0.25.8?" (answered: add `elizaos-plugins/client-slack`).` **Multiple Choice Answers:** a) Aggressive standardization: enforce naming conventions, registry metadata, and compatibility tests for published plugins. *Implication:* Creates a dependable ecosystem and improves DX, but raises the bar for community contributions. b) Light standardization: best-practice templates and optional registry checks. *Implication:* Keeps contributions easy, but risks a fragmented ecosystem and inconsistent UX. c) Dual-track: 'Core Certified' plugins with strict standards, and 'Community' plugins with minimal constraints. *Implication:* Balances openness and reliability, and provides a clear trust signal for developers. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Cross-Chain Vector & Trust Politics: plugin-EVM + Governance Transparency **Summary of Topic:** Demand is rising for EVM capabilities (plugin-evm) while governance and tokenomics debates (tribute token utilization, DAO.fun voting dependency) risk eroding trust; the Council must align cross-chain technical expansion with credible governance signals and information transparency. #### Deliberation Items (Questions): **Question 1:** Do we prioritize an official EVM plugin path now (to match the North Star of cross-chain interoperability), even if it increases maintenance and security burden? **Context:** - `GitHub issue: "Add plugin-evm" (#3723) flagged as needing attention.` - `GitHub daily triage (2025-02-28): "bug reported when attempting to add the plugin-evm... potential integration issues with the plugin system."` **Multiple Choice Answers:** a) Yes—declare EVM support a top-tier capability and staff it as a first-class plugin with security review. *Implication:* Accelerates multi-chain adoption and ecosystem growth, but increases security and maintenance obligations. b) Not yet—defer official EVM support until the plugin system hardens and v2 security posture is clearer. *Implication:* Reduces risk during architectural transition, but may lose builders to more complete frameworks. c) Enable via community track—publish a reference spec and guardrails, but keep it uncertified until maturity. *Implication:* Unlocks experimentation without overcommitting the core team, while still signaling cross-chain intent. d) Other / More discussion needed / None of the above. **Question 2:** How should the Council break the DAO.fun voting bottleneck to restore governance credibility and unblock rebrand/ticker changes—wait, fork, or parallelize governance? **Context:** - `Discord (2025-02-26): "bottleneck is DAO.fun's delayed implementation of a voting module" (partners).` - `Discord (2025-02-25): exchanges want community vote proof for rebrand/ticker update (jasyn_bjorn).` **Multiple Choice Answers:** a) Wait and pressure DAO.fun, aligning all changes behind the official module once delivered. *Implication:* Keeps a single canonical governance system, but prolongs reputational damage and operational delays. b) Parallelize immediately with an alternative (Snapshot/Realms/EVM-compatible tooling) and later reconcile. *Implication:* Restores momentum and credibility faster, but introduces governance fragmentation risk. c) Replace DAO.fun path: migrate governance to a new stack as part of the broader execution excellence push. *Implication:* Creates long-term control and flexibility, but is operationally heavy and politically sensitive. d) Other / More discussion needed / None of the above. **Question 3:** What transparency standard should govern tribute token utilization (including single-sided LP sales) to preserve alignment and prevent partner distrust? **Context:** - `Discord 🥇-partners (2025-02-27): concern that tribute tokens are being sold via "single-sided liquidity pools" (dral).` - `Discord 🥇-partners (2025-02-27): Patt: "the terms should be clear" regarding tributes.` **Multiple Choice Answers:** a) Adopt strict disclosure: public ledger dashboards, explicit policy, and pre-announced disposal schedules. *Implication:* Builds trust and reduces rumor-driven conflict, but constrains treasury flexibility. b) Maintain discretionary treasury operations with only high-level reporting. *Implication:* Maximizes operational flexibility, but increases perceived opacity and partner dissatisfaction. c) Create opt-in tribute agreements: each project selects a utilization template (lock, vest, LP rules). *Implication:* Aligns incentives project-by-project and reduces conflict, but adds administrative complexity. d) Other / More discussion needed / None of the above.