Council Briefing

Strategic Deliberation
▶North Star & Strategic Context

North Star & Strategic Context



This file combines the overall project mission (North Star) and summaries of key strategic documents for use in AI prompts, particularly for the AI Agent Council context generation.

Last Updated: December 2025

---

North Star: To build the most reliable, developer-friendly open-source AI agent framework and cloud platform—enabling builders worldwide to deploy autonomous agents that work seamlessly across chains and platforms. We create infrastructure where agents and humans collaborate, forming the foundation for a decentralized AI economy that accelerates the path toward beneficial AGI.

---

Core Principles: 1. **Execution Excellence** - Reliability and seamless UX over feature quantity 2. **Developer First** - Great DX attracts builders; builders create ecosystem value 3. **Open & Composable** - Multi-agent systems that interoperate across platforms 4. **Trust Through Shipping** - Build community confidence through consistent delivery

---

Current Product Focus (Dec 2025):
  • **ElizaOS Framework** (v1.6.x) - The core TypeScript toolkit for building persistent, interoperable agents
  • **ElizaOS Cloud** - Managed deployment platform with integrated storage and cross-chain capabilities
  • **Flagship Agents** - Reference implementations (Eli5, Otaku) demonstrating platform capabilities
  • **Cross-Chain Infrastructure** - Native support for multi-chain agent operations via Jeju/x402


    • ---

    ElizaOS Mission Summary: ElizaOS is an open-source "operating system for AI agents" aimed at decentralizing AI development. Built on three pillars: 1) The Eliza Framework (TypeScript toolkit for persistent agents), 2) AI-Enhanced Governance (building toward autonomous DAOs), and 3) Eliza Labs (R&D driving cloud, cross-chain, and multi-agent capabilities). The native token coordinates the ecosystem. The vision is an intelligent internet built on open protocols and collaboration.

    ---

    Taming Information Summary: Addresses the challenge of information scattered across platforms (Discord, GitHub, X). Uses AI agents as "bridges" to collect, wrangle (summarize/tag), and distribute information in various formats (JSON, MD, RSS, dashboards, council episodes). Treats documentation as a first-class citizen to empower AI assistants and streamline community operations.
    ▶Daily Strategic Focus
    The program is absorbing fallout from a confusing token migration (eligibility, scams, exchange risk) while needing to re-anchor legitimacy by making Cloud the tangible reliability-and-revenue engine the market can understand.
    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.

    Key Deliberations

    Token Migration Integrity + Exchange Risk Containment
    Community trust is being eroded by migration eligibility constraints (snapshot + original wallet), perceived unfairness, and active scam attempts; Korean exchange delisting risk introduces a hard near-term deadline that could amplify reputational damage.
    Q1
    Do we treat the November 11 snapshot + original-wallet restriction as immutable protocol law, or introduce an exception process to prevent stranded holders and reputational bleed?
    • Alexei (Discord, 2025-12-25): "You can only migrate tokens held at the time of the November 11th snapshot, and only from the wallet that held them at that time."
    • Issue #6211 (GitHub): Tangem snapshot wallet cannot connect; user requests an official safe method due to impersonators.
    1Keep rules immutable; publish a definitive, cryptographically grounded explanation and refuse exceptions.
    Maximizes perceived fairness and security consistency, but may strand legitimate users and prolong hostility.
    2Implement a narrow exception path (manual verification/attestations) for non-connectable snapshot wallets (e.g., Tangem).
    Reduces stranded holders and improves trust, but adds operational burden and social-engineering attack surface.
    3Extend migration with a new mechanism (e.g., secondary snapshot or claim contract) to reduce edge cases broadly.
    Best user outcome, but highest technical/legal complexity and could be perceived as moving goalposts.
    4Other / More discussion needed / None of the above.
    Q2
    What is the Council’s stance on the Korean exchange delisting threat—do we prioritize compliance/relationship management over shipping velocity in the next two weeks?
    • Discord (2025-12-25): "Significant concern about potential delisting from Korean exchanges (Bithumb, Coinone, and Korbit) in January."
    • Odilitime (Discord, 2025-12-25): Migration partly needed because "many exchanges won't support token2022."
    1Make exchange retention the top priority: dedicate a strike team to documentation, attestations, and direct exchange coordination.
    Stabilizes near-term distribution and sentiment, but risks slowing Cloud and framework milestones.
    2Maintain balanced priority: allocate limited resources to exchange needs while continuing Cloud stabilization and Jeju readiness.
    Protects product momentum, but may be insufficient to avert delisting if timelines are strict.
    3Deprioritize exchange politics: focus on product usage and decentralization; accept delisting as temporary collateral damage.
    Signals principled focus on mission, but could cause acute liquidity loss and narrative collapse.
    4Other / More discussion needed / None of the above.
    Q3
    How aggressively should we respond to scam activity and misinformation in support channels to restore trust-through-shipping?
    • Serikiki (Discord, 2025-12-25): warned about scam DMs and urged official ticket system.
    • Action item (Discord, 2025-12-25): "Fix issues with the migration helper bot providing incorrect information."
    1Hard lockdown: temporarily restrict DMs/support surfaces, force all migration support through signed/verified channels.
    Strongly reduces scams, but increases friction and support load during a critical window.
    2Targeted hygiene: fix the helper bot, add pinned canonical migration FAQ, and deploy verified support roles + warnings.
    Improves safety with manageable disruption; relies on fast execution and moderator coverage.
    3Minimal intervention: rely on community self-policing and occasional staff clarifications.
    Lowest effort, but likely prolongs confusion and amplifies reputational damage.
    4Other / More discussion needed / None of the above.
    Cloud as the Tokenomics Engine + Strategic User Acquisition
    Eliza Cloud is positioned as the first credible value-accrual mechanism (revenue-funded buybacks), and a proposed Babylon points-game integration could migrate ~350,000 users—if the Council can ensure reliability, onboarding clarity, and measurable conversion.
    Q1
    Do we anchor the public narrative on Cloud revenue buybacks now, or wait until Jeju adds additional token utility to avoid over-promising?
    • Odilitime (Discord, 2025-12-24): "Cloud revenue (but not yield) will be used for ElizaOS token buybacks."
    • Borko (Discord, 2025-12-24): "additional token utility is planned when Jeju is released."
    1Go public immediately with a precise, auditable buyback policy and reporting cadence.
    Can stabilize sentiment fast, but invites scrutiny and backlash if execution metrics lag.
    2Soft-launch messaging: present buybacks as one component, emphasize product usage and reliability first.
    Reduces reputational risk while building credibility, but may not satisfy urgent token-holder anxiety.
    3Hold messaging until Jeju utility ships; avoid token focus in the near term.
    Minimizes immediate overhang of expectations, but cedes narrative control during the crisis.
    4Other / More discussion needed / None of the above.
    Q2
    Should Babylon integration (points game using Cloud for inference/auth) be treated as a top-tier growth wedge even if it diverts engineering attention from core framework polish?
    • Shaw (Discord core-devs, 2025-12-25): points game could use Cloud for inference/auth, "potentially migrating 350,000 users".
    • Monthly Directive: "launch ElizaOS Cloud, stabilize flagship agents, and build developer trust through reliability."
    1Yes—prioritize Babylon-to-Cloud migration as the primary January growth mission and instrument conversion metrics.
    Could rapidly validate Cloud and tokenomics, but risks reliability regressions if rushed.
    2Phase it—ship a minimal integration for authentication first, inference second, only after Cloud stability SLOs are met.
    Balances growth with execution excellence; may reduce the headline impact of the integration.
    3Defer—focus on developer-first Cloud onboarding and flagship agents as the canonical proof before consumer-scale games.
    Strengthens foundational credibility, but delays the largest near-term user influx opportunity.
    4Other / More discussion needed / None of the above.
    Q3
    What Cloud launch posture best aligns with 'Trust Through Shipping'—beta-with-builders now or a coordinated January PR/event push after hardening?
    • Discord (2025-12-23): "Eliza Cloud has entered beta phase with ecosystem builders being onboarded for production feedback."
    • Discord (2025-12-23): "A larger ramp-up is planned for January, including PR, a launch event, and engagement with coding influencers."
    1Accelerate: broaden beta immediately to convert urgency into adoption momentum.
    May win mindshare quickly, but amplifies risk of visible failures during heightened attention.
    2Harden first: keep beta limited, fix onboarding/docs/UX, then execute the January public ramp.
    Aligns with execution excellence and developer trust, but reduces immediate narrative relief.
    3Dual-track: limited beta continues while a separate 'launch candidate' branch is stabilized for the event.
    Maximizes learning and readiness, but increases coordination overhead and release complexity.
    4Other / More discussion needed / None of the above.
    Execution Excellence Signal: Docs, Support Reliability, and Visible Shipping Cadence
    Despite strong December engineering output, the latest daily GitHub signal shows a momentary stall (0 PRs/issues Dec 25–26), while user-facing pain (outdated docs, migration bot misinformation, CI billing failures) threatens the project's core principle: reliability over feature quantity.
    Q1
    How should the Council respond to the optics of 'no visible repo activity' during a reputational crisis—do we change how we communicate cadence and work-in-progress?
    • GitHub daily (Dec 25-26, 2025): "0 new pull requests... 0 new issues... 0 active contributors" in elizaos/eliza.
    • Discord (2025-12-25): community frustration about "communication issues and unfulfilled promises."
    1Publish a daily ship log (Cloud + framework + migration ops) across GitHub/X/Discord to make progress legible.
    Improves trust via transparency, but increases comms overhead and requires disciplined, accurate reporting.
    2Stay quiet on cadence; focus purely on shipping and let releases speak for themselves.
    Reduces narrative risk from premature claims, but may worsen uncertainty and rumor-driven sentiment.
    3Move work into public RFCs and issue-driven execution so community can track milestones, not chatter.
    Strengthens developer-first posture and composability, but requires process changes and moderation.
    4Other / More discussion needed / None of the above.
    Q2
    What is the minimum documentation package required this week to restore 'Developer First' confidence (especially around migration, Cloud, and token value accrual) without drifting into marketing?
    • Stan (Discord, 2025-12-24): "outdated information in the monorepo documentation" and began updating it.
    • Action items (Discord, 2025-12-25): "Create clearer documentation about token utility and buyback mechanism"; "Make project roadmap and updates more publicly accessible beyond Discord."
    1Ship a 'Single Source of Truth' portal: Migration FAQ + Cloud onboarding + Tokenomics (buyback policy, disclosures) + Roadmap links.
    Maximizes clarity and reduces support load, but requires tight alignment and review to avoid contradictions.
    2Focus only on operational docs: migration eligibility, wallet edge cases, security/scam warnings, and Cloud quickstart.
    Addresses the hottest fires quickly, but leaves token value narrative fragmented.
    3Prioritize developer docs only (APIs, examples, plugins); treat token docs as separate community comms later.
    Strengthens technical credibility, but may be perceived as evasion by affected holders.
    4Other / More discussion needed / None of the above.
    Q3
    Which reliability debt must be burned down immediately to align Cloud launch with 'Execution Excellence'—CI stability, streaming/message handling consistency, or Cloud UX/onboarding?
    • Discord (2025-12-24): "GitHub Actions: job failure... Claude billing needing a top-up."
    • Discord (2025-12-23): "Work continues on standardizing message handling across plugins."
    1CI stability first: eliminate flaky pipelines and billing-related failures so shipping cadence is dependable.
    Improves velocity and confidence across all teams, but may not directly address user-facing confusion.
    2Messaging/streaming consistency first: standardize handleMessage and streaming paths to reduce cross-plugin breakage.
    Reduces runtime bugs and improves agent UX, strengthening the framework’s core promise.
    3Cloud UX/onboarding first: tighten website, docs, and flows (auth, uploads, limits) to convert interest into adoption.
    Directly boosts developer success and revenue potential, but risks hidden reliability regressions if infra lags.
    4Other / More discussion needed / None of the above.