# Council Briefing: 2025-02-08 ## 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 core modularity via the handler-pattern refactor and CLI/character-loading fixes, but confidence is threatened by high-friction deployment failures (Docker startup hang), plugin usability gaps (plugin-evm), and degraded social execution (Twitter actions). ## Key Points for Deliberation ### 1. Topic: V2 Architecture Trajectory: Plugin Exodus → Registry + Dynamic Loading **Summary of Topic:** The project is mid-transition from a monorepo plugin model to independently maintained plugin repositories and a registry/CLI-driven install flow, with dynamic plugin loading targeted for April—this is strategically aligned with composability but risks a temporary DX cliff if not tightly curated and versioned. #### Deliberation Items (Questions): **Question 1:** Do we prioritize an opinionated, curated “golden path” plugin set for v2, or maximize openness by letting the registry remain largely community-governed from day one? **Context:** - `Discord (2025-02-07, Odilitime): "Plugins are being moved from the core repository to separate repositories under elizaos-plugins."` - `Discord (2025-02-06, Odilitime): "Dynamic plugin system... planned for April release."` **Multiple Choice Answers:** a) Curate a small, officially supported core plugin set with strict version gates and compatibility guarantees. *Implication:* Raises reliability and reduces support burden, but slows ecosystem breadth and may frustrate power users. b) Launch with an open registry and minimal curation; rely on community momentum and rapid iteration. *Implication:* Maximizes ecosystem growth but increases breakage risk, harming "developer trust through shipping." c) Hybrid: curated “blessed” lane plus an experimental lane with clear risk labels and automated compatibility checks. *Implication:* Balances composability with trust, but requires governance tooling and CI investment immediately. d) Other / More discussion needed / None of the above. **Question 2:** How hard should we commit to Bun as the default toolchain during the transition, given community reports that pnpm remains more stable in some setups? **Context:** - `Discord (2025-02-07, Sarthak): "v0.1.8-alpha.1 is considered the most stable... working well with pnpm."` - `Daily Summary (2025-02-07): "replacing pnpm with Bun (PR #2852)."` **Multiple Choice Answers:** a) Standardize on Bun now and invest in fixing edge cases; treat pnpm as legacy. *Implication:* Improves build speed and future capabilities, but risks near-term adoption friction and support load. b) Support both Bun and pnpm officially with a compatibility matrix and clear guidance per platform. *Implication:* Reduces onboarding failures but increases maintenance complexity and CI surface area. c) Delay the default switch; keep pnpm as default until v2 is stable, then move to Bun with a migration guide. *Implication:* Protects reliability narrative now, but delays toolchain modernization and internal velocity benefits. d) Other / More discussion needed / None of the above. **Question 3:** What is the Council’s definition of “dynamic plugin loading” success by April: UX simplicity, security/verification, or ecosystem scale? **Context:** - `Discord (2025-02-06, Odilitime): "v2... dynamic plugin system... April."` - `Issue (2025-02-08): "Unable to use plugin-evm after installation" (elizaos/eliza#3380).` **Multiple Choice Answers:** a) UX-first: one-command install, deterministic resolution, and clear errors for missing env/config. *Implication:* Directly advances "Developer First" and reduces Discord support churn. b) Security-first: signed plugins, provenance, sandboxing/permissions, and safer defaults. *Implication:* Strengthens long-term trust and governance aspirations, but may slow shipping and integration pace. c) Scale-first: maximize plugin throughput and community submissions with light governance. *Implication:* Accelerates ecosystem breadth, but risks fragmentation and inconsistent quality. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Reliability Firefighting: Docker Startup Hang, Plugin Usability, Twitter Actions **Summary of Topic:** Despite core refactors and CLI fixes landing, user-facing reliability is under strain: agents hang on startup in Docker/Cloud environments, plugin installation/use (notably EVM) is failing for some users, and Twitter agent actions are not processing—these issues directly threaten Execution Excellence and builder trust. #### Deliberation Items (Questions): **Question 1:** Should we declare a temporary “stability freeze” focused on deployment and social-client correctness before accepting additional ecosystem features? **Context:** - `GitHub Summary (2025-02-08): "Agents getting stuck on startup in Docker environments for v0.25.6-alpha.1 needs immediate investigation." (issue #3385)` - `GitHub Summary (2025-02-08): "Twitter actions not processing correctly." (issue #3384)` **Multiple Choice Answers:** a) Yes—freeze new features until Docker startup, plugin install/use, and Twitter actions meet a defined SLO. *Implication:* Reinforces Execution Excellence and reduces churn, but may slow visible momentum and partnerships. b) Partial freeze—only block merges touching runtime startup, packaging, and social clients; keep plugin additions flowing. *Implication:* Maintains ecosystem energy while protecting critical paths, but requires disciplined triage enforcement. c) No—continue parallel work; rely on rapid hotfix cadence and community contributions. *Implication:* Maximizes throughput, but risks compounding trust damage if reliability regressions persist. d) Other / More discussion needed / None of the above. **Question 2:** What is the canonical deployment target we support right now: local dev, Docker self-host, or cloud-hosted (managed) runtime? **Context:** - `Discord (2025-02-07, Tobiloba): "Minimal server requirements... 4 vCPUs and 4GB RAM."` - `GitHub Summary (2025-02-08): "Agents getting stuck on startup in Docker/Cloud environments" (issue #3385).` **Multiple Choice Answers:** a) Local-first: optimize the default path for local developer machines; treat Docker/cloud as secondary. *Implication:* Improves onboarding success quickly, but delays the platform narrative of scalable deployment. b) Docker-first: Docker is the canonical spec; everything else must conform. *Implication:* Creates deterministic deployments and paves the way for managed cloud, but increases friction for beginners. c) Cloud-first: position managed runtime as default; local/Docker are for advanced users only. *Implication:* Aligns with long-term platform strategy, but risks alienating open-source self-hosters if parity lags. d) Other / More discussion needed / None of the above. **Question 3:** How should the Council handle Twitter/X integration risk (rate limits, auth lockouts, action failures) as a flagship surface area? **Context:** - `Discord (2025-02-07, BOSSU): "Users experiencing Twitter rate limits... obtain proper API credentials rather than just using username/password."` - `Discord (2025-02-06, rubinovitz): "Twitter client aggressively log in... causing account lockouts."` **Multiple Choice Answers:** a) Harden X integration: enforce OAuth/API-key-only flows, add backoff, and ship a dedicated troubleshooting wizard. *Implication:* Reduces lockouts and support burden, improving trust, but increases implementation scope short-term. b) De-emphasize X: label it experimental and shift flagship examples to Discord/Telegram/web surfaces first. *Implication:* Protects reliability brand, but reduces reach and perceived agent autonomy in public channels. c) Abstract social clients: build a provider-agnostic social action layer and let X be just one adapter. *Implication:* Improves long-term composability, but does not immediately resolve current user pain. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Trust Through Documentation: Single Source of Truth in a Fragmenting Ecosystem **Summary of Topic:** As repos split (core vs eliza-starter vs plugin org) and behaviors change (supported knowledge formats, env var requirements, role gating), developers are hitting confusion and setup failures; consolidating and operationalizing documentation is now a strategic reliability initiative, not a cosmetic task. #### Deliberation Items (Questions): **Question 1:** What artifact becomes the Council’s “source of truth” for builders: docs site, CLI output, or a versioned FAQ embedded in the repo? **Context:** - `GitHub Summary (2025-02-08): "Clarification is needed for quick start instructions due to the eliza-starter being a separate repository." (issue #3387)` - `Discord (2025-02-07, Jin): "planning to update the docs and create an FAQ."` **Multiple Choice Answers:** a) Docs site as source of truth, with strict versioning per release and automated link validation in CI. *Implication:* Maximizes clarity and professionalism, but requires ongoing editorial discipline and tooling. b) CLI as source of truth, generating context-aware guidance (detected platform, missing env vars, plugin status). *Implication:* Turns documentation into runtime assistance, reducing support load, but increases engineering complexity. c) Repo-embedded FAQ/README as source of truth, mirrored to docs site periodically. *Implication:* Keeps contributors aligned in Git, but risks duplication and drift across surfaces. d) Other / More discussion needed / None of the above. **Question 2:** Should we formalize a compatibility matrix (Eliza version × package manager × OS/arch × plugin set) and gate releases on it? **Context:** - `Discord (2025-02-07, Sarthak): "v0.1.8-alpha.1... works fine with pnpm."` - `Discord (2025-02-07, JAMES): "Dependency version mismatch in eliza-starter... opened a PR to fix it."` **Multiple Choice Answers:** a) Yes—publish and enforce a matrix; releases must pass a minimal set of blessed environments. *Implication:* Builds trust via predictability, but slows releases and increases CI costs. b) Publish a matrix but do not gate releases; treat it as guidance only. *Implication:* Improves transparency with minimal slowdown, but allows regressions to reach users. c) Skip the matrix; focus on a single canonical environment and provide best-effort support elsewhere. *Implication:* Simplifies engineering, but risks alienating diverse builders and increasing Discord support noise. d) Other / More discussion needed / None of the above. **Question 3:** How should we resolve knowledge ingestion confusion (JSON vs txt/md) without expanding scope into a brittle document-format zoo? **Context:** - `Discord (2025-02-06, ꧁Ninja_Dev꧂): "Only .txt or .md files are supported, not JSON."` - `Discord (2025-02-07, ꧁Ninja_Dev꧂): "Use ragKnowledge: true... place text or MD files in the knowledge folder."` **Multiple Choice Answers:** a) Keep formats strict (txt/md only) and ship conversion tools/templates (e.g., JSON→MD pipelines) as first-class docs. *Implication:* Preserves reliability while meeting users where they are via tooling, not runtime complexity. b) Add JSON as a supported knowledge format with a defined schema and validation. *Implication:* Reduces friction for structured sources, but increases parser surface area and support complexity. c) Support pluggable knowledge loaders via plugins; core remains strict, ecosystem extends formats. *Implication:* Aligns with composability and plugin strategy, but may fragment user experience without curation. d) Other / More discussion needed / None of the above.