Council Briefing

Key Deliberations

ElizaOS Cloud Launch: Stabilization and First-Impression Reliability

Cloud has launched and builders are deploying agents, but early friction (login errors, username-null deploy failures, file upload constraints) threatens the developer-first narrative; execution excellence now means fixing the “day-0 papercuts” faster than new features ship.

What is the Council’s minimum “Cloud Launch Stability Bar” (SLO + top bug list) required before we amplify marketing again?

Discord 2025-12-26: "Some users reported deployment errors (username null error)" (DorianD)
Discord 2025-12-26: "Some users experiencing application errors when logging into ElizaCloud" (DorianD)

1Define and publish SLOs (login success %, deploy success %, first-response latency) and gate outbound marketing until met for 72 hours.

Signals execution excellence and reduces churn, but slows narrative recovery in the short term.

2Run marketing in parallel, but focus messaging on “public beta” and route users to a known-issues + workaround page.

Maintains momentum while acknowledging imperfections, but risks reinforcing the “unfinished” perception.

3Do not publish SLOs; prioritize rapid hotfix cadence and rely on community showcases to outweigh rough edges.

Moves fastest, but weakens trust-through-shipping if failures remain invisible and recurring.

4Other / More discussion needed / None of the above.

Which Cloud friction should be treated as a “red-alert” reliability breach vs. normal beta backlog?

Discord 2025-12-26: "Resolve agent deployment error with username null" (action item)
Discord 2025-12-24: "For file uploads we've set a limit of 50MB" (Borko)

1Any auth/login failures and deploy-blocking errors are red-alert; everything else (uploads, UX polish) is backlog.

Protects conversion funnel and developer trust, aligning with execution excellence.

2Treat deploy-blockers and data ingestion limits (uploads/knowledge) as red-alert because they constrain real agent use.

Improves real workloads quickly, but may leave identity problems undermining adoption.

3Only security/privacy incidents are red-alert; functional bugs are acceptable during rapid iteration.

Maximizes speed, but conflicts with the “most reliable” North Star and can damage DX.

4Other / More discussion needed / None of the above.

How should we structure a “builder showcase pipeline” to turn early agents into credible proof of platform value (without amplifying low-signal meme deployments)?

Discord 2025-12-26: "Create a process for ElizaCloud developers to showcase their projects" (satsbased)
Daily Summary 2025-12-26: "Various agents being created including themed agents (Satoshi, Pepe, Trump)"

1Curate weekly “Council Picks” with acceptance criteria (utility, reliability, open-source template, reproducible deployment).

Improves signal quality and reinforces developer-first positioning, but requires editorial effort.

2Open a public gallery and rank by usage metrics + upvotes; let the market of builders decide what matters.

Scales community-driven discovery, but may overweight memes and underweight serious infra demos.

3Focus only on flagship reference agents until Jeju is ready; postpone community showcase to avoid noise.

Keeps narrative tight, but sacrifices ecosystem growth and third-party validation when it’s most needed.

4Other / More discussion needed / None of the above.

Token Migration Fallout: Trust, Liquidity Fragmentation, and Exchange Risk

Migration mechanics (snapshot eligibility, wallet constraints) and liquidity fragmentation are driving confusion and reputational drag, while delisting fears create time pressure; we need a single authoritative narrative and an operational “migration success program” to restore builder and holder confidence.

What corrective action best restores trust after a snapshot-based migration that “split liquidity and caused confusion,” especially for exchange users?

Discord 2025-12-26: "The migration used a snapshot approach which split liquidity and caused confusion, especially for exchange users" (averma)
Discord 2025-12-25: "Only tokens held at the November 11th snapshot can be migrated, and only from the wallet that held them at that time" (Alexei)

1Publish an immutable Migration Postmortem + remediation plan (exchange playbook, eligibility checker, support SLAs) and pin it across channels.

Converts chaos into credibility and aligns with trust-through-shipping via transparent ops.

2Extend migration tooling with optional verified exceptions (e.g., constrained wallets) via a manual review queue.

Increases success rate, but adds operational burden and potential social engineering risk.

3Freeze scope: keep rules strict, focus on product shipping, and let market dynamics resolve the narrative over time.

Reduces ops complexity, but may cement distrust and amplify delisting/abandonment risk.

4Other / More discussion needed / None of the above.

Given community concern about potential Korean exchange delistings in January, what is the Council’s immediate risk posture?

Discord 2025-12-25: "Significant concern about potential delisting from Korean exchanges (Bithumb, Coinone, and Korbit) in January"

