Council Briefing

Key Deliberations

Eliza Cloud Beta → January Ramp Readiness

Cloud beta is live with ecosystem builders being onboarded for production feedback, and leadership is positioning Cloud as the default registry/registration surface before EthDenver. The Council must ensure the beta-to-ramp path prioritizes reliability, clear onboarding, and measurable adoption rather than a purely narrative launch.

What must be the single gating criterion for moving from Cloud beta to the January public ramp?

Kenk: "Eliza Cloud has entered beta phase with ecosystem builders being onboarded for production feedback" (Discord 🥇-partners, 2025-12-23).
Kenk: "A larger ramp-up is planned for January, including PR, a launch event, and engagement with coding influencers" (Discord 🥇-partners, 2025-12-23).

1Reliability threshold: error budgets/uptime plus stable streaming and deploy flows across the core builder journey.

Optimizes for Execution Excellence and long-term trust, but may delay marketing momentum if issues persist.

2Adoption threshold: minimum number of onboarded builders actively deploying agents weekly with positive NPS.

Forces real-world validation, but risks shipping with hidden reliability debt if metrics are gamed or early users are unusually tolerant.

3Revenue/tokenomics readiness: metering + buyback/burn hooks implemented and auditable before broad launch.

Addresses token-holder pressure quickly, but could compromise DX if monetization complexity precedes stability.

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

Should Cloud be positioned as the canonical agent registry (8004) immediately, or remain a best-in-class deployment platform that later federates registries?

Kenk: "Eliza Cloud is being positioned as the primary platform for agent registration ahead of EthDenver" (Discord 🥇-partners, 2025-12-23).
Kenk: "8004 mainnet is scheduled for mid-January" (Discord 🥇-partners, 2025-12-23).

1Make Cloud the canonical registration path now (Cloud-first registry).

Maximizes clarity and onboarding speed, but increases blast radius if registry semantics or auth/multi-tenancy aren’t fully hardened.

2Dual-path: Cloud offers managed registration while keeping an open spec/API for external registries from day one.

Balances Developer First and Open & Composable, but requires disciplined API governance and documentation.

3Registry-first: prioritize 8004 registry as the neutral layer; Cloud becomes one of several clients/providers.

Strengthens decentralization narrative, but may slow the ‘one obvious path’ onboarding experience for EthDenver.

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

What is the Council’s chosen ‘first builder story’ for EthDenver: deployment simplicity, cross-chain agents, or monetization/tokenomics?

Discord summary: "The Cloud launch represents the 'first real tokenomics engine' for the project" (Odilitime, Discord 🥇-partners, 2025-12-23).
Discord summary: "push to onboard agents ahead of EthDenver in mid-February" (Kenk, 2025-12-23).

1Deployment simplicity: 'ship an agent in minutes' with a stable, boring happy-path.

Aligns with Execution Excellence and Developer First, creating durable trust even if token narrative lags.

2Cross-chain capability: showcase native multi-chain operations via registry/8004 and Jeju/x402 direction.

Differentiates strongly in Web3, but risks demo fragility if infra edges are not production-grade.

3Monetization/tokenomics: Cloud as the economic engine with clear value loops for builders and holders.

May relieve community pressure, but can backfire if utility claims outpace delivered product reliability.

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

Framework Reliability: Unified Messaging, Streaming, and Plugin Hygiene

Core developers report fixes to streaming in cloud build mode and Discord plugin issues, while standardizing message handling across plugins remains a key dependency for stability and composability. The Council must decide how aggressively to enforce the unified message API and how to convert this into a measurable reliability narrative for builders.

Do we mandate a hard cutoff date for all first-party plugins to adopt the standardized message handling (Elizaos.handleMessage/messageService) before the January ramp?

Stan ⚡: "Work continues on standardizing message handling across plugins" (Discord core-devs, 2025-12-23).
Stan ⚡: "Standardize Elizaos.handleMessage across plugins - PR needs to be pushed" (Discord core-devs, 2025-12-23).

1Yes—set a firm cutoff; block releases of non-compliant first-party plugins.

Accelerates reliability and composability, but may temporarily reduce feature breadth and frustrate maintainers.

2Partial mandate—core + top 3 most-used plugins only; others follow a migration guide.

Reduces immediate risk while maintaining momentum, but leaves long-tail instability that can erode trust.

3No cutoff—keep it best-effort while focusing on Cloud onboarding and UX.

Maximizes short-term shipping speed, but risks death-by-a-thousand-inconsistencies across integrations.

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

What reliability metric should become the Council’s ‘single pane’ KPI for Execution Excellence over the next 30 days?

