Council Briefing

Key Deliberations

Developer Trust After the Plugin/Client Architecture Shift

The new “clients as plugins” structure (v0.25.8-era) improved modularity, but created configuration confusion and broken paths; March 1’s doc upgrades are a strong corrective, yet we still need a single canonical migration narrative and tooling guardrails to protect DX.

Do we declare a “DX Stability Window” where we freeze further breaking plugin/CLI interface changes until docs, templates, and upgrade tooling reach parity?

Discord (2025-02-27): “Version 0.25.8 Changes: Major structural changes to how plugins and clients are implemented.”
GitHub Summary (2025-03-01): “Enhanced readme.md to provide a how-to guide for custom plugins (PR #3736)… Updated plugins.md… (PR #3735).”

1Yes—freeze breaking DX changes for a defined window (e.g., 2–4 weeks) and focus on docs/templates/tooling.

Maximizes developer confidence and reduces support load, at the cost of slowing architectural iteration.

2Partial freeze—allow breaking changes only behind explicit version flags and migration tooling checks.

Preserves velocity while establishing a safety hull that prevents silent breakage for most builders.

3No—continue shipping rapidly; rely on community support and incremental documentation to catch up.

Short-term velocity stays high, but risks compounding churn and reputation damage among new adopters.

4Other / More discussion needed / None of the above.

Should the Council mandate a single “Golden Path” starter (character + plugins + env) per major version, and treat all other permutations as advanced/unsupported until maturity?

Discord 💻-coders (2025-02-28): “users adapting to the newer, cleaner ElizaOS architecture while troubleshooting implementation-specific issues.”
Discord (2025-02-27): “Add it as a plugin with "plugins": ["@elizaos-plugins/plugin-twitter", "@elizaos-plugins/client-twitter"]” (CARSON.ts)

1Yes—publish and maintain one canonical starter path per version, with automated validation.

Greatly reduces onboarding entropy and aligns with “Execution Excellence,” but narrows perceived flexibility.

2Maintain two paths: (A) minimal local dev, (B) cloud-first; everything else is community best-effort.

Balances choice with clarity, and maps cleanly to future Cloud adoption without abandoning self-hosters.

3No—keep many official permutations to demonstrate composability and breadth.

Signals openness but increases fragmentation, documentation surface area, and regression risk.

4Other / More discussion needed / None of the above.

How aggressively should we invest in “self-healing CLI” behaviors (detect missing plugins, auto-install dependencies, warn on deprecated config) to reduce Discord support burden?

Discord (2025-02-26): “Plugins and clients have been moved out of the core repository into separate packages that need to be explicitly added. This has caused confusion…”
Daily Report (2025-02-28): “Fixed an out-of-memory bug in version 0.25.8 (PR #3722).”

1High—CLI becomes the primary guardian: auto-detect, auto-fix, and block unsafe/broken configs.

Transforms DX, but requires rigorous versioning and careful security posture for auto-installs.

2Medium—CLI offers diagnostics and guided fixes, but requires explicit user confirmation for changes.

Reduces failures while keeping trust and transparency; moderate engineering cost.

3Low—keep CLI thin; prioritize framework stability and let advanced users manage dependencies manually.

Minimizes CLI complexity, but keeps onboarding friction high and increases community support demands.

4Other / More discussion needed / None of the above.

Memory, RAG, and Resource Reliability (OOM + Large Document Handling)

Operational signals show recurring heap OOM and RAG ingestion failures (PDFs, large files, whole-file embedding). March 1’s runtime guards and earlier OOM fixes are positive, but the Council must decide whether to treat knowledge/RAG as “core reliability work” versus “best-effort plugin territory.”

Do we elevate RAG ingestion (chunking, PDF parsing, large-doc safeguards) into a first-class reliability milestone, even if it delays other features?

GitHub Issue #3745 (2025-03-02): “RAG processFile attempts to embed entire files causing errors for large documents.”
Discord (2025-02-27): “It didn't work with PDFs, converting to txt format worked instead.” (Ale | AutoRujira)

1Yes—RAG is foundational; prioritize robust chunking + PDF support + backpressure now.

Improves real-world agent usefulness and reduces failure rates, strengthening “reliability over features.”

2Partially—ship minimal safe defaults (chunk caps, size limits, clear errors) and postpone full PDF support.

Prevents catastrophic failures quickly while keeping roadmap flexibility for deeper ingestion work later.

3No—keep RAG as plugin/community territory; focus core on agent runtime and Cloud reliability.

Preserves core focus, but risks losing developers who expect turnkey knowledge ingestion.

4Other / More discussion needed / None of the above.

What is the Council’s preferred stance on memory failures: raise default Node memory and document it, or fix underlying leaks/inefficiencies even if it’s slower?

Discord (2025-02-26): “Remove the "knowledge" field… or increase memory allocation with export NODE_OPTIONS='--max-old-space-size=8192'.” (sergii.bomko)
Daily Report (2025-02-28): “Fixed an out-of-memory bug in version 0.25.8 (PR #3722).”

1Raise defaults + document aggressively (fast relief), while continuing targeted OOM fixes opportunistically.

Quickly improves first-run success, but may mask structural issues and increase infra costs.

2Fix root causes first; keep defaults conservative and fail with clear diagnostics and guidance.

Best long-term reliability posture, but risks continued near-term onboarding pain.

3Hybrid: safe default bump plus strict limits for ingestion pipelines (caps, batching, streaming embeddings).

Balances success rate and correctness; requires coordinated engineering across core + knowledge tooling.

4Other / More discussion needed / None of the above.

Should we standardize an official “Knowledge Pipeline Contract” (formats, folder conventions, preprocessing steps) to reduce confusion and support load?

Discord discussion (2025-02-28): “questions about PDF file handling… directed to coders channel.”
Discord (2025-02-26): “workarounds… including removing the "knowledge" field from character files to prevent memory errors.”

1Yes—publish a strict contract (supported types, preprocessing, limits) and enforce it in tooling.

Reduces ambiguity and runtime surprises; may disappoint users expecting automatic format coverage.

2Publish a best-practices guide only; allow flexibility without enforcement.

Keeps composability high, but confusion and inconsistent behavior persist.

3Defer—focus on Cloud-first knowledge ingestion where the pipeline can be controlled end-to-end.

Simplifies support for Cloud users but may alienate self-hosters and open-source purists.

4Other / More discussion needed / None of the above.

Operational Dependencies: Web Presence, Social Accounts, and Governance Bottlenecks

Multiple external dependencies are constraining trust signals: eliza.gg is broken (maintainer gone), DegenAI’s X account remains suspended, and DAO.fun delays block token metadata/ticker migration. These are not just comms issues—they directly affect developer confidence and ecosystem coherence.

Do we treat web/docs presence (eliza.gg replacement, canonical links, onboarding) as a production service with ownership and uptime standards—on par with core releases?

Discord discussion (2025-02-28): “eliza.gg website is broken… Jin: they’ll set up a new site as the previous maintainer went AWOL.”

1Yes—assign explicit owners, SLA-style expectations, and automated link/uptime checks.

Strengthens first impression and reduces churn; requires sustained operational discipline.

2Partially—move to a static, repo-owned docs/site and minimize dynamic dependencies; no formal SLAs.

Improves resilience with low overhead, but still risks slow response to outages or broken flows.

3No—keep web presence lightweight; prioritize engineering output and let community mirror resources.

Saves bandwidth short-term but undermines “Developer First” and discoverability.

4Other / More discussion needed / None of the above.

Given repeated platform risk (X suspensions), should flagship agents adopt a multi-channel-first strategy (Farcaster/Telegram/Discord) with redundancy as a design requirement?

Discord (2025-02-26): “DegenAI is currently facing challenges with its X (Twitter) account suspension… appeal is pending.” (rhota)
Discord spartan_holders (2025-02-28): “The team is working to reintroduce DegenspartanAI to Discord and Farcaster… plans to use Telegram as the public channel.”

1Yes—treat distribution redundancy as mandatory; build and document a multi-client deployment playbook.

Reduces existential platform risk and aligns with interoperability, but increases operational complexity.

2Selective redundancy—only for flagship agents; community agents can choose platforms freely.

Protects core brand while keeping the broader ecosystem flexible.

3No—double down on X once reinstated; alternative platforms remain secondary experiments.

Concentrates attention where reach is largest, but leaves the project vulnerable to repeat suspensions.

4Other / More discussion needed / None of the above.

How should the Council respond to governance/vendor bottlenecks (e.g., DAO.fun delaying voting/metadata changes): wait, integrate alternatives, or build our own governance module?

Discord (2025-02-26): “bottleneck is DAO.fun’s delayed implementation of a voting module… promised ‘Q1–Q2’.”
Discord (2025-02-26): “Partners expressed frustration about the inability to change the token ticker… to match the ElizaOS rebrand.”

1Wait and pressure DAO.fun with a clear deadline and escalation path.

Lowest engineering cost, but risks prolonged brand incoherence and partner dissatisfaction.

2Integrate an interim alternative (Snapshot/Realms/EVM) while maintaining DAO.fun compatibility.

Restores momentum and reduces dependency risk; introduces governance fragmentation to manage.

3Build and own a governance module aligned with ElizaOS (agent-aware governance) and migrate.

Max control and strategic alignment, but significant build/migration burden and associated risk.

4Other / More discussion needed / None of the above.

North Star & Strategic Context

Key Deliberations