# Council Briefing: 2025-01-20 ## 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 high-velocity code surge delivered meaningful stability and DX improvements (Devin plugin, Telegram prerequisites, build/start fixes), but the Council must now contain reliability regressions emerging from rapid feature intake (embedding/vector mismatches, misleading startup errors, brittle config parsing). ## Key Points for Deliberation ### 1. Topic: Runtime Stability & Build Integrity (Execution Excellence) **Summary of Topic:** Core stability improved with develop-branch build/start fixes and CI workflow simplification, yet new defect signals are clustering around embeddings/vectors and misreported provider errors—directly threatening developer trust and Cloud-readiness. #### Deliberation Items (Questions): **Question 1:** Do we declare an immediate reliability freeze (triage-first) until the top failure modes (embeddings/vectors + misleading provider errors) are closed, even if it slows new plugins? **Context:** - `GitHub Daily Update (2025-01-20): "Resolved build/start failures in the develop branch" (#2545, #2546).` - `GitHub Daily Update (2025-01-20): "vector dimension mismatch error when switching to gpt-4o-mini in SQLite" (#2577) and "incorrect OpenAI error on startup when no API key is provided" (#2569).` **Multiple Choice Answers:** a) Yes—announce a short-term stability freeze with explicit exit criteria (top issues closed + regression tests added). *Implication:* Signals "Execution Excellence" to builders, reduces churn, and strengthens Cloud launch credibility. b) Partial freeze—allow only bugfixes, docs, and tests in core; new plugins allowed only behind feature flags. *Implication:* Balances ecosystem momentum with a controlled reliability campaign, but requires strong enforcement. c) No—continue parallel feature and fixes, relying on increased contributor volume to outpace regressions. *Implication:* Maximizes short-term growth optics, but risks compounding support load and eroding developer trust. d) Other / More discussion needed / None of the above. **Question 2:** What is our canonical strategy for embedding/vector compatibility across adapters (SQLite/PGlite/Postgres/Supabase) to prevent recurring dimension mismatch incidents? **Context:** - `GitHub Daily Update (2025-01-20): "vector dimension mismatch error when switching to gpt-4o-mini in SQLite" (#2577).` - `Discord coders (2025-01-19): recurring SQLite/Postgres/Supabase relation/connection errors and manual SQLite binding builds.` **Multiple Choice Answers:** a) Enforce a single default embedding dimension per release line (pinned) with automatic migration tooling. *Implication:* Minimizes runtime surprises and support incidents, at the cost of slower adoption of new embedding models. b) Support multi-dimension embeddings via per-room/per-agent metadata and adapter-level validation + re-embed workflow. *Implication:* Maximizes flexibility for advanced users, but increases complexity and testing surface area. c) Defer—document best practices only and treat dimension mismatch as user configuration responsibility. *Implication:* Low engineering cost now, but continues to leak reliability pain into onboarding and production deployments. d) Other / More discussion needed / None of the above. **Question 3:** How aggressive should we be in CI hardening to prevent "config parsing" and "misleading error" defects from reaching users? **Context:** - `GitHub Daily Update (2025-01-20): "Identified an issue with boolean parsing for ENABLE_OPEN_AI_COMMUNITY_PLUGIN" (#2559).` - `GitHub Daily Update (2025-01-20): "Removed unnecessary cleanup steps from the integration tests workflow" (#2551, #2553).` **Multiple Choice Answers:** a) Add a strict 'configuration contract' test suite (env parsing, provider selection, error messages) as release-gating. *Implication:* Reduces support burden and improves perceived polish, aligning with the North Star's reliability mandate. b) Add targeted smoke tests only for the top 5 user journeys (start agent, connect DB, run Telegram/Twitter, basic RAG). *Implication:* Faster to implement and still meaningful, but may miss edge-case regressions that frustrate power users. c) Rely on community issue reports and rapid patching; keep CI lean to preserve merge velocity. *Implication:* Maintains throughput, but perpetuates a reactive posture that undermines "Trust Through Shipping." d) Other / More discussion needed / None of the above. --- ### 2. Topic: Plugin Ecosystem Velocity vs. Coherence (Composability with Guardrails) **Summary of Topic:** Feature additions expanded capability breadth (NVIDIA inference, Anthropic vision, Lightning, filesystem agent storage), but Discord signals show developer confusion around multi-plugin use and V2 backward compatibility—suggesting we need stricter composability guarantees. #### Deliberation Items (Questions): **Question 1:** Should we introduce a formal 'Composability Contract' for plugins (multi-plugin support, dependency hygiene, consistent config schema) before accelerating V2 migration messaging? **Context:** - `Discord (2025-01-19): "Implement multi-plugin support for Eliza characters" (action item; question was unanswered in discussion).` - `Discord partners (2025-01-19): "There's an effort to make things backwards compatible" (re: V2 plugins).` **Multiple Choice Answers:** a) Yes—define and enforce a composability contract (interfaces + test matrix) as a prerequisite for V2 plugin stability claims. *Implication:* Prevents fragmented plugin behavior and builds a durable ecosystem foundation for Cloud and multi-agent systems. b) Partially—publish a 'recommended plugin set' and compatibility tiers, but keep enforcement light until V2 ships. *Implication:* Reduces immediate friction without blocking community contributions, but may leave long-tail inconsistency. c) No—prioritize feature growth; composability will emerge organically via community iteration. *Implication:* High ecosystem velocity, but risks turning ElizaOS into a plugin bazaar without predictable integration quality. d) Other / More discussion needed / None of the above. **Question 2:** How do we gate high-impact provider additions (e.g., NVIDIA inference, OpenAI integration, new vision providers) to avoid destabilizing default paths for new developers? **Context:** - `GitHub Updates (2025-01-19 summary): "Added support for NVIDIA inference" (#2512), "Added Anthropic image provider" (#2524), "Integrated OpenAI for text generation" (#2463).` - `Discord coders (2025-01-19): "Model selection (small/medium/large) is not being respected" (reported issue).` **Multiple Choice Answers:** a) Provider additions must ship behind explicit opt-in flags until validated across reference agents + adapters. *Implication:* Protects onboarding defaults and reduces surprise regressions, while still allowing power-user experimentation. b) Allow providers to land freely, but lock the 'default provider + default models' to a conservative LTS set. *Implication:* Maintains contribution velocity while keeping a stable runway for most users. c) Treat all providers as first-class immediately to maximize perceived capability and competitive positioning. *Implication:* Improves headline features, but increases the chance that basic setups break or behave inconsistently. d) Other / More discussion needed / None of the above. **Question 3:** What is the Council’s stance on agent-to-agent interoperability as a near-term platform differentiator versus a post-V2 milestone? **Context:** - `Discord partners (2025-01-19): "Yes, that's the intention, with full multiplayer chat" (agent-to-agent interactions).` - `Discord (2025-01-19): emphasis on V2 development and smooth transition for plugin developers.` **Multiple Choice Answers:** a) Make multiplayer agent interaction a flagship near-term objective; prioritize a minimal, reliable protocol now. *Implication:* Differentiates ElizaOS as a true multi-agent OS, but increases scope pressure during stabilization. b) Treat it as a V2+ milestone; focus current cycles on reliability, deployment, and plugin compatibility. *Implication:* Strengthens "Execution Excellence" and Cloud readiness, but delays a compelling multi-agent narrative. c) Keep it experimental: ship prototypes in reference agents only, while core remains stable and conservative. *Implication:* Enables learning and marketing demos without committing the core platform to immature interfaces. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer Onboarding & Deployment Friction (DX as Trust Engine) **Summary of Topic:** Telegram prerequisites documentation and new tooling landed, yet Discord logs show recurring onboarding failures (npm/package confusion, Twitter/Telegram client breakage, Windows SQLite builds, Supabase schema errors), indicating our DX is still brittle at the edges. #### Deliberation Items (Questions): **Question 1:** What is the single highest-leverage onboarding fix we should ship next to convert community troubleshooting into reliable self-serve setup? **Context:** - `GitHub Updates (2025-01-19 summary): "Updated README with prerequisites for enabling Telegram bot" (#2547).` - `Discord coders (2025-01-19): recurring "package not found in npm registry" confusion and Telegram/Twitter install issues.` **Multiple Choice Answers:** a) Ship a 'Doctor' CLI that validates environment, Node/pnpm versions, adapters, and client prerequisites with actionable fixes. *Implication:* Turns fragmented tribal knowledge into productized reliability, reducing Discord support load. b) Create a single canonical 'Production Deployment' guide (Railway/VPS/Docker) with known-good templates and defaults. *Implication:* Accelerates serious builders to production, but may not solve first-run local setup failures. c) Prioritize platform-specific fixes (Windows SQLite build + Supabase schema) as the biggest blockers to first success. *Implication:* Improves success rate for a large segment quickly, but risks whack-a-mole if root causes are systemic. d) Other / More discussion needed / None of the above. **Question 2:** Do we standardize and officially support one default persistence path (SQLite -> Postgres) to reduce DB confusion, or continue broad adapter parity? **Context:** - `Discord coders (2025-01-19): repeated SQLite/PostgreSQL/Supabase errors (relation missing, connection not open).` - `GitHub Daily Update (2025-01-20): SQLite vector mismatch issue when switching models (#2577).` **Multiple Choice Answers:** a) Standardize: Officially support SQLite for local + Postgres for production, with a documented migration path. *Implication:* Improves clarity and reduces support burden while still serving both prototyping and production. b) Maintain broad parity across adapters, but add conformance tests so adapters behave identically. *Implication:* Maximizes openness and composability, but requires sustained investment in testing and maintenance. c) De-emphasize local DB complexity by pushing ElizaOS Cloud storage as the default for most users. *Implication:* Simplifies onboarding and aligns with Cloud strategy, but may alienate self-hosting/open-source purists. d) Other / More discussion needed / None of the above. **Question 3:** How should we handle packaging/publishing expectations to avoid "package not found" failures and repo-vs-npm confusion? **Context:** - `Discord coders (2025-01-19): "The packages are already installed in the repo; they appear in the packages folder. You don't need to install them separately." (answer by skeeet.........)` - `GitHub issues (2025-01-19.json): install issues include "Problems with installing @elizaos/plugin-0g" (#2513) and Telegram client not working (#2557).` **Multiple Choice Answers:** a) Declare a clear distribution model: Starter repo consumes published packages; monorepo is for contributors (with explicit docs). *Implication:* Reduces ambiguity and aligns with a professional developer experience. b) Make everything publishable and consistently available on npm, so repo and npm flows behave the same. *Implication:* Simplifies mental model but increases release engineering overhead and versioning complexity. c) Keep the current hybrid approach but add prominent install-time warnings and better error messages. *Implication:* Low effort, but ongoing friction may persist and continue leaking into support channels. d) Other / More discussion needed / None of the above.