# Council Briefing: 2025-02-11 ## 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 - Operational reliability took priority as critical developer-blocking failures (.env not read; startup hanging at LlamaService; PostgreSQL long-message errors) surfaced alongside ongoing hardening work (tests, validation, DB path fixes), making “trust through shipping” the dominant imperative. ## Key Points for Deliberation ### 1. Topic: Reliability Incidents: Boot, Config, and Database Failure Modes **Summary of Topic:** Three high-severity issues threaten developer trust: environment configuration not loading, server hangs during LlamaService initialization, and PostgreSQL errors on long messages; these are now the clearest obstacles to execution excellence and smooth onboarding. #### Deliberation Items (Questions): **Question 1:** Do we declare a reliability freeze (no new features) until the boot/config path and startup hang are resolved across common environments? **Context:** - `GitHub Daily (2025-02-11): "Urgent Discussion: .env file is not being read" (Issue #3449).` - `GitHub Daily (2025-02-11): "pnpm start process is hanging during LlamaService initialization" (Issue #3448).` **Multiple Choice Answers:** a) Yes—impose a short reliability freeze with a defined exit criterion (issues closed + regression tests). *Implication:* Maximizes developer trust and stabilizes onboarding at the cost of temporarily slowing new capability throughput. b) Partial—allow limited feature work only if coupled with tests and does not touch boot/runtime paths. *Implication:* Preserves momentum while reducing risk, but may prolong the time-to-stability if attention remains split. c) No—continue parallel feature development; treat the incidents as normal churn during rapid growth. *Implication:* Maintains velocity, but risks reputational damage and higher support load if new users keep hitting blockers. d) Other / More discussion needed / None of the above. **Question 2:** Which “known-good” runtime environment should we canonize for V1/V2 to reduce support entropy (Node/pnpm/bun matrix)? **Context:** - `Discord (2025-02-09): "Recommended environment ... Node.js v23.3.0 and pnpm v9.15.4." (Sarthak).` - `Discord (2025-02-10): "Running multiple Eliza agents requires ~1.5–3GB RAM per agent" (coders channel summary).` **Multiple Choice Answers:** a) Canonize Node 23.3 + pnpm 9.15.4 as the single supported baseline; document others as “best-effort.” *Implication:* Reduces variability and support burden; may frustrate teams standardized on older LTS stacks. b) Support two baselines: Node LTS (e.g., 20/22) and Node 23.x; automate CI coverage for both. *Implication:* Improves adoption and enterprise friendliness, but increases CI and maintenance overhead. c) Move decisively toward Bun-first (with pnpm as compatibility) and focus all docs/CI on Bun. *Implication:* Potentially improves speed and DX, but amplifies breakage risk during the transition period. d) Other / More discussion needed / None of the above. **Question 3:** How should we handle long-message and knowledge ingestion constraints to prevent database/runtime instability (Postgres + RAG memory growth)? **Context:** - `GitHub Daily (2025-02-11): "Long messages are causing errors with PostgreSQL" (Issue #3441).` - `GitHub Issues Summary (2025-02-10): "RagKnowledge ... cleaned up during runtime initialization" / "ragKnowledge handling for stringKnowledge" (Issues #3440, #3434).` **Multiple Choice Answers:** a) Implement strict message/knowledge size limits with graceful truncation + user-visible warnings. *Implication:* Stabilizes systems quickly and predictably, but may reduce capability for power users with large contexts. b) Adopt streaming/segmented storage: chunk long messages and store embeddings incrementally with backpressure. *Implication:* Preserves capability and scales better, but requires more engineering and careful compatibility testing. c) Offload large-context handling to a dedicated knowledge service (external DB/vector store) and keep core lean. *Implication:* Improves core robustness and composability, but increases deployment complexity for self-hosters. d) Other / More discussion needed / None of the above. --- ### 2. Topic: V2 Readiness and Modular Architecture Direction **Summary of Topic:** The community is aligned on an impending V2 (beta March, GA April) and is already pushing for structural modularity (/sources plugins vs /packages core); Council must decide how to balance schedule credibility against architecture refactors that improve selective installs and DX. #### Deliberation Items (Questions): **Question 1:** Should the Council protect the V2 Beta/GA dates by deferring major repo restructuring, or accept schedule slip in favor of modular installation as a V2 pillar? **Context:** - `Discord (2025-02-10): "V2 Timeline: Beta release in March, GA release in April 2025" (kalshnikov).` - `Discord (2025-02-10): "Proposal to organize into /sources (optional plugins) and /packages (core functionality)" (discussion summary).` **Multiple Choice Answers:** a) Protect dates—ship V2 with minimal restructuring; schedule a post-GA modularization milestone. *Implication:* Strengthens shipping credibility, but may prolong dependency bloat and installation confusion. b) Modular-first—make selective install the core of V2 even if GA slips modestly. *Implication:* Improves DX and long-term maintainability, but risks trust if timelines repeatedly slide. c) Hybrid—ship Beta on time, but gate GA on completion of the restructuring + migration tooling. *Implication:* Keeps momentum and community testing while ensuring the final release meets execution-excellence standards. d) Other / More discussion needed / None of the above. **Question 2:** What is our official stance on plugin ecosystem expansion versus stability (new plugins are arriving rapidly while core incidents persist)? **Context:** - `GitHub Activity (2025-02-10 to 2025-02-12): "29 new pull requests (8 merged) ... active contributor participation."` - `GitHub PRs (2025-02-10.json): "Multiple new plugins introduced ... D.A.T.A, Navi, Bluefin" (PRs #3421, #3417, #3425, #3427).` **Multiple Choice Answers:** a) Prioritize stability—tighten merge gates for new plugins until core reliability KPIs improve. *Implication:* Reduces breakage surface area and support load, but may slow ecosystem growth and partner excitement. b) Parallel tracks—continue plugin expansion but require standardized tests/CI templates for all plugins. *Implication:* Sustains momentum while improving quality through process; requires investment in tooling and enforcement. c) Ecosystem-first—accelerate plugin intake to win mindshare; accept higher churn temporarily. *Implication:* May win short-term attention, but risks violating the “reliability over feature quantity” principle. d) Other / More discussion needed / None of the above. **Question 3:** Do we formalize multi-agent orchestration as a near-term framework capability (to match demand), or keep it as an advanced pattern documented outside core? **Context:** - `Discord (2025-02-10): "What's the best way to have agents working with each other? ... orchestration/manager framework?" (unanswered; discussion/coders logs).` - `Discord (2025-02-10): "Create guide for agent-to-agent communication" (action item; joseroberts87).` **Multiple Choice Answers:** a) Core capability—define a minimal orchestration API in V2 (agent-to-agent calls, permissions, tracing). *Implication:* Differentiates platform and enables composable swarms, but increases scope and security complexity. b) Docs-first—publish validated orchestration patterns and a reference “manager agent” without core changes. *Implication:* Delivers value quickly with low risk, but may limit standardization and interoperability across projects. c) Plugin-layer—ship orchestration as an official plugin package with versioned contracts. *Implication:* Maintains core simplicity while enabling modular adoption, but may fragment implementations if not governed tightly. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Trust Surfaces: Security of Agent-Managed Funds & Operational Exposure **Summary of Topic:** Community discussion highlights a credibility risk around agents handling funds and exposed clients/services; we must define a security posture (vaults, policy controls, TEEs vs wallet abstractions) before pushing deeper into DeFAI and autonomous finance narratives. #### Deliberation Items (Questions): **Question 1:** What security baseline should we declare for any agent that can move value (funds, contracts, LP interactions) before it is showcased as a flagship capability? **Context:** - `Discord ideas-feedback-rants (2025-02-10): "Security mechanisms for agent-managed funds" (TAISER Andy).` - `Discord (2025-02-10): "Reference to Lit Agent Wallet as an improvement for controls and key handling" (ideas-feedback-rants summary).` **Multiple Choice Answers:** a) Smart-contract vault + policy guardrails (spending limits, allowlists, time locks) as mandatory baseline. *Implication:* Creates robust on-chain safety and auditability, improving trust for DeFAI and cloud deployments. b) Wallet abstraction baseline (e.g., Lit Agent Wallet) with strong key management and human override. *Implication:* Faster to ship and integrate, but may provide weaker guarantees than enforceable on-chain constraints. c) No baseline yet—limit fund-moving to experimental status with explicit disclaimers until later. *Implication:* Reduces liability and risk now, but may slow market positioning in autonomous finance narratives. d) Other / More discussion needed / None of the above. **Question 2:** Should TEEs be part of our security story, given reliability concerns ("instances die"), or should we treat them as optional hardening only? **Context:** - `Discord ideas-feedback-rants (2025-02-10): "TEE instances die pretty frequently" (TAISER Andy).` **Multiple Choice Answers:** a) Optional—support TEEs via plugins/integration guides, but do not make them a recommended default. *Implication:* Avoids operational fragility while preserving a path for high-security deployments. b) Recommended—invest in TEE-first operational tooling (recovery, attestation, key rotation) as a differentiator. *Implication:* Could raise the ceiling for trust and enterprise adoption, but increases complexity and on-call burden. c) Deprioritize—focus on vault/policy systems and remove TEE messaging from near-term roadmap. *Implication:* Simplifies narrative and engineering scope, but may concede a perceived security advantage to competitors. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should we lock down exposed interfaces (e.g., DirectClient/public IP) to prevent RCE-class incidents as the ecosystem scales? **Context:** - `Discord (2025-02-09): "Security concerns ... exposing DirectClient to public IPs and potential RCE vulnerabilities" (daily summary).` **Multiple Choice Answers:** a) Ship secure-by-default: bind to localhost, require auth tokens, and document reverse-proxy best practices. *Implication:* Prevents preventable incidents and builds trust with developers deploying in the wild. b) Add a “deployment profile” wizard (local/dev/prod) that configures secure defaults but remains flexible. *Implication:* Improves DX and reduces misconfigurations, but requires additional product work and maintenance. c) Rely on documentation warnings only; keep current defaults to reduce friction for quick demos. *Implication:* Maximizes ease-of-start but increases the probability of serious security incidents and reputational harm. d) Other / More discussion needed / None of the above.