# Council Briefing: 2025-01-19 ## 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 - GitHub velocity remains high with meaningful quality work (tests/docs/providers), but field reliability pain (Twitter auth and DB adapters) and brand/value-accrual confusion threaten developer trust if not triaged above new feature throughput. ## Key Points for Deliberation ### 1. Topic: Reliability Triage: Twitter + Database Adapters **Summary of Topic:** Operational logs show recurring user-blocking failures in the Twitter client (ArkoseLogin/auth/rate limits) and database adapters (Supabase schema/connection errors). These issues directly conflict with the "Execution Excellence" directive and are now the loudest trust risk in public channels. #### Deliberation Items (Questions): **Question 1:** Do we declare a short-term reliability freeze (Twitter + DB) that temporarily deprioritizes new plugins/features until the top failure modes are eliminated? **Context:** - `Discord 2025-01-18 đŸ’»-coders: multiple users reported Twitter login failures: "Unknown subtask ArkoseLogin" (erickdemoura; tony suggested using a stable version tag).` - `Discord 2025-01-18 đŸ’»-coders: database errors reported: "relation 'public.accounts' does not exist" and "The database connection is not open" (Killian; gusjipe).` **Multiple Choice Answers:** a) Yes—enact a 7–14 day reliability freeze focused on Twitter client auth/rate limits and Supabase/DB initialization and error handling. *Implication:* Improves developer trust and reduces support load, but slows ecosystem feature expansion temporarily. b) Partial—freeze only core runtime + official clients (Twitter/Discord/Telegram) while allowing new plugins to land behind experimental flags. *Implication:* Balances momentum with quality, but requires strict enforcement and clear “official vs experimental” labeling. c) No—continue feature throughput and address reliability opportunistically via community fixes and docs workarounds. *Implication:* Maintains velocity, but risks compounding churn and reputational damage as builders hit recurring blockers. d) Other / More discussion needed / None of the above. **Question 2:** What is our canonical “supported persistence stack” for the next release window (SQLite, Postgres, Supabase), and how do we enforce it in docs and CI? **Context:** - `Discord 2025-01-17/18: repeated debates and troubleshooting around SQLite vs PostgreSQL/Supabase, with Supabase schema errors and connection-state failures.` - `Daily Dev Updates 2025-01-18: tests added for Supabase and SQLite DB adapters (PR #2468), indicating growing surface area but also a need to define support tiers.` **Multiple Choice Answers:** a) Standardize on SQLite (local) + Postgres (server) as “supported,” and treat Supabase as a documented reference deployment of Postgres with a validated schema tool. *Implication:* Clarifies DX and reduces ambiguity while still allowing Supabase as a path, but requires strong schema tooling and docs. b) Make Supabase the default cloud persistence recommendation and invest in first-run migrations, schema validation, and clearer errors. *Implication:* Aligns with managed-cloud onboarding, but increases dependency on Supabase-specific quirks and schema lifecycle. c) Support all three equally and rely on expanded adapter test coverage to keep parity. *Implication:* Maximizes choice, but likely dilutes reliability unless staffing and CI rigor scale proportionally. d) Other / More discussion needed / None of the above. **Question 3:** Should we introduce a "known-good" version channel (LTS tags + compatibility matrix) for clients like Twitter to reduce breakage from main/develop churn? **Context:** - `Discord 2025-01-18: workaround for Twitter auth issues was to "use a stable version tag instead of the main branch" (tony).` - `GitHub issues list: Twitter behavior bugs and client regressions appear repeatedly (e.g., agent replying logic, Twitter Spaces interaction issues).` **Multiple Choice Answers:** a) Yes—publish LTS tags for framework + key clients, and document a compatibility matrix in docs. *Implication:* Greatly improves builder confidence and reduces support burden, at the cost of release management overhead. b) Yes, but only for clients (Twitter/Discord/Telegram) while framework remains rapid-release. *Implication:* Protects the highest-friction integrations while preserving core iteration speed, but adds cross-repo coordination complexity. c) No—encourage builders to pin versions themselves and keep official guidance minimal to avoid maintenance commitments. *Implication:* Keeps internal overhead low, but shifts reliability costs to developers and undermines “developer-friendly” positioning. d) Other / More discussion needed / None of the above. --- ### 2. Topic: V2 + Launchpad Readiness vs. Messaging Debt **Summary of Topic:** Leadership reports V2 is progressing and a launchpad is expected within weeks, with revenue share intended to buy back the token; however, community confusion around naming (ai16z/ElizaOS/Eliza) and value accrual is actively depressing confidence and price perception. #### Deliberation Items (Questions): **Question 1:** Should the Council mandate a single canonical brand architecture (names, product lines, token references) before launchpad/V2 announcements proceed? **Context:** - `Discord 2025-01-18 đŸ„‡-partners: "need for better branding consistency" due to multiple names (ai16z, ElizaOS, Eliza).` - `Discord 2025-01-17: transition from "ai16z" branding to "ElizaOS" with a clearer focus on an AI agent framework.` **Multiple Choice Answers:** a) Yes—freeze outward-facing announcements until a single naming schema, token naming guidance, and product map are approved and published. *Implication:* Reduces confusion and sets a clean narrative, but may delay momentum and partner activations. b) Partial—publish a migration guide immediately, but allow V2/launchpad progress to continue in parallel. *Implication:* Maintains speed while reducing confusion, but risks mixed messaging if the guide isn’t enforced consistently. c) No—accept naming fluidity as organic growth; focus on shipping and let the market adapt. *Implication:* Maximizes short-term velocity, but confusion may persist and erode trust precisely during launch windows. d) Other / More discussion needed / None of the above. **Question 2:** What is the minimum credible "value accrual" narrative we commit to, and in what format must it ship (doc + slides + video + FAQ) to restore trust? **Context:** - `Discord 2025-01-18 đŸ„‡-partners: Shaw: price drops were because "we don't have clear messaging around value accrual".` - `Discord 2025-01-17: Shaw: "Revenue share from launchpad/marketplace... with proceeds used to buy ai16z"; Jin working on tokenomics docs and phases.` **Multiple Choice Answers:** a) Publish a single "Value Accrual One-Pager" plus an executable roadmap (phases, timelines, and what is live vs planned), with weekly updates. *Implication:* Sets clear expectations and reduces rumor-driven volatility, but commits the org to ongoing public accountability. b) Ship an educational media package (slides + video) first, then formalize docs after partner feedback. *Implication:* Fast narrative correction, but risks inconsistencies if docs lag or differ from the media framing. c) Defer specifics until launchpad revenue share is contractually finalized; communicate only general principles. *Implication:* Avoids overpromising, but prolongs uncertainty and may continue to suppress developer and market confidence. d) Other / More discussion needed / None of the above. **Question 3:** Do we prioritize shipping the launchpad as a standalone revenue engine even if core framework stability issues remain unresolved? **Context:** - `Discord 2025-01-18: Shaw: launchpad project expected "in the next couple of weeks"; delayed by team issues now resolved.` - `Discord 2025-01-18: recurrent developer pain points (Twitter auth, DB adapters) continue to surface in support channels.` **Multiple Choice Answers:** a) Yes—launchpad timing is strategic; ship it, then fund reliability work from proceeds. *Implication:* Accelerates financial flywheel but risks reputational damage if builders associate launches with instability. b) Gate the launchpad on a defined stability bar (top 5 issues fixed, LTS tag, and minimum docs complete). *Implication:* Aligns with “Execution Excellence,” though it may delay revenue and partner schedules. c) Split the difference—soft launch to partners only while stabilizing core issues before public expansion. *Implication:* Reduces blast radius and gathers real data, but requires operational discipline and clear access boundaries. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Ecosystem Expansion vs. Coherence: Plugin Proliferation and Support Burden **Summary of Topic:** Development activity is extremely high (dozens of PRs/day, hundreds of contributors/month), adding new providers (NVIDIA, OpenAI plugin) and wide Web3 coverage; without tighter curation and “golden path” documentation, plugin volume risks lowering perceived reliability and increasing integration confusion. #### Deliberation Items (Questions): **Question 1:** Should ElizaOS establish an "Official/Certified Plugin" program with stricter requirements (tests, docs, CI, maintenance SLAs) and demote everything else to "community"? **Context:** - `Daily Report 2025-01-18: new capabilities landed across Telegram multimedia, NVIDIA inference, OpenAI text generation, plus expanded chain support.` - `Discord 2025-01-18 đŸ’»-coders: repeated confusion about plugin activation and multi-plugin usage in character files.` **Multiple Choice Answers:** a) Yes—create a two-tier registry (Certified vs Community) with explicit requirements and a review board cadence. *Implication:* Raises trust and reduces support debt, but may slow contributions and require governance overhead. b) Yes, but keep it lightweight—automated checks (Biome, tests, docs lint) define “certified,” with minimal human review. *Implication:* Scales better with contributor volume, but automated gates may miss security/reliability concerns. c) No—keep a flat ecosystem; rely on user choice and community reputation to surface quality. *Implication:* Maximizes openness, but makes the developer experience noisier and increases the risk of brittle integrations. d) Other / More discussion needed / None of the above. **Question 2:** What is our ‘golden path’ developer journey for multi-agent + multi-plugin deployments, and who owns keeping it current? **Context:** - `Discord 2025-01-18: frequent questions: "How do I add plugins to my character file?" and "Can we use 2 plugins simultaneously?" (some unanswered).` - `Daily Report 2025-01-18: "Support for loading multiple characters from remote URLs" (PR #2475) increases multi-agent use cases but also raises configuration complexity.` **Multiple Choice Answers:** a) Define a single official tutorial track (Local → Cloud → Multi-agent → Cross-chain) owned by a docs squad with weekly refresh cycles. *Implication:* Improves DX and lowers churn, but requires sustained resourcing and release coordination. b) Provide reference templates and starter repos per major path (Twitter bot, Discord bot, Trading agent, RAG assistant) and accept docs drift. *Implication:* Helps quickly, but risks fragmentation and outdated guidance as the framework evolves. c) Let community creators lead; the core team only maintains API docs and minimal examples. *Implication:* Low internal cost, but weakens the “developer-friendly” promise and increases onboarding friction. d) Other / More discussion needed / None of the above. **Question 3:** Given the surge in new model providers and tooling (e.g., NVIDIA inference, OpenAI plugin, DI), do we optimize for breadth or for operationally consistent defaults (Cloud-first, stable tags, opinionated configs)? **Context:** - `Daily Dev Update 2025-01-19: added support for NVIDIA inference (#2512) and OpenAI integration via plugin-openai (#2463), plus architectural improvements (Dependency Injection #2115).` - `Discord 2025-01-18: builders advised to use stable version tags for reliability (tony), signaling a desire for consistent defaults.` **Multiple Choice Answers:** a) Optimize for consistent defaults—opinionated Cloud-first configuration and a small set of validated providers for the mainline experience. *Implication:* Strengthens reliability and onboarding, but may frustrate power users who want maximal provider flexibility. b) Maintain breadth—continue adding providers rapidly, but improve abstractions (DI, templates) to keep integration coherent. *Implication:* Preserves ecosystem expansion while reducing chaos, but coherence work must keep pace with additions. c) Hybrid—defaults stay narrow, but breadth lives behind clear "experimental" flags and separate documentation sections. *Implication:* Reduces confusion while enabling innovation, but requires disciplined labeling and tooling support. d) Other / More discussion needed / None of the above.