1Treat as a critical-path operational risk: assign an exchange-compliance war room and publish weekly status updates.

Maximizes chance of retention and reduces rumor-driven panic, but consumes leadership bandwidth.

2Pursue partial mitigation: prepare contingency liquidity routes and communication templates, but avoid frequent public updates.

Reduces panic signaling while still preparing, but may be seen as evasive if events unfold.

3Do nothing special: prioritize Cloud adoption; assume exchange risk is secondary and transient.

Keeps focus on building, but a delisting shock could undermine token coordination narrative.

4Other / More discussion needed / None of the above.

What should be the canonical public framing of token value accrual in the near term while Jeju utility is pending?

Discord 2025-12-24: "Cloud revenue (but not yield) will be used for ElizaOS token buybacks" (Odilitime)
Discord 2025-12-24: "additional token utility is planned when Jeju is released" (Borko)

1Lead with measurable Cloud revenue → buybacks, and explicitly label Jeju utility as staged roadmap with dates/criteria.

Grounds value in observable metrics and reduces speculative ambiguity.

2De-emphasize buybacks; emphasize token as coordination primitive for a decentralized agent economy (Jeju/x402) to avoid “financial product” optics.

Better long-term narrative alignment, but may not satisfy near-term holder anxiety.

3Keep messaging flexible: mention buybacks and future utility without committing to specifics until Jeju is ready.

Reduces promise risk, but fuels distrust because ambiguity is currently the core complaint.

4Other / More discussion needed / None of the above.

Identity, Streaming, and Core Reliability: The DX Trust Layer

Multiple signals point to “trust layer” gaps—broken streaming due to dependency mismatch, need for unified SSO, and bun-only constraints—indicating that developer experience now depends on rigorous integration discipline and clear platform contracts.

Should the Council prioritize a unified SSO/JWT identity plane as a prerequisite for scaling Cloud and Jeju, even if it delays feature throughput?

core-devs 2025-12-26: "Implement custom SSO solution to unify authentication and identity" (Odilitime)
GitHub PR list (month): "feat(auth): implement JWT authentication and user management" (standujar, PR #6200, open)

1Yes—identity is the backbone: standardize on JWT/SSO now to prevent future fragmentation across Cloud, plugins, and cross-chain services.

Improves composability and security posture, enabling multi-tenant and ecosystem integrations.

2Partially—ship a minimal SSO for Cloud UI first, defer full ecosystem identity until Jeju milestones are clearer.

Balances speed and structure, but risks accruing identity tech debt and inconsistent auth flows.

3No—keep auth simple in the near term; focus on reliability and agent features, revisit identity after product-market signal strengthens.

Maximizes short-term shipping, but may block enterprise/dev adoption and complicate cross-chain coordination.

4Other / More discussion needed / None of the above.

How do we prevent “streaming broken due to wrong dependencies” from recurring across core and plugins—what governance mechanism do we enforce?

core-devs 2025-12-26: "Streaming functionality broken in the core due to wrong dependencies"
core-devs 2025-12-26: "Fix OpenAI streaming functionality (PR #22)" (Stan ⚡)

1Introduce a streaming compatibility test suite (core + plugin matrix) that blocks releases unless passing.

Strong execution-excellence enforcement; may slow merges but reduces regressions dramatically.

2Add stricter dependency pinning and automated dependency-diff reviews for streaming-related packages only.

Targets the failure mode with lower overhead, but may miss integration regressions beyond deps.

3Rely on community reports and rapid hotfixes; prioritize velocity over preventative process.

Maintains speed, but undermines “most reliable framework” promise at the exact moment Cloud is public.

4Other / More discussion needed / None of the above.

Given “bun required” constraints, what is the Council’s stance on widening tooling compatibility vs. doubling down on bun-first performance?

Discord 2025-12-26 (coders): "Is it possible to use npm instead of bun?" → "nope" (sayonara)

1Commit to bun-first and document it clearly with fast paths for common environments; treat compatibility requests as long-term.

Keeps stack coherent and high-performance, but narrows the contributor funnel.

2Support npm as a first-class alternative within a defined subset (CLI + core), keeping bun optional for power users.

Improves DX inclusivity, but increases CI surface area and risk of “works on my machine” failures.

3Abstract tooling entirely via containerized dev environments and “one-command” setup; underlying package manager becomes irrelevant.

Best long-term DX, but requires significant investment and discipline in dev-env maintenance.

4Other / More discussion needed / None of the above.

North Star & Strategic Context

Key Deliberations