# Council Briefing: 2025-01-09 ## 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 - A major client overhaul and rapid plugin expansion are shipping in parallel with a growing tail of stability issues (GPU/runtime errors, client integrations), creating an urgent need to rebalance “more capabilities” toward “more reliable defaults.” ## Key Points for Deliberation ### 1. Topic: Stability vs. Velocity in Core + Client Overhaul **Summary of Topic:** The new client overhaul and broad feature throughput are strong signals of momentum, but recurring runtime failures (CUDA/llama_local, plugin regressions, inconsistent Twitter behavior) risk undermining developer trust unless a quality gate and “golden path” are enforced. #### Deliberation Items (Questions): **Question 1:** Do we temporarily slow new plugin merges to establish a reliability gate (tests, CI, compatibility matrix) for the core runtime + flagship clients? **Context:** - `GitHub summary: “Complete overhaul of the client application” (PR #2038).` - `GitHub issues: “CUDA error when using 'llama_local'” (issue #2080); “CUDA not being detected… transcription runs on CPU” (issue #1994).` **Multiple Choice Answers:** a) Yes—enforce a reliability gate immediately (CI + smoke tests for core, Twitter, Telegram, Discord, and top providers). *Implication:* Short-term velocity drops, but reduces public-facing breakage and increases builder confidence. b) Partial—keep merges flowing, but quarantine new plugins behind “experimental” tags and require minimal test coverage. *Implication:* Maintains ecosystem momentum while narrowing blast radius from unstable additions. c) No—optimize for breadth now; let community triage instability via issues and rapid patching. *Implication:* Maximizes feature surface area, but risks reputational damage and contributor burnout from constant firefighting. d) Other / More discussion needed / None of the above. **Question 2:** Which runtime failures deserve “red alert” prioritization as the canonical developer experience blockers? **Context:** - `GitHub issues: “WhatsApp plugin… cannot read properties of undefined (reading 'actions')” (issue #2078).` - `Discord (2025-01-07/08): frequent Twitter login, JSON formatting, rate limit, and shadowban discussions; PR #1974 created to fix Twitter scraper/login attempts.` **Multiple Choice Answers:** a) GPU/local inference failures (CUDA/llama_local) and embedding/vector DB errors—block local self-hosting credibility. *Implication:* Strengthens the “runs anywhere” promise and reduces support load for serious builders. b) Social client reliability (Twitter/Telegram/Discord) because these are the flagship onramps and most visible failures. *Implication:* Protects public brand and reduces churn among new users trying to deploy social agents. c) Plugin API consistency and regression-proofing (e.g., WhatsApp undefined actions) to stabilize the long tail ecosystem. *Implication:* Improves composability, but may delay addressing the most common user-facing breakpoints. d) Other / More discussion needed / None of the above. **Question 3:** What should be designated as the “Golden Path” reference stack for builders (the default opinionated setup we guarantee)? **Context:** - `Discord (2025-01-08): debates about minimum viable specs (2GB vs 4GB RAM) and deployment strategies (VPS/AWS/Docker).` - `GitHub updates: “Local Embedding Manager… fixing high RAM issues” (PR #1950).` **Multiple Choice Answers:** a) Cloud-first Golden Path (ElizaOS Cloud + managed storage + curated providers), with local as best-effort. *Implication:* Optimizes reliability and supportability but may alienate self-host purists. b) Local-first Golden Path (Docker + SQLite/Postgres + one recommended local model), with cloud as optional acceleration. *Implication:* Maximizes open-source autonomy, but raises the bar for stability guarantees across varied hardware. c) Dual-path: officially supported “Local Lite” and “Cloud Pro,” each with explicit constraints and compatibility matrix. *Implication:* Clarifies expectations and reduces confusion, at the cost of maintaining two tested tracks. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Knowledge System & Documentation as Operational Infrastructure **Summary of Topic:** The new Knowledge system (multi-agent RAG), Obsidian integration, and doc improvements directly advance the “Taming Information” mandate, but the Council must ensure these capabilities are delivered as a coherent, beginner-friendly workflow rather than scattered primitives. #### Deliberation Items (Questions): **Question 1:** Should the Knowledge system become a first-class default (enabled by default in starter agents), or remain opt-in until its UX and migration story are stable? **Context:** - `GitHub updates: “Implemented a separate Knowledge system with Multi-Agent RAG Optimization (PR #1620).”` - `GitHub updates: “Added methods… getKnowledge, searchKnowledge, createKnowledge… (PR #2005).”` **Multiple Choice Answers:** a) Enable by default for all new agents and treat it as a core pillar of ElizaOS. *Implication:* Accelerates adoption and capability, but increases risk of confusing failures for beginners. b) Keep opt-in; ship a guided onboarding and a migration wizard before defaulting it on. *Implication:* Protects execution excellence while building a smoother path to broader adoption. c) Hybrid: default on only in curated “reference agents” (Eli5/Otaku), opt-in for general users. *Implication:* Provides working exemplars without forcing complexity on every new builder. d) Other / More discussion needed / None of the above. **Question 2:** How should we standardize knowledge ingestion to avoid fragmentation across Obsidian, GitBook, Discord logs, and ad-hoc character.json knowledge blocks? **Context:** - `GitHub updates: “Introduced Obsidian integration plugin for improved knowledge management (PR #1943).”` - `Discord (2025-01-08): user question about alternatives to character.json knowledge text section for larger datasets (unanswered in coders channel).` **Multiple Choice Answers:** a) Define a single canonical “Knowledge Source” spec (folders/URLs/connectors) and make all integrations conform to it. *Implication:* Improves composability and reduces duplicated tooling, but requires coordination across plugin authors. b) Support multiple ingestion paths but publish an official “recommended stack” with templates and examples. *Implication:* Balances flexibility with guidance; risk remains that third-party patterns diverge over time. c) Keep it decentralized; let the ecosystem evolve organically and curate later. *Implication:* Maximizes experimentation now, but increases long-term documentation and support complexity. d) Other / More discussion needed / None of the above. **Question 3:** Do we operationalize a “Scribe Agent” pipeline that converts Discord/GitHub/X activity into issues, digests, and docs as a core governance function? **Context:** - `Discord (2025-01-08): action item “Develop a bot that can take intent from Discord and generate GitHub issues” (jin).` - `Discord (2025-01-08): action item “Create an automated daily digest from X, Discord, and GitHub” (jin).` **Multiple Choice Answers:** a) Yes—make it a top-level initiative with a single owner and weekly output targets (issues triaged, docs updated, digest shipped). *Implication:* Directly supports “Trust Through Shipping” by turning conversation into execution artifacts. b) Pilot it as an optional community-run tool first; only formalize after proving accuracy and low hallucination risk. *Implication:* Reduces governance risk, but may delay benefits to developer experience and transparency. c) No—keep this manual to avoid automation errors and reputational risk. *Implication:* Avoids agent mistakes, but sustains high coordination overhead and slows knowledge consolidation. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Ecosystem Alignment: Tribute Model, Partnerships, and Multichain Token Direction **Summary of Topic:** The community is coalescing around a tribute-based alignment mechanism and aggressive partnership expansion (Roblox, Arbitrum, Hyperfy), but governance clarity, wallet verification reliability, and an explicit multichain token strategy are now prerequisites for credibility. #### Deliberation Items (Questions): **Question 1:** Should the tribute model be codified into a standard agreement and on-chain enforcement primitives, or remain a social norm? **Context:** - `Discord (partners, 2025-01-08): “Projects using Eliza tech should send 5-10% of their tokens to the DAO as a form of alignment” (jin).` - `Discord (2025-01-08): “Roblox integration… with 10% tribute paid to the DAO” (StealthSDK announcement).` **Multiple Choice Answers:** a) Codify it: publish a standard deal + lightweight on-chain attestations for “Eliza-aligned” projects. *Implication:* Strengthens legitimacy and reduces ambiguity, but raises coordination and legal/compliance complexity. b) Keep it social: maintain norms, publish best practices, and spotlight compliant partners on the website. *Implication:* Moves fast and stays flexible, but may allow free-riders and create ecosystem resentment. c) Hybrid: social norm now, with a future migration path to optional on-chain enforcement for major partners. *Implication:* Balances momentum with a credible roadmap toward stronger alignment guarantees. d) Other / More discussion needed / None of the above. **Question 2:** What is our near-term multichain token strategy to prevent liquidity fragmentation while still enabling cross-chain agent economies? **Context:** - `Discord (tokenomics, 2025-01-08): “Explore Hyperlane integration for multi-chain token deployment” (wit).` - `Discord (tokenomics, 2025-01-08): “Develop canonical bridged token to Ethereum or Base for adoption” (wit).` **Multiple Choice Answers:** a) Canonical bridge first (Ethereum/Base), treat other chains as satellites with unified liquidity routing. *Implication:* Minimizes fragmentation and simplifies messaging, but delays true omnichain reach. b) Go omnichain via Hyperlane/LayerZero now, accept fragmentation and solve with market-making and routing later. *Implication:* Maximizes expansion speed, but increases operational complexity and risk of price inconsistencies. c) Defer multichain token moves; prioritize framework/cloud reliability and revisit after execution excellence milestones. *Implication:* Protects focus and trust, but may miss strategic windows for ecosystem distribution. d) Other / More discussion needed / None of the above. **Question 3:** How should leadership and public communication be structured to reduce reputational risk while preserving founder authenticity? **Context:** - `Discord (partners, 2025-01-08): partner concerns about founder engagement with memecoins and public perception.` - `Discord (overall, 2025-01-08): “Requests for better transparency about partnerships and development roadmaps.”` **Multiple Choice Answers:** a) Create an official comms protocol: a single source of truth for partnerships/roadmaps and clear separation between personal and project accounts. *Implication:* Reduces narrative volatility and increases trust, but constrains informal community energy. b) Maintain current informal comms, but add rapid-response clarification posts and an always-updated partnerships page. *Implication:* Preserves agility, but continues exposure to recurring confusion and reputational flare-ups. c) Delegate outward comms to a council-elected spokesperson while founders focus on shipping and internal coordination. *Implication:* Professionalizes external messaging, but may introduce bureaucracy and dilute founder voice. d) Other / More discussion needed / None of the above.