# Council Briefing: 2025-12-19 ## 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 - Council attention is split between execution excellence in the runtime (streaming + provider performance hardening) and a rising legitimacy risk from token migration confusion and community distrust that threatens the Cloud launch narrative. ## Key Points for Deliberation ### 1. Topic: Runtime Reliability: Streaming & Provider Performance Contracts **Summary of Topic:** Core shipped a major streaming enhancement (merged PR #6212), while an open refactor (PR #6263) proposes parallel provider execution with timeouts—signaling a push toward reliability but exposing an unresolved contract: are providers allowed to hit live APIs or must they be cache-only? #### Deliberation Items (Questions): **Question 1:** What is the Council’s official provider contract for the Framework: cache-only data access, best-effort live calls, or a tiered approach with strict time budgets? **Context:** - `core-devs: Odilitime argued providers should never make API calls and should only read from caches; Stan proposed parallel execution with configurable timeout (default 1s) and warnings for slow providers (PR #6263).` **Multiple Choice Answers:** a) Cache-only contract: providers must not perform network I/O during the critical pipeline; live fetching belongs in tools/actions with explicit UX. *Implication:* Maximizes determinism and latency predictability, but requires more developer education and clearer tool/provider boundaries. b) Best-effort live calls allowed: providers may call APIs, but must respect global timeouts and fail gracefully. *Implication:* Improves out-of-the-box usefulness, but risks tail latency, rate-limit failures, and inconsistent agent behavior across environments. c) Tiered model: default providers are cache-only; an opt-in 'networked provider' class is allowed with explicit budget, circuit-breakers, and observability. *Implication:* Balances DX and reliability, but adds complexity to docs, interfaces, and test expectations. d) Other / More discussion needed / None of the above. **Question 2:** How aggressive should the runtime be in enforcing performance budgets (e.g., aborting the pipeline at 1s) versus degrading gracefully with partial provider results? **Context:** - `core-devs: Agreement formed around a configurable timeout (default 1s) that would abort the pipeline if providers take too long; add warnings for slow providers.` **Multiple Choice Answers:** a) Hard-fail budget: abort the pipeline when provider SLA is violated, surface a clear error and guidance. *Implication:* Forces ecosystem discipline and predictable UX, but may feel brittle during early plugin experimentation. b) Soft-degrade: continue with partial provider data, emit warnings/telemetry, and let the agent respond with reduced context. *Implication:* Preserves continuity for users, but can hide systemic performance debt and complicate debugging. c) Adaptive mode: hard-fail in Cloud/production presets, soft-degrade in local/dev presets. *Implication:* Aligns with Developer First while protecting Cloud reliability, at the cost of configuration surface area. d) Other / More discussion needed / None of the above. **Question 3:** What is the fastest path to making streaming feel 'real' end-to-end (Framework → Cloud → Client) given remaining UI rendering issues? **Context:** - `Discord 2025-12-16: Stan: "Everything works in the monorepo, but for Actions the UI still displays the text all at once instead of streaming it."` - `GitHub 2025-12-18: PR #6212 'feat: enhance streaming support in text generation' merged.` **Multiple Choice Answers:** a) Prioritize client/UI correctness: fix Actions UI streaming rendering before adding more streaming endpoints. *Implication:* Delivers visible user value quickly and boosts trust, but may delay backend refactors. b) Prioritize Cloud transport: ensure Cloud streaming is stable and observable, accept temporary UI quirks with clear roadmap. *Implication:* Hardens the platform layer for scale, but risks perception that streaming is still 'broken'. c) Ship a 'Streaming MVP preset': known-good model/provider + UI path, document limitations, expand coverage iteratively. *Implication:* Creates a reliable demo lane for credibility, while buying time to fix long-tail streaming paths. d) Other / More discussion needed / None of the above. --- ### 2. Topic: Token Migration & Exchange Coordination: Trust Incident Containment **Summary of Topic:** Migration confusion across exchanges (e.g., Bithumb vs Kraken handling) and user reports of a "disastrous" swap are creating a reputational gravity well; without crisp, multilingual guidance and verifiable exchange communications, the Cloud launch risks being drowned by governance noise. #### Deliberation Items (Questions): **Question 1:** What is the Council’s containment strategy for migration-related distrust: public evidence releases, partner-by-partner escalation, or a redesigned self-serve migration path? **Context:** - `Discord 2025-12-17: "Different exchanges (Bithumb and Kraken) are handling the AI16Z to ELIZAOS token swap differently, causing confusion."` - `Discord 2025-12-18 discussion: users described migration as "disastrous" and "dilution."` **Multiple Choice Answers:** a) Publish verifiable timelines and receipts: snapshot rules, exchange contact logs (where allowed), and a single canonical FAQ. *Implication:* Restores credibility through transparency, but may expose sensitive partner dynamics and requires careful compliance review. b) Escalate privately with exchanges first, then issue short public updates with milestones (no receipts). *Implication:* Preserves partner relationships, but may fail to satisfy communities demanding proof and could prolong distrust. c) Invest in productized migration v2: wallet-agnostic claims, clearer UX, and safer recovery flows for edge cases (e.g., Tangem/WalletConnect gaps). *Implication:* Reduces future incidents and support load, but is slower and could miss the December execution window. d) Other / More discussion needed / None of the above. **Question 2:** How should the Council address Korean community concerns about marginalization while maintaining operational focus on shipping? **Context:** - `Discord 2025-12-18 discussion: "Several Korean users expressed feeling marginalized by the project leadership."` - `Discord 2025-12-17: requests for evidence of communications with Bithumb regarding snapshot timing.` **Multiple Choice Answers:** a) Establish a KR liaison cell: bilingual moderators + a weekly KR-specific migration bulletin and office hours. *Implication:* Directly reduces friction and misinformation, but requires staffing and consistent follow-through. b) Treat it as a universal comms gap: ship one global migration playbook and translate it, without special programs. *Implication:* Scales better, but may not repair perceived exclusion or handle KR exchange-specific realities fast enough. c) Defer community repairs until after Cloud launch, focusing all bandwidth on shipping and stability. *Implication:* Maximizes near-term delivery velocity, but increases the chance that legitimacy erosion undermines launch impact. d) Other / More discussion needed / None of the above. **Question 3:** What is the Council’s posture on exchange-driven swap discrepancies: do we accept exchange snapshot sovereignty, or provide compensatory mechanisms where feasible? **Context:** - `Discord 2025-12-17: Serikiki explained Kraken would not give tokens to users who sold after the snapshot; confusion persists due to exchange differences.` **Multiple Choice Answers:** a) Accept exchange sovereignty: reinforce 'self-custody recommended' and provide education; no compensation. *Implication:* Clear boundaries and lower liability, but may intensify backlash from affected users. b) Compensate selectively: create an appeals process for provable edge cases (time-bounded, capped). *Implication:* Can defuse major grievances, but introduces fraud risk and sets precedent for future claims. c) Offer technical alternatives: enable claims from more wallet types / manual verification paths instead of compensation. *Implication:* Improves fairness via tooling, but requires engineering effort and careful security controls. d) Other / More discussion needed / None of the above. --- ### 3. Topic: Developer-First Delivery: Plugin Integration Friction & Documentation Debt **Summary of Topic:** Builders are hitting friction integrating new plugins (Starknet type mismatches, missing handlers, unclear CLI flows) while major ecosystem PRs (Discord plugin) sit large and stale; combined with an open-ended 'Docs' issue (#6264), this threatens the 'Developer First' promise at the exact moment Cloud onboarding must be crisp. #### Deliberation Items (Questions): **Question 1:** Should the Council enforce stricter compatibility gates for plugins (types, runtime interfaces, action registration) before they are promoted as 'official'? **Context:** - `coders 2025-12-18: FenrirFawks hit TypeScript incompatibilities between AgentRuntime and IAgentRuntime; missing handler for DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN.` - `core-devs 2025-12-18: Decision to pin @elizaos/* versions in plugins rather than using latest (Stan).` **Multiple Choice Answers:** a) Yes—introduce an 'official plugin bar' with CI matrices against supported Framework versions and required type checks. *Implication:* Improves reliability and trust, but raises contributor friction and may slow ecosystem growth. b) Partially—keep community plugins flexible, but label compatibility explicitly and provide a 'known good' lockfile/pinning guidance. *Implication:* Balances openness with clarity, but still leaves users exposed to rough edges if labels are ignored. c) No—prioritize speed and experimentation; rely on semver + community support to smooth edges. *Implication:* Maximizes experimentation, but conflicts with the Monthly Directive’s execution excellence and Cloud reliability goals. d) Other / More discussion needed / None of the above. **Question 2:** How should we handle the large, aging Discord plugin PR (66 commits, ~3 weeks open): merge fast with follow-up fixes, or split/refactor before merging? **Context:** - `Discord 2025-12-17: "Discord Plugin: Large PR with 66 commits is ready to merge after being open for three weeks" (Odilitime).` **Multiple Choice Answers:** a) Merge now with a rollback plan and immediate patch sprint (48–72h) to stabilize in main. *Implication:* Unblocks ecosystem velocity quickly, but increases short-term breakage risk. b) Split into smaller PRs: isolate risky refactors vs safe fixes, then merge incrementally. *Implication:* Reduces blast radius and improves review quality, but delays shipping and may stall contributors. c) Hold until Cloud launch stabilizes: freeze non-critical integrations to protect execution excellence. *Implication:* Protects the launch window, but harms Developer First momentum and leaves important integration work stranded. d) Other / More discussion needed / None of the above. **Question 3:** What documentation artifact should be treated as the single source of truth for December: migration playbook, Cloud onboarding path, or plugin/provider best practices? **Context:** - `GitHub 2025-12-18: Issue #6264 titled 'Docs' opened with no comments.` - `Discord 2025-12-18: Freya requested clearer migration documentation; Odilitime requested documenting provider best practices (avoid API calls, use caching).` **Multiple Choice Answers:** a) Migration playbook first: reduce support load and reputational harm; Cloud docs can follow. *Implication:* Stabilizes community trust, but may slow developer adoption if Cloud onboarding remains unclear. b) Cloud onboarding first: make the happy path irresistible and reliable; handle migration via targeted FAQs. *Implication:* Accelerates platform adoption, but risks the narrative being dominated by unresolved migration complaints. c) Provider/plugin best practices first: prevent performance and compatibility issues from multiplying as adoption grows. *Implication:* Improves framework quality at scale, but may not address the most visible user pain points immediately. d) Other / More discussion needed / None of the above.