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 fleet is riding a surge of public attention while simultaneously absorbing migration friction and cloud-beta edge cases—making trust-through-reliability the decisive battlefield for the next 72 hours.
    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 & Support Load
    Migration is functionally live (snapshot taken; multi-chain availability confirmed), but repeated user errors and eligibility confusion are creating support drag and reputational risk at the exact moment the project is most visible.
    Q1
    Do we prioritize expanding migration accessibility (wallet support / exceptions) or enforce strict snapshot policy to maximize predictability and fraud resistance?
    • Discord 2025-12-27: Odilitime — "As a policy we're not migrating any purchases after snapshot."
    • Discord 2025-12-28: Multiple users reported wallet connection problems and "max amount reached" errors; support routed to dedicated channels.
    1Enforce strict snapshot rules; invest only in clearer messaging and automated eligibility checks.
    Maximizes determinism and reduces exploit surface, but may strand legitimate holders and increase sentiment volatility.
    2Add narrowly-scoped exception paths (manual review/whitelist) for provable snapshot holders with unsupported wallets.
    Reduces legitimate-user fallout while containing fraud risk, but increases operational complexity and turnaround expectations.
    3Broaden eligibility and tooling (multi-wallet connectors, expanded bridge directions) to minimize user friction.
    Improves UX rapidly but expands attack surface, creates policy ambiguity, and can undermine “trust through shipping” if rushed.
    4Other / More discussion needed / None of the above.
    Q2
    What is the Council’s minimum “trust posture” for migration comms (contracts, bridges, support) to reduce confusion and impersonation risk?
    • Discord 2025-12-29: Broccolex action item — "Create pinned tweet with contract addresses to avoid confusion."
    • Discord 2025-12-29: Contract shared in chat — "DuMbhu7mvQvqQHGcnikDgb4XegXJRyhUBfdU22uELiZA"
    1Publish a single canonical “Migration & Contracts” page and pin it across Discord/X/GitHub; no other links endorsed.
    Reduces phishing/impersonation vectors and consolidates truth, at the cost of slower updates unless well-maintained.
    2Keep comms distributed but add signed verification (PGP/sig, on-chain attestations) for official addresses and announcements.
    Raises authenticity guarantees without centralizing everything, but adds ceremony and requires user education.
    3Rely on support channels for resolution; keep public comms lightweight to avoid mistakes.
    Limits public errors but increases support burden and leaves narrative control to rumors during peak attention.
    4Other / More discussion needed / None of the above.
    Q3
    How aggressively should we invest in migration UX engineering (error clarity, wallet diagnostics) versus treating this as a one-time operation?
    • Discord 2025-12-28: Action item — "Fix 'max amount reached error' when users have large amounts of AI16Z."
    • Discord 2025-12-27: "max amount reached" interpreted as snapshot-ineligible (Odilitime), indicating UX ambiguity.
    1Treat it as a one-time event: patch only critical blockers; focus engineering on Cloud launch stability.
    Protects near-term roadmap velocity, but risks lingering distrust among late or confused migrators.
    2Invest in a polished migrator: explicit eligibility proofs, wallet-level diagnostics, and better error taxonomy.
    Improves success rate and reputation, but diverts capacity from Cloud beta hardening.
    3Outsource/automate: add community-run triage tooling and templates; engineering only supports escalation paths.
    Scales support with lower core-team load, but quality control and safety guarantees may weaken.
    4Other / More discussion needed / None of the above.
    ElizaOS Cloud Beta & Jeju Compute-Marketplace Trajectory
    Cloud is in open beta with “light support,” while Jeju is positioned as a decentralized Vercel alternative (compute marketplace, distributed cache, DNS, serverless SQLite). The strategic risk is promising a future platform before the current beta’s reliability story is airtight.
    Q1
    Should the Council frame Jeju as near-term product reality or long-horizon R&D, given Cloud is still in “light support” beta?
    • Discord 2025-12-29: "Eliza Cloud Beta: Open beta access is now available with light support ahead of full launch."
    • Discord 2025-12-28: Shaw — "Decentralized Vercel Alternative" with marketplace selecting optimal resources; includes DNS, distributed cache, and SQLite.
    1Position Jeju as R&D; focus messaging on Cloud beta reliability and developer onboarding now.
    Aligns with Execution Excellence and reduces expectation debt, but may dampen speculative excitement.
    2Market Jeju as imminent; use hype to drive Cloud beta signups and provider interest.
    Accelerates ecosystem energy, but increases reputational risk if beta issues remain visible.
    3Dual-track narrative: Jeju for providers/partners, Cloud for builders; segment comms and roadmaps.
    Balances excitement with credibility, but requires disciplined messaging and clear boundary-setting.
    4Other / More discussion needed / None of the above.
    Q2
    What is the minimum reliability/operability bar required before declaring “Cloud launch” complete under the monthly directive?
    • Monthly directive: "launch ElizaOS Cloud" and "build developer trust through reliability and clear documentation."
    • Discord 2025-12-29: Users reported an unspecified error when chatting with an agent via share link (Destiny).
    1Launch is “complete” when core workflows work end-to-end: create → deploy → chat/share, with documented known issues.
    Protects trust by anchoring launch to user reality, but may delay celebratory messaging.
    2Launch is “complete” when infra is online and onboarding exists; bugs are normal post-launch backlog.
    Ships faster and captures momentum, but risks violating Execution Excellence if UX is visibly brittle.
    3Launch is “complete” only after SLAs/incident response and provider reliability mechanisms are in place.
    Sets a high enterprise-grade bar that strengthens long-term credibility, but likely pushes launch beyond December.
    4Other / More discussion needed / None of the above.
    Q3
    How should provider SLAs and marketplace accountability be designed without undermining composability and decentralization?
    • Discord 2025-12-28: Shaw — "I do not [offer SLAs], but providers can" and action item to implement provider SLA capabilities.
    1Provider-defined SLAs with standardized disclosure templates and public reliability metrics.
    Keeps marketplace decentralized while enabling informed choice, but requires robust metrics and anti-gaming controls.
    2Protocol-enforced baseline SLA requirements (uptime, latency tiers) for listing eligibility.
    Improves average reliability, but increases central policy surface and may reduce provider diversity.
    3No formal SLAs; rely on reputation, staking/slashing, and automatic routing away from unreliable providers.
    Fits decentralized ethos, but may feel opaque/unreliable to Web2 developers unless reputation signals are strong.
    4Other / More discussion needed / None of the above.
    Developer Trust: DX, Data Layer Choices, and Quality Gates
    Docs and tooling progress is strong (multiple PRs merged; hot reload; docs improvements), but recurring “death by papercut” bugs (agent naming crashes, share-link errors, Windows setup friction) and storage uncertainty (SQLite vs PGLite) threaten the reliability narrative.
    Q1
    Do we standardize on SQLite-first portability for local/dev and treat PGLite/Postgres as advanced modes, or keep PGLite central to avoid fragmentation?
    • Discord 2025-12-29 core-devs: sayonara — SQLite "more portable and uses a single file, unlike PGLite."
    • Discord 2025-12-29: Ongoing debate about restoring first-class SQLite support due to PGLite portability/file corruption concerns.
    1Make SQLite the default local/dev path; provide a clear migration path to PGLite/Postgres for production.
    Optimizes DX and reliability for builders, but adds long-term maintenance and migration surface.
    2Keep PGLite as the default; fix corruption/portability issues and improve tooling around it.
    Reduces data-layer fragmentation, but may keep setup friction higher for newcomers.
    3Abstract storage behind a strict interface and let Cloud be the recommended default for persistence.
    Aligns with Cloud strategy and composability, but risks alienating self-hosters if local story feels second-class.
    4Other / More discussion needed / None of the above.
    Q2
    What quality gates should be enforced now to prevent recurring UX-breaking edge cases (e.g., invalid agent names, share link errors) from reaching production?
    • Discord 2025-12-27: DorianD — agent names "null" or numeric values caused save failures/exceptions.
    • Discord 2025-12-29 coders: Destiny — unspecified error when chatting with an agent via share link.
    1Add strict validation + contract tests for all user-input fields and share workflows; block release if failing.
    Improves reliability and trust, but may slow shipping cadence and require more test infrastructure.
    2Soft validation in UI with server-side sanitization; allow releases but track regressions with Sentry/telemetry.
    Maintains velocity while reducing worst failures, but still allows some broken experiences into the wild.
    3Rely on community issue triage and rapid patches; formal gates only for security and data-loss risks.
    Maximizes shipping speed, but conflicts with Execution Excellence and may erode developer confidence.
    4Other / More discussion needed / None of the above.
    Q3
    How far should we push TypeScript strictness and build-time checks (unused vars, DI patterns) before it begins harming contributor throughput?
    • Discord 2025-12-29 core-devs: discussion of build-time checks for unused variables as a middle ground (Odilitime).
    • GitHub issues 2025-12-29: Issue #6292 — epic for "world-class TypeScript patterns" (Decorators, DI, advanced type system).
    1Incrementally tighten: enforce unused-var checks now, defer full strict mode until after Cloud launch stabilization.
    Balances reliability and velocity, preserving near-term execution focus while raising quality over time.
    2Go strict immediately (full TS checks, stricter linting) to eliminate entire bug classes.
    Raises codebase integrity quickly, but may slow contributions and increase friction for new developers.
    3Stay permissive; invest in tooling (Copilot/Opus workflows) and code review culture rather than strict compilers.
    Keeps onboarding easy, but increases hidden defect risk and undermines “most reliable framework” positioning.
    4Other / More discussion needed / None of the above.