Stan ⚡: "Streaming issues in cloud build mode have been fixed" (Discord core-devs, 2025-12-23).
Odilitime: "Analytics for memories table is in development" (Discord core-devs, 2025-12-23).

1End-to-end agent lifecycle success rate (create → deploy → run → message) across Cloud and CLI.

Directly maps to developer value and onboarding, but requires consistent instrumentation across services.

2Streaming stability score (timeouts, partial outputs, reconnection rate) across providers and plugins.

Targets a known pain point, but may overweight one subsystem versus broader DX issues.

3Plugin compatibility index (percentage of registry plugins passing conformance tests for messaging API).

Strengthens Open & Composable, but may feel abstract to builders if not tied to real outcomes.

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

How should we operationalize ‘plugin-wrapped functionality’ into a repeatable reference pattern (especially for social/image workflows) without increasing surface area risk?

Odilitime: "Plugin-wrapped functionality is progressing, with image generation and social media preparation underway" (Discord core-devs, 2025-12-23).

1Promote a strict reference implementation (one blessed stack) and document it as the canonical pattern.

Improves DX and reduces confusion, but may slow experimentation and ecosystem diversity.

2Define a minimal interface spec + conformance tests; allow multiple implementations.

Preserves composability and ecosystem creativity while maintaining reliability guardrails.

3Keep it internal for now; use it only for flagship agents until Cloud ramp stabilizes.

Reduces near-term risk, but delays ecosystem leverage and community contributions.

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

Trust & Token Utility Narrative Under Market Stress

Discord logs show continued community frustration around token drawdown and demands for visible utility; team messaging points to Cloud as the tokenomics engine, with prior mentions of buybacks and related projects/airdrops. The Council must align product truth (what exists now) with communications (what is promised) to avoid trust erosion during the migration and Cloud launch window.

What should be the Council’s official stance on token value communication during the Cloud ramp: product-first silence, utility roadmap clarity, or explicit buyback/revenue guidance?

Community member: token holders reporting ~75% decline and asking for better token utility communication (Discord, 2025-12-22).
Odilitime: "We just launched cloud, kinda feels like our first real tokenomics engine" (Discord 🥇-partners, 2025-12-23).

1Product-first: communicate only shipped capabilities; avoid forward-looking token mechanisms until live.

Maximizes credibility and reduces regulatory/expectation risk, but may not satisfy anxious holders.

2Utility roadmap clarity: publish a concrete, time-bound utility spec (what/when/how) with disclaimers.

Restores some confidence through transparency, but creates execution pressure and public deadlines.

3Explicit economic guidance: lead with buybacks/burns/revenue loop narrative tied to Cloud usage.

May provide immediate sentiment relief, but risks reputational damage if revenue or mechanisms underdeliver.

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

Which documentation deliverable most directly increases developer trust this week: Cloud onboarding guide, unified messaging migration guide, or token utility explainer?

Stan ⚡: "Review monorepo docs to identify gaps after recent core changes" (Discord core-devs, 2025-12-23).
Discord action item: "Create clear documentation about token utility and roadmap" (Discord, 2025-12-22).

1Cloud onboarding guide with ‘golden path’ examples and troubleshooting (CLI ↔ Cloud).

Directly drives adoption and reduces support load, converting beta interest into real deployments.

2Unified messaging migration guide + plugin conformance checklist.

Reduces ecosystem fragmentation and hard-to-debug issues, improving long-term reliability.

3Token utility explainer (current utility + near-term roadmap) hosted on the official site.

Addresses community pressure, but does not by itself improve DX unless tied to actionable product flows.

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

How should we handle emergent security/trust hazards in the community channels during this launch phase (impersonators, CVEs, installation errors) without derailing engineering focus?

Discord: "Tickets BS is scammers trying to get you, ignore them" (Roman V, 2025-12-21).
Discord: "Security Alert: Mention of a CVE 10 RCE exploit discovered in n8n" (jin, 2025-12-22).

1Create a formal Security & Trust playbook: verified support channels, signed links, and rapid advisories.

Improves user safety and trust, but requires operational ownership and ongoing maintenance.

2Lightweight approach: pinned warnings + automated moderation; escalate only if exploit impacts ElizaOS directly.

Preserves engineering bandwidth, but may be insufficient if scams spike during major announcements.

3Outsource/community-led trust ops: delegate moderation and incident triage to vetted community sentinels.

Scales operational coverage quickly, but increases risk if delegation is poorly governed.

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

North Star & Strategic Context

Key Deliberations