# Council Briefing: 2025-03-21 ## 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 shifted from rapid feature throughput to stability-first triage—shipping targeted UI refinements while surfacing core reliability risks (packaging, IDs, provider limits) that threaten developer trust ahead of V2 and Cloud-era expectations. ## Key Points for Deliberation ### 1. Topic: V2 Readiness: UX Polish vs. Stability Gates **Summary of Topic:** UI improvements (notably the action viewer) continue to land, but the operational signal shows rising pressure to define a “release gate” that protects reliability and minimizes regression churn. Council alignment is needed on what constitutes “ready” in a developer-first universe where trust is earned by predictable behavior, not visual shine. #### Deliberation Items (Questions): **Question 1:** What is the Council’s minimum release gate for V2/Cloud-era trust: UX completeness, crash-free boot, or end-to-end “golden path” tutorials that actually run? **Context:** - `GitHub summary (2025-03-21): “Improved the action viewer UI… triaged new issues…”` - `Discord (2025-03-20, 💻-coders): “users appreciating the content but still struggling with implementation” (docs at eliza.how)` **Multiple Choice Answers:** a) Gate on reliability: crash-free startup + core agent loop stable across recommended environments. *Implication:* Maximizes execution excellence and reduces support burden, but may delay UX polish and demo momentum. b) Gate on “golden path” DX: one blessed install + one blessed deployment path that works with docs verbatim. *Implication:* Optimizes developer trust directly, but requires concentrated docs/testing resources and may postpone secondary features. c) Gate on flagship UX: ship when the UI/agent builder feels complete enough for broad onboarding. *Implication:* Improves first impressions, but risks reputational damage if underlying reliability remains inconsistent. d) Other / More discussion needed / None of the above. **Question 2:** How should we sequence Spartan/DegenAI reactivation relative to V2 stabilization, given the dependency on the V2 stack? **Context:** - `Discord (2025-03-20, spartan_holders): “Enable Spartan chat functionality before V2 official launch” (Odilitime).` - `Discord (2025-03-19): “Current priority is getting open-source functionality working in v2 and deploying Spartan…” (rhota).` **Multiple Choice Answers:** a) Stabilize V2 first; keep Spartan in controlled beta until core regressions are resolved. *Implication:* Prevents flagship agents from becoming public proof of instability, preserving long-term brand trust. b) Parallel-track: ship Spartan chat behind explicit “beta” framing while core team continues stabilization. *Implication:* Maintains community energy and token-holder value, but increases incident surface area and support load. c) Prioritize Spartan as the flagship; treat its working chat loop as the acceptance test for V2 readiness. *Implication:* Creates a single north-star integration test, but may bias architecture toward one agent’s needs over framework generality. d) Other / More discussion needed / None of the above. **Question 3:** Should Council mandate a single canonical “blessed” install command/path for the beta to reduce fragmentation across versions (0.25.9 vs 1.0.0-beta)? **Context:** - `Discord (2025-03-20): Beta install steps repeated across channels: “npm create eliza@beta … npx @elizaos/cli start”.` - `Discord (2025-03-20): “Users reported issues with… v0.25.9… could no longer interact with their agent via terminal” (FBRN).` **Multiple Choice Answers:** a) Yes—declare one supported beta track and clearly deprecate older quickstarts. *Implication:* Reduces confusion and accelerates feedback quality, but may alienate users stuck on older setups. b) Maintain dual-track support temporarily, but add a versioned compatibility matrix and migration guide. *Implication:* Minimizes user disruption, but increases docs and support complexity during an already unstable phase. c) Keep it flexible; let the community self-select versions while we focus on shipping features. *Implication:* Maximizes velocity short-term, but directly undermines the “reliable, developer-friendly” North Star via fragmentation. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Developer Trust Fault Lines: Packaging, IDs, and Provider Limits **Summary of Topic:** Multiple “sharp edges” emerged that disproportionately harm DX: missing beta packages, UUID/id coercion failures, and model provider token-per-minute ceilings. These issues are existential to reliability perception because they break the first-run experience and force developers into archaeology rather than building. #### Deliberation Items (Questions): **Question 1:** How do we treat packaging integrity failures in beta (e.g., missing @elizaos/plugin-openai): as release blockers or as expected beta turbulence? **Context:** - `GitHub issue (2025-03-21): “@elizaos/plugin-openai package not found when using beta packages” (#4037).` **Multiple Choice Answers:** a) Release blocker: packaging must be consistent for any public beta we want developers to trust. *Implication:* Aligns with “Developer First,” but may slow iteration as release engineering becomes mandatory. b) Non-blocker, but require a rapid hotfix SLA and a public incident log for transparency. *Implication:* Maintains velocity while protecting trust through communication, but risks repeated paper cuts. c) Defer; advise users to pin versions or use alternative providers until the ecosystem settles. *Implication:* Shifts cost to developers and erodes confidence precisely when we need adoption and feedback. d) Other / More discussion needed / None of the above. **Question 2:** Should we standardize and enforce an “ID hygiene protocol” across clients/plugins to prevent UUID conversion failures (especially for negative or non-UUID external IDs)? **Context:** - `GitHub issue (2025-03-21): “invalid input syntax for type uuid: \"-1002129157442\"” (#4042).` - `Recent merged work (PR #4052 listed in completed items): “Fix Telegram negative chat ID UUID conversion” (plugin/telegram-related).` **Multiple Choice Answers:** a) Yes—define a canonical ID normalization layer in core and require all plugins to use it. *Implication:* Prevents recurring class of bugs and improves composability, but requires coordinated refactors. b) Plugin-owned: provide best-practice utilities, but let each client/plugin decide. *Implication:* Faster locally, but higher long-term entropy and repeated regressions across the ecosystem. c) Database schema flexibility: relax UUID constraints where external IDs are common. *Implication:* Reduces friction quickly, but may compromise data consistency and cross-system interoperability. d) Other / More discussion needed / None of the above. **Question 3:** How should we operationalize model/provider limits (e.g., Groq TPM caps) so agents fail gracefully and predictably rather than mysteriously? **Context:** - `GitHub issue (2025-03-21): “Groq tokens per minute (TPM) limit of 6000” (#4040).` - `GitHub (recent merged PR #4044): “Groq integration” introduced new provider surface area.` **Multiple Choice Answers:** a) Implement unified rate-limit and backoff handling in core runtime, surfaced in UI logs and CLI. *Implication:* Creates consistent behavior across providers and strengthens reliability, at the cost of core complexity. b) Handle limits in each provider plugin with documented recommended defaults. *Implication:* Keeps core lean, but produces inconsistent UX and repeated reinvention across plugins. c) Document the limits and rely on community best practices without adding runtime logic yet. *Implication:* Fastest to ship, but violates “seamless UX over feature quantity” and increases support volume. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Strategic Architecture: Golang Port vs. Hardening the TypeScript Core **Summary of Topic:** A proposal surfaced to port ElizaOS to Golang for performance; this is a strategic fork decision with high opportunity cost. Council must decide whether performance/throughput is best achieved by a language port, by targeted optimization (Bun/Tauri/WebSockets), or by Cloud-managed infrastructure while keeping the framework developer-friendly. #### Deliberation Items (Questions): **Question 1:** Does pursuing a Golang port advance our North Star (reliability + developer-friendly) or distract from stabilizing V2 and Cloud launch execution? **Context:** - `GitHub (2025-03-21): “Needs Attention: discussion needed… Golang port of ElizaOS for performance improvements” (#4034).` **Multiple Choice Answers:** a) Reject for now: focus on stabilizing TypeScript core and Cloud reliability before any language port. *Implication:* Protects near-term execution excellence and reduces strategic drift during a critical migration window. b) Explore as an R&D track: small spike/prototype with strict timebox and measurable performance targets. *Implication:* Keeps optionality without derailing the roadmap, but still consumes senior attention and review bandwidth. c) Commit to a dual-runtime strategy: Go core for performance, TS SDK for plugins and DX. *Implication:* Potentially best long-term throughput, but introduces major coordination risk, interoperability complexity, and community fragmentation. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s preferred performance path in the near term: runtime optimization (Bun/WebSockets), Cloud-managed scaling, or architectural simplification (fewer moving parts)? **Context:** - `Discord (2025-03-18): “Shaw added websocket functionality… enabling direct agent connections to web interfaces.”` - `Recent PR activity: socket/web client refinements and UI performance work (multiple PRs in 2025-03-20 daily report).` **Multiple Choice Answers:** a) Lean into Cloud-managed scaling as the default; optimize framework for local dev and correctness. *Implication:* Strengthens the platform narrative and reduces local performance pressures, but increases dependency on Cloud readiness. b) Optimize the existing TS runtime (Bun/WebSockets/DB hot paths) to reduce infra demands everywhere. *Implication:* Improves self-hosting credibility and open-source strength, but may be slower than scaling via Cloud. c) Simplify architecture and reduce surface area (fewer clients, fewer modes) until stability is proven. *Implication:* Maximizes reliability and reduces bug surface, but may frustrate ecosystem experimentation and integrations. d) Other / More discussion needed / None of the above. **Question 3:** How do we prevent “innovation drift” (new providers/plugins) from eroding reliability—should we formalize an “experimental zone” with stricter stability guarantees for the core? **Context:** - `Recent PRs: “Groq integration” (#4044), “Redpill support” (#4045), “DPSN Plugin” (#4043) alongside beta instability signals.` - `GitHub activity (2025-03-20 to 2025-03-21): “22 new PRs (16 merged)… 5 new issues” indicates high churn.` **Multiple Choice Answers:** a) Yes—create tiered maturity levels (experimental/beta/stable) with gating in registry and docs. *Implication:* Preserves composability while protecting trust, but requires governance and tooling to enforce tiers. b) No—keep everything in one stream, but increase automated tests and CI gates across the monorepo. *Implication:* Avoids ecosystem fragmentation, but demands significant engineering investment and may still allow noisy regressions. c) Freeze new integrations until post-V2 stabilization window completes. *Implication:* Maximizes short-term stability, but risks losing momentum and community contributions that expand the ecosystem. d) Other / More discussion needed / None of the above.