# Council Briefing: 2025-01-06 ## 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 - Stability and trust posture improved via rapid bugfix throughput and new safeguards, but deployment/runtime regressions (Docker text generation, Postgres startup failures) remain the highest-threat vector to execution excellence. ## Key Points for Deliberation ### 1. Topic: Reliability Gate: Build & Deployment Stability **Summary of Topic:** Core compilation and runtime stability saw meaningful fixes (postinstall, type errors, null checks), yet the operational frontier shifted to deployment reliability, with new reports of Dockerized agents failing to generate text and PostgreSQL adapter startup failures. #### Deliberation Items (Questions): **Question 1:** Do we institute a "release train + stability gate" that prioritizes deployment/runtime correctness over new plugin merges for the next cycle? **Context:** - `GitHub Daily Update (Jan 6, 2025): "Identified a bug where the agent fails to generate text when dockerized" (#1925).` - `GitHub Daily Update (Jan 6, 2025): "Raised a concern about the agent's random startup failures when using the PostgreSQL adapter" (#1914).` **Multiple Choice Answers:** a) Yes—freeze non-critical feature merges and run a stability sprint until Docker + Postgres paths are green. *Implication:* Short-term feature velocity slows, but developer trust increases via fewer broken deployments. b) Partial—allow plugin merges but require stricter CI and runtime checks on core + adapters before merge. *Implication:* Balances ecosystem growth with stability, but risks continued user pain if regressions slip through. c) No—keep feature velocity high and treat deployment bugs as best-effort patches post-merge. *Implication:* Maximizes expansion but undermines the North Star of reliability and risks community churn. d) Other / More discussion needed / None of the above. **Question 2:** Which runtime surface should be treated as the canonical 'production path' for reliability testing: Docker images, bare-metal Node, or Cloud deployments? **Context:** - `GitHub Daily Update (Jan 6, 2025): "agent fails to generate text when dockerized" (#1925).` - `Discord (2025-01-03): "Node.js version 23.3.0 is recommended over newer versions for compatibility."` **Multiple Choice Answers:** a) Docker-first: treat Docker as the primary production target and gate releases on it. *Implication:* Improves deployability and aligns with Cloud, but may increase CI complexity and build times. b) Bare-metal Node-first: optimize for local DX and let Docker lag slightly. *Implication:* Eases contributor workflows but risks production incidents for teams deploying containerized agents. c) Cloud-first: define ElizaOS Cloud as the reference runtime, with Docker/Node considered secondary targets. *Implication:* Tightens managed-platform experience, but could erode open-source trust if self-hosting becomes brittle. d) Other / More discussion needed / None of the above. **Question 3:** Do we standardize a supported-version matrix (Node + database + OS) and enforce it via tooling (devcontainer, preflight checks)? **Context:** - `Discord (2025-01-03): "Node.js version 23.3.0 is recommended over newer versions for compatibility."` - `GitHub Updates (Jan 5): "Added devcontainer support" (PR #1807).` **Multiple Choice Answers:** a) Yes—publish an official compatibility matrix and fail fast when outside it. *Implication:* Reduces support burden and increases predictability, but constrains edge-case users. b) Soft guidance only—publish recommendations but do not enforce them. *Implication:* Maintains flexibility but keeps support load high and failures more frequent. c) No—focus on broad compatibility and avoid declaring a matrix until Cloud is dominant. *Implication:* Avoids fragmentation optics but risks perpetual breakage across environments. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Security & Verifiable Execution: From Plugins to Policy **Summary of Topic:** Security posture expanded with new capabilities (GoPlus security, remote attestation actions, TEE attestation plugins), while security vulnerabilities and scam risks remain active—requiring Council decisions on enforcement, defaults, and trust signaling. #### Deliberation Items (Questions): **Question 1:** Should security and verifiability features (TEE attestation, security plugins) become a first-class 'recommended baseline' for Cloud and flagship agents? **Context:** - `GitHub Daily Summary (Jan 5): "Added GoPlus Security Plugin" (PR #1898).` - `GitHub Daily Summary (Jan 5): "Added Marlin TEE remote attestations plugin" (PR #935) and "Added remote attestation action" (PR #1885).` **Multiple Choice Answers:** a) Yes—baseline security profile for Cloud + flagship agents, opt-out for advanced users. *Implication:* Improves trust and safety at the cost of complexity and potential performance overhead. b) No—keep as optional plugins and focus on documentation + examples. *Implication:* Maintains simplicity but misses a chance to differentiate via verifiable agent operation. c) Hybrid—baseline in Cloud only; OSS remains modular and opt-in. *Implication:* Strengthens managed offering while preserving OSS composability, but may create a two-tier perception. d) Other / More discussion needed / None of the above. **Question 2:** How strict should we be about security review and provenance for new plugins landing in core (vs. registry)? **Context:** - `GitHub Issues (Jan 5): "code analysis report highlighting security vulnerabilities" (#1862).` - `GitHub Daily Summary (Jan 5): Multiple new plugins merged (e.g., Binance, Hyperfy, zktls-reclaim, OpenWeather).` **Multiple Choice Answers:** a) Strict: require security checklist + minimal threat model + maintainer approval for core inclusion. *Implication:* Reduces risk and strengthens trust, but slows plugin velocity and increases maintainer workload. b) Moderate: allow merges with automated scanning + post-merge audit and rapid rollback policy. *Implication:* Preserves momentum while adding guardrails, but may still allow high-impact vulnerabilities through. c) Loose: keep current approach and rely on community review and issue reporting. *Implication:* Maximizes ecosystem growth but increases the likelihood of security incidents. d) Other / More discussion needed / None of the above. **Question 3:** Do we treat anti-scam operations as an agent capability roadmap item (data capture, classification, moderation), or as a community policy/process function? **Context:** - `Discord 🥇-partners (2025-01-05): "Implement a system to indefinitely mute scammers for 24 hours before banning to preserve data for machine learning" (jin).` - `Discord tokenomics (2025-01-05): calls for an "Eliza scribe agent" and better verified info channels.` **Multiple Choice Answers:** a) Agent capability: build moderation + scam-intel as a first-class plugin suite with ML feedback loops. *Implication:* Creates differentiated value and safer community operations, but introduces liability and governance questions. b) Policy/process: implement human-led procedures and minimal tooling only. *Implication:* Lower technical risk, but slower response and weaker long-term learning pipeline. c) Hybrid: ship minimal tooling now, formalize agent-driven intelligence after governance and safeguards. *Implication:* Balances safety and speed while building toward autonomous ops without overcommitting prematurely. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Trust Through Documentation & Signal Clarity **Summary of Topic:** Documentation and DX improved through fixes, translations, and devcontainer support, but recurring community questions (DegenAI roadmap, tokenomics clarity, knowledge ingestion) indicate an information-diffusion failure that threatens perceived reliability. #### Deliberation Items (Questions): **Question 1:** Do we prioritize a "single source of truth" status system (dashboard + roadmap + known issues) over additional feature announcements to reduce repeated questions and uncertainty? **Context:** - `Discord spartan_holders (2025-01-05): repeated requests for "updates on DegenAI progress and roadmap information"; "week of DegenAI starts today" (jin).` - `Discord tokenomics (2025-01-05): "Develop a simple status dashboard showing features, status, dates, and owners" (PrudentSpartan).` **Multiple Choice Answers:** a) Yes—ship a lightweight status dashboard with owners/dates and pin it across Discord/GitHub. *Implication:* Reduces support burden and increases trust through transparency, with minimal engineering effort. b) Partial—publish weekly roundups only; no dashboard until Cloud launch is complete. *Implication:* Improves comms somewhat but may not solve real-time confusion and repeated questions. c) No—keep communications informal; prioritize shipping and let community synthesize info. *Implication:* Maximizes builder time but increases rumor cycles and harms credibility with new developers. d) Other / More discussion needed / None of the above. **Question 2:** How should we operationalize 'Taming Information'—human editorial process, an Eliza scribe agent, or a hybrid ETL pipeline? **Context:** - `Discord tokenomics (2025-01-05): "Create an Eliza scribe agent to improve documentation processes" (jin).` - `Discord tokenomics (2025-01-05): "Set up a basic ETL pipeline for documentation management" (yikesawjeez).` **Multiple Choice Answers:** a) Human-led editorial first, then automate with agents once formats stabilize. *Implication:* Higher accuracy early, slower scaling; risks backlog growth as community expands. b) Agent-first: deploy a scribe agent now to draft docs and triage questions automatically. *Implication:* Scales fast and demonstrates agent utility, but risks hallucinated or inconsistent documentation. c) Hybrid: ETL pipeline + scribe agent with human review gates for publishing. *Implication:* Best alignment with reliability and scale, requiring modest process design and tooling integration. d) Other / More discussion needed / None of the above. **Question 3:** Do we change how knowledge ingestion works (folder-based knowledge, URL crawling) as a near-term DX priority, even if it delays other roadmap items? **Context:** - `Discord (2025-01-05): "Soon knowledge will be a folder" (jin) and requests for URL crawling for knowledge base (hammerzon).` - `Discord (2025-01-05): Interest in "URL crawling" and "knowledge base construction" for character JSON.` **Multiple Choice Answers:** a) Yes—prioritize folder-based knowledge + URL crawling as core DX and trust-building features. *Implication:* Improves onboarding and reduces friction, but may divert focus from token migration/Cloud milestones. b) Incremental—ship folder-based knowledge now; defer URL crawling to a plugin later. *Implication:* Delivers structure quickly while preserving modularity, but leaves a key user request partially unmet. c) Defer—keep current approach and focus on deployment stability and Cloud launch first. *Implication:* Stabilizes the platform foundation, but risks continued confusion and support load around knowledge setup. d) Other / More discussion needed / None of the above.