# Council Briefing: 2025-01-23 ## 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 project showed high throughput shipping (new plugins and rapid merges) while reliability debt surfaced as the main strategic risk—core client stability, installation friction, and documentation gaps now threaten developer trust more than missing features. ## Key Points for Deliberation ### 1. Topic: Execution Excellence vs. Expansion: Stabilization Gate for Core + Plugins **Summary of Topic:** Development velocity is strong (new plugins, fixes, and high merge rates), but recurring breakages in Twitter, Docker/Windows, embeddings, and plugin bootstrapping are generating support load and eroding the "reliable framework" promise; Council must decide where to place a stabilization gate to protect DX while continuing ecosystem expansion. #### Deliberation Items (Questions): **Question 1:** Do we impose a temporary stabilization gate (limited merges + stricter CI/docs requirements) for core clients and installation paths before accepting additional new plugins? **Context:** - `GitHub summary (Jan 22-23): "37 new PRs (12 merged)..." then "28 new PRs (24 merged)" indicating high merge velocity.` - `Discord coders (Jan 22): recurring issues with "bootstrap, node, solana, and dexscreener plugins" plus Docker/Windows workarounds.` **Multiple Choice Answers:** a) Yes—freeze non-critical feature merges for 1–2 weeks; prioritize install/boot, core clients, and top-5 community pain points. *Implication:* Short-term feature slowdown buys long-term trust and reduces support drag, aligning with Execution Excellence. b) Partial gate—allow new plugins only if they meet a higher bar (README + tests + lint + compatibility checklist), while core fixes proceed normally. *Implication:* Maintains ecosystem momentum while raising the quality floor and making expansion composable instead of chaotic. c) No gate—keep shipping broadly and rely on community triage; optimize merge throughput as the primary strategy. *Implication:* Maximizes growth optics but risks compounding reliability debt and undermining the "developer-friendly" promise. d) Other / More discussion needed / None of the above. **Question 2:** Which reliability front should be treated as the Council’s immediate "red alert" because it blocks adoption most directly? **Context:** - `Discord coders (Jan 22): "Vector dimension mismatch" when switching embedding models; workaround: delete db.sqlite.` - `Daily update (Jan 23): "bug in the Twitter client related to fetching tweets, which needs urgent attention (#2700)."` **Multiple Choice Answers:** a) Install/boot & environment consistency (Docker, Windows/WSL, dependency errors) as the primary blocker. *Implication:* Improving first-run success increases conversion from curious builders to retained builders. b) Social clients reliability (Twitter/Telegram/Discord) because these are flagship-facing and highly visible. *Implication:* Prevents public failures and brand damage, reinforcing “trust through shipping” externally. c) Data/memory correctness (embedding model switching, vector dimensions, caching duplication) because it corrupts agent behavior. *Implication:* Protects long-lived agents and prevents subtle failures that are expensive to debug and fix later. d) Other / More discussion needed / None of the above. **Question 3:** Should we formalize a "supported matrix" (OS + DB adapters + model providers + clients) to reduce support chaos, even if it constrains flexibility? **Context:** - `Discord (Jan 22): Windows users advised to use WSL2; repeated Docker build failures and environment-specific errors.` - `GitHub issues list (Jan 22): installation and dependency issues (e.g., "Error installing @discordjs/opus...", "workspace dependency reference" issue).` **Multiple Choice Answers:** a) Yes—publish an explicit support matrix and treat everything else as "best effort" community support. *Implication:* Sets clear expectations and focuses engineering on predictable reliability targets. b) Hybrid—define a supported matrix, but keep "experimental" lanes with clear warnings and telemetry-driven promotion to supported. *Implication:* Balances innovation with clarity, creating a path for new providers/clients to mature. c) No—keep all combinations unofficially supported to preserve openness and maximal composability. *Implication:* Avoids perceived restriction but increases ongoing support cost and inconsistent user experience. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Persistent Identity: Cross-Client Memory and Personality Continuity **Summary of Topic:** The system is approaching a multi-surface reality (Discord/Twitter/Telegram and multiple agent instances), but memory is not consistently shared—risking fragmented personalities and unreliable autonomy; Council must choose an architectural stance for memory portability and correctness. #### Deliberation Items (Questions): **Question 1:** What should be the canonical strategy for "passing around memories" across agent instances and clients to maintain consistent identity? **Context:** - `Partners channel (Jan 22): jin: "passing around memories" between different agent instances will be important for maintaining consistent agent personalities.` - `Daily update (Jan 23): new issue on "duplicate API calls in the memory cache" affecting performance (#2688).` **Multiple Choice Answers:** a) Centralized memory service (Cloud-first): one canonical store per agent identity, clients become stateless front-ends. *Implication:* Strong consistency and easier debugging, but increases reliance on Cloud and raises trust/availability requirements. b) Federated sync: local-first stores with periodic reconciliation (CRDT/event-log style) across surfaces. *Implication:* Resilient and decentralized, but more complex and risks emergent inconsistency without strong tooling. c) Keep memory per-instance for now; focus on better prompts and clearer user expectations rather than sync. *Implication:* Fastest to ship, but undermines the promise of persistent agents and makes autonomy brittle at scale. d) Other / More discussion needed / None of the above. **Question 2:** Should embedding model changes be treated as a breaking change that forces automatic data migration/versioning rather than manual DB deletion? **Context:** - `Coders channel (Jan 22): Yoda26: switching embedding models causes "Vector dimension mismatch"; fix: `rm -f ./agent/data/db.sqlite`.` **Multiple Choice Answers:** a) Yes—implement embedding-dimension versioning and an automated migration/reset flow with explicit prompts to the operator. *Implication:* Reduces foot-guns and support burden; improves professional DX for production deployments. b) Partial—detect mismatch and auto-disable vector features (RAG) until the operator explicitly rebuilds the index. *Implication:* Avoids destructive actions while keeping core agent usable; preserves operator control. c) No—keep it manual and document the reset steps clearly as the expected workflow. *Implication:* Lowest engineering cost now, but increases long-term churn from repeated “mysterious breakage” experiences. d) Other / More discussion needed / None of the above. **Question 3:** What is the Council’s minimum definition of "persistent agent" required to claim execution excellence publicly? **Context:** - `Meeting context (Core Principles): "Execution Excellence" and "Trust Through Shipping" imply reliability and clear UX.` - `Discord (Jan 22): multiple reports of client/plugin issues; users asking for better deployment and DB adapter documentation.` **Multiple Choice Answers:** a) Persistence = stable long-term memory across restarts + consistent identity across at least two clients (e.g., Discord + Twitter). *Implication:* Sets a high bar aligned with the North Star; may delay claims until architecture is ready. b) Persistence = durable memory across restarts in a single deployment surface, with multi-client sync marked as "coming soon". *Implication:* Allows nearer-term messaging while being honest about current limitations. c) Persistence = best-effort memory with clear disclaimers; prioritize feature breadth and integrations. *Implication:* Maximizes surface area but risks reputational mismatch with the "most reliable" positioning. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Flagship Trust Surface: DegenAI Transparency, Tokenomics Credibility, and Platform Policy Risk **Summary of Topic:** DegenAI’s early performance is a strong proof signal, but public-wallet transparency may invite copy-trading/counter-trading; tokenomics work is in tension between fast simplicity and sophisticated trust mechanisms; and Telegram’s TOS shift is a looming operational threat to a major client surface. #### Deliberation Items (Questions): **Question 1:** How should we balance transparency and strategic edge for DegenAI given concerns about copy-trading and counter-strategies? **Context:** - `Spartan holders (Jan 22): debate over a public wallet and strategy dilution; team considering "multiple wallets" (jin, M3xR).` - `Partners (Jan 22): DegenAI portfolio grew from "$2,600 to $6,000 over 4 days".` **Multiple Choice Answers:** a) Keep a single public wallet for maximal transparency; accept that edge erosion is the cost of credibility. *Implication:* Strengthens community trust but may reduce performance over time and create public drawdown optics. b) Adopt a dual-structure: one public "audited" wallet for visibility plus separate execution wallets for strategy protection. *Implication:* Balances trust and performance, but requires careful messaging to avoid accusations of deception. c) Make execution private; publish delayed reports (e.g., T+24h) and risk metrics instead of live wallet transparency. *Implication:* Preserves edge but increases the burden of proving honesty and may reduce community confidence. d) Other / More discussion needed / None of the above. **Question 2:** For tokenomics, do we ship a simple draft quickly or wait for a more sophisticated trust/staking design (e.g., PoS/restaking) to avoid future reworks and reputational damage? **Context:** - `Tokenomics channel (Jan 22): tension between "release a simple draft quickly" vs "more sophisticated approach"; Yardy introduced token engineer Vasily Sumanov and a detailed doc.` - `Tokenomics channel (Jan 22): unreadyplayer: "77.5% traded on the curve" and "22.5% goes to locked LP"; suggestion to leverage "Jito's restaking platform".` **Multiple Choice Answers:** a) Ship a minimal draft immediately (bonding curve + LP lock basics) and iterate publicly with community feedback. *Implication:* Accelerates coordination and reduces rumor vacuum, but may entrench early assumptions and invite backlash if revised. b) Ship a two-layer release: a short 2–3 page explainer now plus a parallel deep technical paper for audit-grade design. *Implication:* Balances speed and rigor; improves communication without prematurely locking mechanism details. c) Wait until the full sophisticated design (including staking/restaking trust mechanics) is coherent and testable. *Implication:* Reduces redesign risk but prolongs uncertainty and may weaken near-term ecosystem momentum. d) Other / More discussion needed / None of the above. **Question 3:** How should we respond to Telegram’s updated TOS restricting third-party blockchains (non-TON) before Feb 21 enforcement? **Context:** - `Discord (Jan 22): kirsten warned Telegram TOS will restrict third-party blockchains aside from TON; enforcement begins "February 21st".` **Multiple Choice Answers:** a) Prioritize compliance: refactor Telegram integrations to minimize/abstract non-TON blockchain actions or disable them by default. *Implication:* Protects continuity of Telegram presence but may reduce Web3 functionality on that surface. b) Segment offerings: maintain a TON-compliant Telegram mode, and route cross-chain features to other clients (Discord/Web) and Cloud APIs. *Implication:* Preserves capability breadth while reducing platform risk; requires clear product messaging. c) Deprioritize Telegram: invest engineering in more permissive surfaces and accept potential Telegram degradation or exit. *Implication:* Avoids compliance churn but risks losing a major distribution channel and community touchpoint. d) Other / More discussion needed / None of the above.