# Council Briefing: 2025-01-16 ## 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 fleet’s critical thrust shifted toward execution excellence via a surge in test coverage and stability fixes, while field reports continued to flag onboarding friction (Docker/ARM64, RAG confusion, and client auth failures) that threatens developer trust. ## Key Points for Deliberation ### 1. Topic: Reliability Drive: Tests, Stability Fixes, and Release Discipline **Summary of Topic:** Engineering output shows a deliberate pivot toward reliability (new tests for GitHub/Slack/Solana, crash fixes around REMOTE_CHARACTER_URLS, Docker/compose stabilization), aligning with our North Star of trust-through-shipping. The Council must now decide how to harden this into a repeatable release discipline that scales with contributor volume. #### Deliberation Items (Questions): **Question 1:** What reliability bar should gate merges/releases while contributor throughput remains high? **Context:** - `GitHub activity update: "46 new pull requests (33 merged)... 83 active contributors" (Jan 16-17 vs Jan 15-16).` - `Daily Update (Jan 16, 2025): "Added tests for the GitHub client" (#2407), "tests for the Slack client" (#2404), "tests for the Solana plugin" (#2345).` **Multiple Choice Answers:** a) Strict gate: required tests + smoke suite must pass for every PR touching core/runtime/clients. *Implication:* Slows merges but converts velocity into dependable releases and reduced support load. b) Tiered gate: strict for core/runtime/deployment, lighter for plugins/docs with automated rollback/revert paths. *Implication:* Preserves ecosystem speed while protecting the reliability surface area that defines user trust. c) Minimal gate: prioritize shipping; rely on community bug reports and quick patch releases. *Implication:* Maximizes short-term feature velocity but risks reputational damage and support saturation. d) Other / More discussion needed / None of the above. **Question 2:** Where should we concentrate near-term stability work to best support ElizaOS Cloud and production deployments? **Context:** - `Issues list: "Bug when running in cloud from docker image" (#2343), "Startup failures on macOS" (#2360), "Low performance under parallel requests" (#2311).` - `Daily Update (Jan 16, 2025): "Resolved issues regarding unset variables in Docker Compose" (#2387).` **Multiple Choice Answers:** a) Deployment-first: Docker/compose/macOS startup and cloud runtime parity become the top stabilization lane. *Implication:* Directly de-risks Cloud launch and improves first-run success rates for developers. b) Performance-first: prioritize concurrency and throughput (parallel requests) before widening distribution. *Implication:* Improves scalability but may leave many developers blocked at installation/deploy time. c) Client-first: stabilize social clients (Twitter/Discord) because they are the primary user-facing surface. *Implication:* Reduces visible failures in flagship demos, but Cloud infra risks may remain hidden until late. d) Other / More discussion needed / None of the above. **Question 3:** Should we formalize a 'stability sprint' cadence (e.g., every N weeks) to counteract feature influx? **Context:** - `Daily Report (Jan 15, 2025): large feature inflow (e.g., Instagram client #1964, RAG knowledge improvements #2351, S3 flexibility #2379) alongside many bug fixes.` - `Discord (Jan 15): repeated troubleshooting themes across Docker, embeddings/RAG, and Twitter.` **Multiple Choice Answers:** a) Yes—schedule recurring stability sprints with explicit no-new-features rules for core/runtime/deploy. *Implication:* Predictably improves reliability, but requires governance to resist scope creep. b) Partial—apply stability sprints only to Cloud and flagship agent tracks; keep plugins moving. *Implication:* Balances ecosystem experimentation with production-grade surfaces. c) No—treat stability as continuous; rely on CI and reviews rather than timeboxed freezes. *Implication:* Avoids cadence overhead, but risks stability work being perpetually deprioritized. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Developer Onboarding Friction: RAG, Docker/ARM64, and Installation Failures **Summary of Topic:** Field reports show recurring, high-friction failure modes: embeddings and RAG mental models are unclear, Docker builds fail across architectures (notably ARM64), and @discord/opus blocks installs. These are trust-killers for a developer-first framework and must be triaged into clear docs + safer defaults. #### Deliberation Items (Questions): **Question 1:** What is the single highest-leverage intervention to reduce "first hour" developer failures? **Context:** - `Discord (Jan 15, coders): "Cannot generate embedding: Memory content is empty" troubleshooting (Simz → tony).` - `Discord (Jan 15): "Docker build issues on ARM64" and "@discord/opus dependency" installation failures.` **Multiple Choice Answers:** a) Publish a canonical 'First Run' path (one blessed setup) with automated checks and remediation prompts. *Implication:* Maximizes first-success probability and reduces repetitive support, but narrows initial flexibility. b) Prioritize code-level guardrails: better defaults, clearer runtime errors, and auto-fallbacks (no docs dependency). *Implication:* Transforms failure into guided recovery; costs engineering time but scales better than support. c) Scale community support: coders-channel playbooks, pinned fixes, and a support rota; defer product changes. *Implication:* Fast to deploy socially, but risks institutionalizing fragility and burning out helpers. d) Other / More discussion needed / None of the above. **Question 2:** How should ElizaOS standardize RAG knowledge format to minimize confusion and embedding errors across adapters? **Context:** - `Discord (Jan 15, MonteCrypto): "Break knowledge into concise lines with specific keywords for embedding."` - `Action item: "Fix embedding errors when using different embedding models with Supabase (384 vs 1536)."` **Multiple Choice Answers:** a) Enforce a strict, validated knowledge schema (lint + runtime validation) with tooling to auto-chunk text. *Implication:* Reduces ambiguity and support tickets, but constrains advanced users unless extensibility is designed. b) Keep it flexible but ship best-practice templates and a "knowledge compiler" that recommends chunking. *Implication:* Maintains composability while guiding novices; some edge-case inconsistency persists. c) Defer standardization; focus on adapter compatibility and let the community converge on conventions. *Implication:* Lowest coordination cost now, but prolongs confusion and harms perceived framework maturity. d) Other / More discussion needed / None of the above. **Question 3:** What is our stance on heavyweight/fragile dependencies (e.g., Discord voice via @discord/opus) in the default install path? **Context:** - `Discord (Jan 15): "Installation issues with @discord/opus dependency" requiring workarounds.` - `Discord (Jan 14): guidance included "remove Discord voice functionality if not needed".` **Multiple Choice Answers:** a) Make voice dependencies fully optional and excluded by default; enable via explicit feature flags. *Implication:* Improves baseline install reliability and aligns with execution excellence, at the cost of extra setup for voice use-cases. b) Keep voice in default install but improve platform-specific installers and documentation. *Implication:* Preserves out-of-box capability, but continues to impose high failure rates on a broad user base. c) Split voice into a separate package/repo with independent release cadence. *Implication:* Reduces core fragility and clarifies ownership, but increases integration surface and coordination overhead. d) Other / More discussion needed / None of the above. --- ### 3. Topic: V2 Core vs Ecosystem Sprawl: Strategic Focus and Product Coherence **Summary of Topic:** Signals indicate early progress on a bare-bones V2 core while the ecosystem continues rapid expansion (new clients, onchain transformer, numerous plugins). The Council must decide how to protect execution excellence (Cloud + flagship stability) while harnessing community feature velocity without fragmenting the platform story. #### Deliberation Items (Questions): **Question 1:** What is the Council’s preferred operating model for V2 while V1 continues to accumulate plugins and clients? **Context:** - `Discord (Jan 15, Shaw): "pushing a basic v2 that is still 'bare bones'."` - `Daily Report (Jan 15): high feature inflow including "Onchain Agent Transformer" (PR #2319) and "Instagram client" (PR #1964).` **Multiple Choice Answers:** a) Hard fork focus: freeze major new V1 core features and move serious effort to V2 with a migration plan. *Implication:* Accelerates next-gen architecture but risks alienating builders relying on V1 stability/features. b) Dual-track: keep V1 stable with strict release discipline; incubate V2 in parallel with limited surface area. *Implication:* Maintains trust for current builders while enabling strategic evolution, but requires strong prioritization. c) V1-first: defer V2 until Cloud and flagship agents are fully stabilized and onboarding pain is reduced. *Implication:* Maximizes short-term reliability but may delay architectural improvements needed for future autonomy and scale. d) Other / More discussion needed / None of the above. **Question 2:** How should we govern plugin proliferation to remain "open & composable" without sacrificing reliability and UX coherence? **Context:** - `Discord (Jan 15): users report plugin integration problems and confusion around clients vs plugins (Twitter).` - `Daily Report (Jan 15): multiple new providers/clients and many fixes landing rapidly.` **Multiple Choice Answers:** a) Introduce a tiered plugin registry (Core/Verified/Experimental) with explicit support guarantees. *Implication:* Preserves openness while making quality legible; increases governance/maintenance overhead. b) Keep a single open registry but require automated tests, docs, and compatibility metadata for listing. *Implication:* Scales quality via automation; some users may still interpret listing as endorsement. c) Allow free-for-all registry; rely on disclaimers and community reputation signals. *Implication:* Maximizes experimentation but increases support burden and damages perceived reliability. d) Other / More discussion needed / None of the above. **Question 3:** Which "trust-through-shipping" artifact should become the Council’s primary narrative beacon during rapid change (rebrand, V2, Cloud)? **Context:** - `Discord (Jan 15, jin): proposal for weekly newsletters to prevent announcements from getting lost.` - `DankVR: desire for an "AI intern" to scribe relevant information from group chats to avoid the "game of telephone".` **Multiple Choice Answers:** a) A weekly Council Brief + changelog that explicitly ties shipped work to reliability and DX outcomes. *Implication:* Builds trust and alignment, but requires disciplined synthesis and consistent cadence. b) A public operational dashboard (build health, install success, top issues, Cloud uptime) as the single source of truth. *Implication:* Turns trust into measurable signals; requires instrumentation and ongoing maintenance. c) Flagship agent demos (stable, reproducible) as the narrative anchor, with docs as secondary. *Implication:* Creates visceral proof quickly, but can mask infrastructure and onboarding weaknesses. d) Other / More discussion needed / None of the above.