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
    Council attention converges on trust repair: clarifying token value accrual and migration safety while hardening Cloud beta reliability and documentation to sustain developer confidence.
    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 Trust, Value Accrual, and Migration Safety
    Community sentiment is dominated by token drawdown anxiety and unclear value accrual narratives; the team’s message is that Cloud revenue (not yield) funds buybacks and future utility arrives with Jeju, but gaps in official tokenomics and migration guidance remain a trust risk.
    Q1
    What is the Council-approved, canonical value-accrual doctrine to publish now—before Jeju—so builders and holders can model incentives without speculation?
    • Odilitime (Discord 2025-12-24): "Cloud revenue (but not yield) will be used for ElizaOS token buybacks"
    • Kenk (Discord 2025-12-24): "The roadmap is a technical document, not a tokenomics piece."
    1Publish a minimal, verifiable tokenomics addendum: buybacks from Cloud revenue + explicit near-term utility milestones (Jeju/registry fees/agent registration).
    Reduces narrative ambiguity quickly and anchors expectations to measurable product activity.
    2Delay public tokenomics specifics until Jeju, focusing messaging strictly on product usage and shipping reliability.
    Avoids overpromising, but prolongs uncertainty and may depress builder participation during the critical Cloud ramp.
    3Adopt a competitor-inspired liquidity coupling model (e.g., agent-token pairing) as an explicit roadmap experiment.
    May boost perceived incentives, but risks strategic drift from execution excellence and adds economic complexity.
    4Other / More discussion needed / None of the above.
    Q2
    How should the Council operationalize migration safety to neutralize impersonation/scam risk during the token transition window?
    • Hexx 🌐 (Discord 2025-12-24): advised moving tokens to Phantom and warned about potential scams during migration
    • Discord 2025-12-24: users asked about Moonshot wallet migration path
    1Ship an official migration safety bulletin + signed link registry (website/GitHub) and enforce Discord verification rituals (locked announcements, mod-only links).
    Establishes a single source of truth and reduces social-engineering surface area.
    2Provide a supported “manual attestation” channel (GitHub issue template + on-chain proof steps) for edge wallets, without direct DM support.
    Helps legitimate edge cases while preserving security hygiene, at the cost of operational overhead.
    3Pause or slow migration support interactions on Discord; route all support through the portal and public docs only.
    Minimizes scam vectors but may increase frustration and reduce migration completion rate.
    4Other / More discussion needed / None of the above.
    Q3
    What is the Council’s stance on buybacks vs. broader utility mechanisms as the primary near-term coordination lever?
    • Odilitime (Discord 2025-12-24): "revenue will be used for buy backs, the yield won't"
    • Borko (Discord 2025-12-24): "additional token utility is planned when Jeju is released"
    1Treat buybacks as a transitional stabilizer; prioritize shipping utility (Jeju/registry/Cloud primitives) as the real engine.
    Aligns with the North Star by tying value to usage while keeping a near-term confidence mechanism.
    2Scale buybacks aggressively to signal strength while utility matures.
    May improve sentiment short-term but can starve product velocity and conflict with execution-excellence priorities.
    3De-emphasize buybacks; focus purely on utility and developer adoption metrics.
    Maximizes product focus but leaves a narrative vacuum during a sensitive market and migration period.
    4Other / More discussion needed / None of the above.
    ElizaOS Cloud Beta Readiness & Developer Onboarding
    Cloud is in beta onboarding with a January ramp planned; near-term product constraints (50MB uploads, no custom model hosting yet) and promised roadmap items (custom model hosting next week) must be delivered with reliability and clear UX to earn developer trust.
    Q1
    What is the Council’s “beta exit” definition for Cloud—what reliability and capability thresholds must be met before the January ramp and EthDenver positioning?
    • Discord 2025-12-23: "Eliza Cloud has entered beta... larger ramp-up planned for January"
    • Discord 2025-12-23: Cloud positioned as "primary platform for agent registration" ahead of EthDenver
    1Define beta exit by reliability KPIs (streaming stability, chat isolation correctness, upload success rate) plus one “must-have” feature (custom model hosting).
    Creates an execution-excellence gate that protects trust even if launch timing slips slightly.
    2Define beta exit by onboarding throughput and ecosystem visibility (number of onboarded builders/agents) even if some features remain flagged.
    Accelerates network effects but increases the chance of trust-damaging failures in production feedback loops.
    3Maintain perpetual beta; iterate publicly with feature flags, prioritizing rapid shipping over formal exit criteria.
    Maximizes pace but can dilute the project’s “reliability first” brand promise.
    4Other / More discussion needed / None of the above.
    Q2
    How should we scope and message the knowledge-upload pathway to avoid mismatched expectations (e.g., large book-scale corpora) while preserving a great DX?
    • Borko (Discord 2025-12-24): "For file uploads we've set a limit of 50MB."
    • Borko (Discord 2025-12-24): "Best is markdown" (recommended format)
    1Publish a “Knowledge Ingestion Guide” with file-size ceilings, chunking patterns, and recommended markdown schemas (plus examples).
    Reduces support load and turns constraints into a developer-friendly, repeatable workflow.
    2Raise the limit quickly (e.g., 200MB) and rely on backend scaling to handle demand.
    Improves perceived capability but risks platform instability and unpredictable costs during beta.
    3Keep the limit and introduce an external “knowledge repo sync” (Git-based) as the primary path for large corpora.
    Aligns with open/composable principles, but requires extra tooling and may slow casual builder adoption.
    4Other / More discussion needed / None of the above.
    Q3
    What is the Council’s priority order for next-week Cloud work: custom model hosting, upload tweaks, or onboarding/registration flows?
    • Borko (Discord 2025-12-24): "Custom model hosting... on our roadmap... probably be ready next week"
    • Borko (Discord 2025-12-24): "File upload features are currently being tweaked"
    1Custom model hosting first (minimum viable BYO endpoint), then polish uploads, then refine onboarding.
    Unlocks advanced builders and differentiates Cloud, but may slow overall UX stability improvements.
    2Upload reliability and knowledge UX first, then onboarding flows, then custom model hosting.
    Optimizes execution excellence and first impressions for the broadest builder segment.
    3Agent registration/onboarding flow first to secure EthDenver positioning, then address feature depth.
    Improves narrative and ecosystem momentum, but risks scaling a leaky funnel if core flows are unstable.
    4Other / More discussion needed / None of the above.
    Reliability & DX Debt: Docs, CI Integrity, and Chat Isolation Bugs
    Operational signals show classic trust erosion vectors: outdated monorepo docs, CI failures due to billing, and UI/chat behavior issues (conversation duplication and default conversation selection) that threaten the “reliable, seamless UX” principle if not treated as priority defects.
    Q1
    Should the Council impose a “Docs-as-Code Release Gate” for v1.6.x/Cloud onboarding, given reported outdated/false monorepo documentation?
    • Stan (Discord 2025-12-24): "identified outdated information in the monorepo documentation and began updating it"
    • GitHub Issue #6284 (Dec 24): "monorepo documentation needs to be fixed"
    1Yes—no release without docs parity checks (versioned docs, verified onboarding steps, and an owner assigned).
    Directly reinforces Developer First and Trust Through Shipping, at the cost of some throughput.
    2Partial gate—only block releases when docs errors affect security, onboarding, or migration; otherwise backlog.
    Balances velocity with trust, but may allow slow accumulation of DX friction.
    3No gate—optimize for shipping and rely on community corrections post-release.
    Maximizes speed but undermines reliability branding and increases support burden.
    4Other / More discussion needed / None of the above.
    Q2
    How should we treat CI failures caused by external service billing (e.g., Claude top-up) in the context of execution excellence?
    • core-devs (Discord 2025-12-24): "GitHub Actions job failure... Claude billing needing a top-up"
    1Make CI dependencies budgeted and redundant (billing alerts, failover, and a “no-billing-no-merge” policy).
    Protects shipping cadence and signals professionalism to developers.
    2Reduce reliance on paid CI steps by moving LLM-dependent checks to optional/nightly jobs.
    Improves resilience and cost control, but may reduce automated quality signals on each PR.
    3Accept occasional CI downtime; address ad hoc when failures occur.
    Low overhead short-term, but compounds reliability risk and slows contributor throughput.
    4Other / More discussion needed / None of the above.
    Q3
    What is the Council’s severity classification for cross-agent conversation duplication and conversation selection UX—P0 trust defect or routine UX backlog?
    • GitHub Issue #6282 (Dec 24): "conversation duplication bug... appearing in another agent's chat history"
    • GitHub Issue #6281 (Dec 24): request to open most recent conversation by default
    1P0 trust defect—treat as data isolation breach risk; halt feature work until fixed and verified with tests.
    Reinforces reliability and user trust, especially critical for Cloud’s multi-tenant future.
    2P1—fix in the next sprint with targeted tests; allow limited feature work in parallel.
    Keeps momentum while addressing a serious UX issue, but risks prolonged exposure.
    3P2—schedule after major launches; mitigate with UI messaging and user workarounds.
    Prioritizes launch optics over correctness, increasing the chance of reputational damage if reproduced publicly.
    4Other / More discussion needed / None of the above.