# Council Briefing: 2025-04-10 ## 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 toward “trust through shipping” by landing core reliability upgrades (new message API, OpenAI TTS, plugin-install fixes), while unresolved v2 migration friction (API endpoint confusion, social plugins) remains the main drag on developer confidence. ## Key Points for Deliberation ### 1. Topic: V2 Reliability & DX Stabilization (CLI + Core Runtime) **Summary of Topic:** Today’s merges concentrated on hardening the operator interface (CLI) and runtime stability—directly aligned with Execution Excellence—yet field reports still signal migration confusion and endpoint breakage risks that can erode developer trust. #### Deliberation Items (Questions): **Question 1:** Should the Council declare a short-term “Stability Lock” period for v2 where only bugfixes/compatibility work land, to restore developer trust before new features expand scope? **Context:** - `ElizaOS Daily Update (Apr 10, 2025): "Bug Fixes… plugin installation priority order… CLI and startup code…"` - `elizaOS Dev Discord (2025-04-09): "users struggling to understand architectural changes" (standard; shaw explanation of v2 shift)` **Multiple Choice Answers:** a) Yes—enforce a Stability Lock (bugfixes, perf, docs, compatibility only) for a defined window. *Implication:* Improves reliability perception and reduces regressions, but may slow headline feature velocity. b) No—continue feature + fixes in parallel, but add stricter CI gates and release criteria. *Implication:* Maintains momentum while raising quality, but requires disciplined enforcement and test coverage. c) Hybrid—stability lock for CLI/API surfaces only; allow non-breaking plugin/UX features to proceed. *Implication:* Protects the critical developer path while keeping ecosystem energy high, at the cost of complexity in governance. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s preferred “single source of truth” for v2 operational usage: CLI-first workflows, REST-first workflows, or GUI-first workflows? **Context:** - `elizaOS Dev Discord (2025-04-09): "agent package moved into cli with REST API integration… agents are now database-driven" (shaw)` - `Daily report (2025-04-09.json): "Added a new message API (PR #4247)"` **Multiple Choice Answers:** a) CLI-first: treat CLI as canonical; GUI and REST are conveniences built atop it. *Implication:* Optimizes for power users and reproducibility, but can alienate new builders seeking a visual workflow. b) REST-first: treat API contracts as canonical; CLI/GUI become clients against stable endpoints. *Implication:* Strengthens composability and Cloud-readiness, but demands rigorous versioning and backward compatibility. c) GUI-first: treat the GUI as the default onboarding path; CLI/REST serve advanced use cases. *Implication:* Improves approachability and adoption, but risks masking underlying complexity and delaying infra hardening. d) Other / More discussion needed / None of the above. **Question 3:** How aggressively should we remove or deprecate legacy v1 patterns during the v2 transition to reduce confusion without breaking builders? **Context:** - `elizaOS Discord (2025-04-09): "Some users reported reverting to v1 due to functionality issues in v2"` - `elizaOS Discord (2025-04-09): "Which version… most stable? Version 0.25.9" (notorious_d_e_v)` **Multiple Choice Answers:** a) Aggressive: rapid deprecations and strict migration guidance; minimize dual-support. *Implication:* Reduces long-term maintenance burden, but risks backlash and short-term ecosystem fragmentation. b) Conservative: extended dual-support with compatibility layers and clear “best known stable” guidance. *Implication:* Protects builders and reduces churn, but increases engineering overhead and slows convergence. c) Selective: deprecate only the most confusing/unsafe v1 patterns; keep a compatibility runtime for critical plugins. *Implication:* Balances stability and progress, but requires careful curation of what remains supported. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Messaging + Social Surface Reliability (Message API, TTS, Telegram/Twitter) **Summary of Topic:** Messaging capabilities expanded (new message API, buttons, TTS), but social integrations—especially X/Twitter interactions—remain a high-visibility failure mode that pushes users back to older versions and undermines the flagship-agent narrative. #### Deliberation Items (Questions): **Question 1:** Should we prioritize a “golden path” reference implementation for social agents (X + Telegram) that is tested end-to-end and version-pinned, even if it slows v2 feature breadth? **Context:** - `elizaOS Discord (2025-04-09): "Twitter interactions functionality not working properly in v2… workaround… TWITTER_SEARCH_ENABLE=true" (notorious_d_e_v)` - `ElizaOS Daily Update (Apr 10, 2025): "Added support for message buttons in the Telegram plugin (PR #4187)"` **Multiple Choice Answers:** a) Yes—ship a golden-path repo (pinned versions, CI, example characters, deployment recipes). *Implication:* Directly advances Developer First + Trust Through Shipping, at the cost of narrower short-term scope. b) No—keep examples lightweight; focus on core framework and let the community iterate on social stacks. *Implication:* Maximizes framework velocity, but leaves the most visible user experience to chance. c) Partial—golden path for Telegram + REST first; X/Twitter remains “best-effort” until API access stabilizes. *Implication:* Improves reliability where controllable, but risks perception that ElizaOS can’t reliably operate on X. d) Other / More discussion needed / None of the above. **Question 2:** What is the Council’s stance on Twitter/X integration strategy: scraping, official API v2, or pluggable abstraction supporting both? **Context:** - `elizaOS Discord (2025-04-09): "shared a custom Twitter client fork using API access instead of scraping" (notorious_d_e_v)` - `elizaOS Discord (2025-04-08): multiple reports of Twitter plugin issues; users revert to v1` **Multiple Choice Answers:** a) API v2 only: standardize on official access and document requirements (paid tiers, limits). *Implication:* Maximizes reliability and compliance, but raises the barrier for hobbyists and global builders. b) Scraping only: keep zero-cost entry and accept periodic breakage as operational reality. *Implication:* Improves accessibility, but repeatedly damages trust and increases maintenance firefighting. c) Pluggable abstraction: support both backends with clear reliability tiers and fallbacks. *Implication:* Balances accessibility and robustness, but increases complexity and test surface area. d) Other / More discussion needed / None of the above. **Question 3:** How should we define “message API” success criteria before calling it stable for Cloud and external integrations (latency, idempotency, versioning, error semantics)? **Context:** - `ElizaOS Daily Update (Apr 10, 2025): "Developed a new messaging API (PR #4247)"` - `elizaOS Dev Discord (2025-04-09): "message endpoints returning 404 errors despite agent showing active status" (Titan | Livepeer-Eliza.com)` **Multiple Choice Answers:** a) Contract-first: publish OpenAPI spec + compatibility policy; stability is measured by contract adherence. *Implication:* Enables composable ecosystems and Cloud readiness, but requires disciplined API governance. b) Performance-first: define SLOs (p95 latency, uptime) and focus on operational metrics over formal specs. *Implication:* Improves real-world reliability quickly, but can leave integrators guessing without clear contracts. c) Iteration-first: keep API “beta” until social + GUI + CLI all converge on consistent behavior. *Implication:* Reduces premature lock-in, but prolongs uncertainty for developers building production integrations. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Composable Ecosystem Governance: Registries, Reputation, and Coordination **Summary of Topic:** Community discourse is converging on composability primitives (agent registry + trust scores) and DAO operational infrastructure (reputation tracking, working circles). This is strategically aligned with a decentralized AI economy, but needs clear boundaries between open community governance and core platform stewardship. #### Deliberation Items (Questions): **Question 1:** Should ElizaOS bless an “official Agent Registry” standard (Agent Cards + trust graph), or keep it as an ecosystem experiment until Cloud launch stabilizes? **Context:** - `elizaOS Discord 🥇-partners (2025-04-09): "Eliza agent registry… JSON 'Agent Cards'… trust scores" (DorianD; Odilitime: "likely to happen")` - `elizaOS Discord (2025-04-08): repeated discussion of registry + trust scores` **Multiple Choice Answers:** a) Bless it now: publish an official spec and reference implementation. *Implication:* Accelerates ecosystem interoperability and positions ElizaOS as the coordination layer, but creates long-term maintenance obligations. b) Defer: encourage experiments, but avoid an official standard until Cloud and v2 stabilize. *Implication:* Prevents overcommitting while reliability work continues, but may allow competing standards to fragment the ecosystem. c) Dual-track: publish a minimal “Agent Card v0” schema only; leave trust scoring to third parties for now. *Implication:* Bootstraps composability with low lock-in, while keeping contentious reputation logic out of core. d) Other / More discussion needed / None of the above. **Question 2:** How should the DAO reputation system interface with the product roadmap: governance-only incentives, or directly powering developer discovery (e.g., plugin trust, agent trust)? **Context:** - `elizaOS Discord dao-organization (2025-04-09): "reputation/contribution tracking… scores GitHub contributions… generates reports" (jin)` - `elizaOS Discord 🥇-partners (2025-04-09): registry trust scores proposal (DorianD)` **Multiple Choice Answers:** a) Governance-only: keep reputation internal to DAO rewards and roles. *Implication:* Minimizes manipulation risk in product surfaces, but misses a chance to solve discovery and trust at scale. b) Product-integrated: use reputation signals to rank plugins/agents and guide defaults. *Implication:* Improves safety and DX through trust signals, but creates high-stakes incentives and potential gaming. c) Layered: separate “contribution reputation” from “runtime reliability reputation,” with different sources and audits. *Implication:* Enables useful trust signals while reducing incentive distortion, but increases system complexity. d) Other / More discussion needed / None of the above. **Question 3:** What autonomy boundary should be formalized between ElizaDAO initiatives and ElizaLabs/Studios so alignment does not become dependency? **Context:** - `elizaOS Discord dao-organization (2025-04-09): "coordination with ElizaLabs and ElizaStudios while maintaining the DAO's autonomy ('Eliza is Ours')"` - `elizaOS Discord dao-organization (2025-04-09): "need for DAO treasury independence" (yikesawjeez; others)` **Multiple Choice Answers:** a) Strong independence: separate treasury + roadmap; coordinate only via public interfaces and proposals. *Implication:* Protects decentralization narrative, but may duplicate efforts and slow critical execution alignment. b) Tight coupling: DAO acts as execution arm for Labs priorities with shared planning and budgets. *Implication:* Maximizes shipping coherence, but risks centralization optics and reduces community initiative. c) Federated model: shared quarterly goals and interfaces, independent execution and treasury decisions within those bounds. *Implication:* Creates alignment without dependency, but requires mature rituals and explicit conflict-resolution mechanisms. d) Other / More discussion needed / None of the above.