# Council Briefing: 2025-01-08 ## 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 advanced execution excellence by hardening build/DB reliability and shipping core-system improvements (RAG/CI) while the volume of new plugins continues to test our ability to keep a coherent, stable developer experience. ## Key Points for Deliberation ### 1. Topic: Reliability Frontier: Build + Database Stability as Trust Engine **Summary of Topic:** Operational logs show meaningful progress on build and DB stability (packaging fixes, CI lockfile enforcement, DB adapters), but also recurring startup and vector/embedding failures that erode developer trust if not systematically eliminated. #### Deliberation Items (Questions): **Question 1:** Do we declare a short "stability window" where merges are gated by reproducible install/start tests across the top deployment targets (local, Docker, Windows), even if it slows plugin intake? **Context:** - `Daily Update 2025-01-08: "Added a pnpm lockfile consistency check to enhance CI processes" (#2015).` - `GitHub issues summary: "continuous errors when starting agents" (#2024) and "ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL" (#2127).` **Multiple Choice Answers:** a) Yes—freeze non-critical feature merges and enforce cross-platform install/start gates for 1–2 weeks. *Implication:* Accelerates trust-through-shipping by reducing regressions, but may frustrate plugin contributors expecting fast merges. b) Partially—gate only core/runtime and top-tier plugins, leaving experimental plugins on a separate track. *Implication:* Preserves velocity while protecting the core, but requires explicit tiering and enforcement to avoid "everything is critical" drift. c) No—maintain current merge velocity and rely on post-merge fixes and community triage. *Implication:* Maximizes breadth of ecosystem growth, but raises the probability of recurring breakages that damage DX and Cloud adoption. d) Other / More discussion needed / None of the above. **Question 2:** Which persistence stack should be canon for production guidance in the near term: PostgreSQL/Supabase, PGLite, or SQLite with strict embedding controls? **Context:** - `Daily Summary 2025-01-07: "Added PGLite database adapter" and "Fixed SQLite error related to zero-length vectors" (#1984).` - `Discord 2025-01-07: "SQLite errors related to vector dimensions and zero-length vectors"; common advice: delete DB and rebuild.` **Multiple Choice Answers:** a) Canonize Postgres/Supabase for production; position SQLite/PGLite as dev/test only. *Implication:* Improves reliability expectations and scaling path, but increases setup friction for new builders. b) Canonize PGLite as the default bridge (local-first Postgres semantics), with Postgres/Supabase as the scale-up path. *Implication:* Unifies developer experience with fewer "works on my machine" mismatches, but adds a relatively newer dependency surface. c) Keep SQLite as default and invest in stronger embedding migration/versioning + guardrails to prevent corruption. *Implication:* Lowest barrier to entry, but requires disciplined engineering to prevent recurring vector mismatch incidents. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should the Council prioritize eliminating "agent won't start" classes of errors versus expanding feature surface area (plugins/providers)? **Context:** - `Daily Update 2025-01-08: "Users are experiencing continuous errors when starting the agent" (#2024).` - `GitHub Activity: 36 PRs/day pace, many new plugins, while issues still appear around core usability.` **Multiple Choice Answers:** a) Treat startup reliability as Priority-0: no new features until the top startup errors are near-zero. *Implication:* Maximizes execution excellence and Cloud readiness; may reduce ecosystem buzz temporarily. b) Run a dual-track: a dedicated reliability squad plus continued plugin throughput with stricter templates/tests. *Implication:* Balances growth and trust, but depends on clear ownership and enforcement to avoid diffusion of responsibility. c) Focus on feature breadth now; let the community self-resolve startup issues through docs and forums. *Implication:* Increases experimentation, but risks reputational damage if builders repeatedly hit non-actionable startup failures. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Comms & Platform Surface: Twitter/Telegram Integration as Public-Facing Stability **Summary of Topic:** Discord and GitHub signals converge: social integrations remain a primary pain point (auth loops, formatting issues, dry-run inconsistencies), and these are the most visible failure modes for flagship agents and community deployments. #### Deliberation Items (Questions): **Question 1:** Should ElizaOS formalize a supported "Social Client Compatibility Matrix" (Twitter/Telegram/Discord) with explicit modes (API vs browser simulation, cookies, rate limits), and gate releases against it? **Context:** - `Discord 2025-01-07: "Multiple users reported issues with Twitter integration, including authentication problems, replies formatting as JSON, and rate limiting concerns."` - `Discord 2025-01-07: PR #1974 created to fix Twitter plugin to use client-twitter instead of scraper, avoiding repeated login attempts.` **Multiple Choice Answers:** a) Yes—publish and enforce a compatibility matrix with automated regression tests for core social flows. *Implication:* Improves predictability and reduces repeated support burden, but increases maintenance cost as platforms change. b) Publish the matrix as documentation only, without gating releases. *Implication:* Improves transparency quickly, but may not reduce regressions without enforcement. c) No—keep social clients as best-effort community plugins without official guarantees. *Implication:* Protects core focus, but undermines flagship agent credibility in the most public deployment channels. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s stance on the tradeoff between automation and safety for public posting: do we recommend "approval workflow" as default for Twitter posting? **Context:** - `Daily Summary 2025-01-07: "Added approval mechanism for Twitter posts via Discord bot."` - `Daily Update 2025-01-08: Closed issue: "dry-run mode issue in the Twitter client" (#1962) addressed.` **Multiple Choice Answers:** a) Default to manual approval for all Twitter posts; require opt-in to autonomous posting. *Implication:* Reduces reputational and ToS risk, but weakens the "autonomous agent" narrative for demos. b) Default to autonomous posting with optional approval for high-risk accounts/characters. *Implication:* Maximizes autonomy and engagement, but increases the chance of public misfires and platform enforcement actions. c) Use a hybrid: autonomous replies to mentions only, approval for original tweets and quotes/retweets. *Implication:* Balances responsiveness with brand safety, but adds complexity and requires strong defaults/documentation. d) Other / More discussion needed / None of the above. **Question 3:** Do we invest immediately in first-class formatting controls (plain text vs JSON) across all clients, or treat it as per-client configuration burden? **Context:** - `Discord 2025-01-06: "Why does my agent tweet in JSON format instead of plain text? Add responseFormat/text and outputFormat/plain."` - `Discord 2025-01-07: "Fix JSON formatting in tweet responses" listed as an action item (0xJam3s).` **Multiple Choice Answers:** a) Make output format a top-level, consistent runtime setting with safe defaults per client. *Implication:* Reduces confusion and support load; creates a unified DX story across integrations. b) Keep as character-level settings and improve docs/templates to set them correctly. *Implication:* Fast to implement with minimal core changes, but errors will persist among new users. c) Leave it to client implementers and community examples; core should remain minimal. *Implication:* Avoids core complexity, but risks fragmented behavior that conflicts with developer-first principles. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Knowledge & RAG: Toward Composable Memory Without Fragmentation **Summary of Topic:** A separate Knowledge system with Multi-Agent RAG Optimization and new knowledge CRUD/search methods are shipping, creating a path to stronger multi-agent memory—yet this raises governance questions: default enablement, migration strategy, and documentation to prevent confusion. #### Deliberation Items (Questions): **Question 1:** Should the new separate Knowledge/RAG system become the default path for knowledge retrieval, or remain opt-in until we prove stability and migration tooling? **Context:** - `Daily Update 2025-01-08: "Implemented a new RAG optimization system that operates separately... allowing for user-enabled functionality" (#1620).` - `Daily Summary 2025-01-07: "Implemented getKnowledge, searchKnowledge, createKnowledge, removeKnowledge, and clearKnowledge methods" (#2005).` **Multiple Choice Answers:** a) Keep it opt-in until we publish migration guides, benchmarks, and failure-mode playbooks. *Implication:* Protects reliability and avoids breaking existing agents, but slows ecosystem convergence on better memory. b) Make it default for new agents only; legacy agents remain on the old path until upgraded. *Implication:* Creates a clean forward path while minimizing disruption, but introduces dual-system complexity in docs/support. c) Flip the default globally and prioritize fixing regressions quickly. *Implication:* Forces rapid standardization and accelerates capability, but risks a wave of support incidents and trust loss. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council-approved definition of "multi-agent" in ElizaOS for the next release cycle: shared knowledge store, orchestrated task delegation, or both? **Context:** - `Discord 2025-01-07 Action Items: "Develop a knowledge transfer system between agent instances" (Mike D.).` - `Discord 2025-01-07 Features: "Implement multi-agent orchestration similar to OpenAI swarms or crewAI" (0xn1c0).` **Multiple Choice Answers:** a) Prioritize shared knowledge/memory primitives first; orchestration later. *Implication:* Builds a solid substrate for interoperability, but delays visible "swarm" functionality demos. b) Prioritize orchestration primitives first (task routing, roles), even with minimal shared memory. *Implication:* Delivers exciting demos quickly, but risks shallow or brittle behavior without robust memory semantics. c) Commit to both via a minimal "multi-agent baseline" spec and ship iteratively behind feature flags. *Implication:* Aligns with open/composable principles while controlling risk, but requires strong product governance and docs. d) Other / More discussion needed / None of the above. **Question 3:** How do we prevent documentation entropy as plugins and knowledge primitives multiply: do we deploy an official "scribe agent" pipeline to turn Discord/GitHub into canonical docs? **Context:** - `Discord 2025-01-06: "Jin proposed creating an Eliza agent as a 'scribe' to reduce friction in documentation contributions."` - `Discord 2025-01-07 Documentation: calls for READMEs/JSDoc across undocumented plugins (Ed Marcavage).` **Multiple Choice Answers:** a) Yes—stand up a scribe agent pipeline that converts high-signal discussions into PR-ready docs with human review. *Implication:* Operationalizes the "Taming Information" strategy and scales documentation quality with community activity. b) Partially—use the scribe agent only for weekly/monthly summaries, not for canonical docs. *Implication:* Reduces risk of incorrect docs, but misses the chance to reduce day-to-day support and onboarding friction. c) No—keep documentation human-authored to avoid hallucinations and governance disputes. *Implication:* Maximizes accuracy, but constrains documentation throughput and may fail under current ecosystem growth rate. d) Other / More discussion needed / None of the above.