# Council Briefing: 2025-01-02 ## 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 - Jan 2’s critical trajectory is stabilization-by-shipping: tightening core reliability via targeted plugin enhancements (web search/SUI) and patching high-friction runtime failures (image services, schema, builds) to protect developer trust. ## Key Points for Deliberation ### 1. Topic: Reliability Triage: Breaking Issues Across Core Services **Summary of Topic:** Operational work on Jan 2 reduced friction by fixing image description/provider wiring, Supabase schema faults, and build blockers, but new issues (Google model API key handling, unsupported image errors, PostgreSQL start failures) signal ongoing reliability debt that threatens the “execution excellence” mandate. #### Deliberation Items (Questions): **Question 1:** Do we declare a short-term “stability freeze” (limited merges) until the top runtime blockers (Postgres startup, image provider errors, model provider key handling) are resolved end-to-end? **Context:** - `Daily Update (2025-01-02): "New issues regarding build failures ... starting agents with PostgreSQL configurations (#1680, #1687)."` - `Daily Update (2025-01-02): "Reported an issue with the Google Model not functioning correctly due to API key handling (#1709)."` **Multiple Choice Answers:** a) Yes—impose a stability freeze with a short, explicit exit criterion (e.g., green smoke tests + fixed top 5 issues). *Implication:* Maximizes trust-through-shipping and lowers regressions, at the cost of slowing new feature inflow. b) Partial freeze—allow merges only for fixes, tests, docs, and critical provider/plugin repairs. *Implication:* Balances velocity with reliability, but requires strict triage discipline and enforcement. c) No—keep normal velocity and rely on incremental fixes as issues appear. *Implication:* Preserves feature cadence, but risks compounding instability and eroding developer confidence. d) Other / More discussion needed / None of the above. **Question 2:** Which failure class should be treated as “P0 Council-level” because it directly blocks new builders: database boot (Postgres/Supabase), provider auth (Google/OpenAI), or media pipelines (Image Description Service)? **Context:** - `Daily Update (2025-01-02): "Fixed a syntax error in the Supabase schema that was causing upload failures (#1660)."` - `Daily Update (2025-01-02): "Identified a problem with unsupported image errors from the OpenAI API when using the Image Description Service (#1694)."` **Multiple Choice Answers:** a) Database boot is P0 (Postgres/Supabase/SQLite vectors), because it prevents any persistent agent from running reliably. *Implication:* Improves baseline operability and Cloud readiness; may delay polish features. b) Provider auth is P0 (Google/OpenAI key handling), because it’s the fastest path to “it works” for new devs. *Implication:* Reduces onboarding churn immediately but leaves latent data-layer fragility. c) Media pipelines are P0 (image description/upload), because social agents are our public-facing trust surface. *Implication:* Protects flagship agent perception but risks a “pretty demo” atop shaky foundations. d) Other / More discussion needed / None of the above. **Question 3:** Should we formalize an “error budget” policy for plugins/providers (Twitter, image, DB adapters) to prevent repeated breakages from consuming core capacity each cycle? **Context:** - `Discord (2025-01-01): "Fix vector database error: 'SqliteError: ... zero-length vectors are not supported' (ibcflan)."` - `Discord (2025-01-01): "Fix Twitter client ... leak JSON format (POPPP)"` **Multiple Choice Answers:** a) Yes—define error budgets and gating tests per plugin tier (core vs community) with escalation paths. *Implication:* Increases predictability and reduces firefighting, but adds process overhead. b) Yes, but only for “core” plugins (Discord, Twitter, DB adapters); leave community plugins best-effort. *Implication:* Targets the highest trust surface while keeping ecosystem experimentation fast. c) No—keep an informal approach; use community triage and rapid patching. *Implication:* Minimizes bureaucracy but risks recurring reliability spirals as scale increases. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Developer Experience & Documentation as a System (Taming Information) **Summary of Topic:** The community is actively organizing 45+ plugins and requesting docs parity with code; operational proposals (AI greeter, Discord Q&A extraction, GitHub activity pipeline, OpenTelemetry tracing) point toward a scalable “documentation + observability loop” that can convert community support into durable product trust. #### Deliberation Items (Questions): **Question 1:** Do we prioritize an official “plugin catalog + one-liner registry + docs sync” release artifact to reduce onboarding friction and support load? **Context:** - `Discord (2025-01-01): "0xwitch sorting them into core packages, database adapters, client packages, blockchain packages, and general plugins"` - `Discord (2025-01-01): "Update ElizaOS docs to match current code (Mr. Kiter)"` **Multiple Choice Answers:** a) Yes—ship a curated plugin catalog as a first-class docs section with ownership, maturity labels, and examples. *Implication:* Directly improves DX and reduces repeated Discord support, strengthening trust. b) Partially—publish an auto-generated catalog first (low-touch), then curate incrementally. *Implication:* Fast time-to-value but risks inaccuracies unless automated outputs are validated. c) No—keep discovery community-driven to avoid central bottlenecks. *Implication:* Maintains decentralization but increases fragmentation and inconsistent onboarding. d) Other / More discussion needed / None of the above. **Question 2:** Should OpenTelemetry tracing be treated as mandatory core infrastructure (enabled-by-default in dev) to accelerate debugging and reliability work? **Context:** - `Discord (2025-01-01): "OpenTelemetry tracing is being added to Eliza for better debugging capabilities"` - `Discord (2025-01-01): "Add OpenTelemetry tracing to main Eliza repo (Mike D.)"` **Multiple Choice Answers:** a) Yes—make it default in dev builds with minimal config, and optional in production. *Implication:* Shortens incident resolution time and supports execution excellence. b) Optional—provide a well-documented opt-in module to avoid overhead and complexity. *Implication:* Reduces risk of performance/config issues but slows systematic debugging gains. c) Defer—focus on fixing top bugs first; add tracing after the current instability wave. *Implication:* Preserves short-term velocity but prolongs the “unknown unknowns” debugging tax. d) Other / More discussion needed / None of the above. **Question 3:** Do we operationalize Discord knowledge extraction (auto Q&A harvesting + conversion to agent knowledge) as a formal pipeline owned by Council? **Context:** - `Discord (2025-01-01): "Automate finding questions and answers in Discord to build agent knowledge (jin)"` - `Discord (2025-01-01): "Set up GitHub activity pipeline for streamlined updates (jin)"` **Multiple Choice Answers:** a) Yes—build a pipeline that produces versioned FAQ/docs PRs and agent-readable knowledge artifacts weekly. *Implication:* Turns community support into compounding documentation assets and better agent UX. b) Pilot—run it only on the top 2 support channels (e.g., discussion + coders) for 30 days. *Implication:* De-risks automation quality and moderation overhead before scaling to the whole Discord. c) No—keep support human-led; use ad-hoc summaries instead of automation. *Implication:* Avoids automation mistakes but limits scaling and repeats the same support cycles. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Composable Expansion vs Stability: Plugins, Chains, and “Cloud-Readiness” **Summary of Topic:** Jan 2 shipped capability expansion (SUI key format support, activated web search via Tavily), while ongoing community focus pushes cross-chain and new integrations; the strategic risk is ecosystem sprawl outpacing reliability, undermining the Cloud launch and flagship agent stability goals. #### Deliberation Items (Questions): **Question 1:** Should Council define a “Tier-1 compatibility matrix” (OS/DB/clients/providers) and require new plugins to meet it (tests + docs) before being promoted as recommended? **Context:** - `Daily Update (2025-01-02): "Added support for the SUI plugin with the new suiprivatekey account configuration (#1693)."` - `Discord (2025-01-01): "Deployment challenges across different environments (Ubuntu, WSL, MacOS) ... dependency issues"` **Multiple Choice Answers:** a) Yes—introduce a Tier-1 matrix and promotion process (recommended vs experimental) enforced in docs and registry. *Implication:* Clarifies expectations and improves Cloud readiness, but may slow ecosystem breadth. b) Soft matrix—publish recommended environments and best practices without hard gating. *Implication:* Improves guidance while preserving openness, but risks “recommended” drift over time. c) No—avoid tiers; let community usage signal what’s stable. *Implication:* Keeps decentralization pure, but new users face higher ambiguity and failure rates. d) Other / More discussion needed / None of the above. **Question 2:** How do we sequence cross-chain ambitions (e.g., DegenAI cross-chain roadmap) against the immediate need to stabilize core agent operations and integrations? **Context:** - `Discord (2025-01-01): "Cross-chain functionality is in development for DegenAI... onboarding of new developers underway (jin)"` - `Discord (2025-01-01): "Twitter integration challenges ... API rate limiting, authentication problems"` **Multiple Choice Answers:** a) Stability-first: lock core + flagship agents, then expand cross-chain once baseline reliability is proven. *Implication:* Protects trust-through-shipping but may delay strategic narrative of multi-chain dominance. b) Parallel tracks: dedicate a small, isolated cross-chain squad; keep core team focused on reliability. *Implication:* Maintains momentum on both fronts but requires strong interface boundaries and coordination. c) Expansion-first: prioritize cross-chain integrations to capture ecosystem attention and developer inflow now. *Implication:* Grows surface area quickly but increases operational risk and maintenance burden. d) Other / More discussion needed / None of the above. **Question 3:** Do we treat “web search activation” as a flagship default capability, or keep it opt-in to reduce reliability and cost variability across deployments? **Context:** - `Daily Update (2025-01-02): "Improved web search functionality by activating the Tavily API key for agents (#1676)."` - `GitHub Daily (2025-01-01): "Added web search functionality to the agent (#1676, #1577)."` **Multiple Choice Answers:** a) Default-on for Cloud/flagship agents; opt-in for self-hosted by env var to control cost and risk. *Implication:* Improves flagship UX while preserving self-hosted predictability. b) Opt-in only everywhere, with clear docs and templates for enabling it. *Implication:* Reduces surprises and outages, but lowers perceived “magic” for new users. c) Default-on everywhere to standardize agent capability expectations. *Implication:* Simplifies mental models but increases dependency on external API stability and costs. d) Other / More discussion needed / None of the above.