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 is split between execution excellence in the runtime (streaming + provider performance hardening) and a rising legitimacy risk from token migration confusion and community distrust that threatens the Cloud launch narrative.
    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

    Runtime Reliability: Streaming & Provider Performance Contracts
    Core shipped a major streaming enhancement (merged PR #6212), while an open refactor (PR #6263) proposes parallel provider execution with timeouts—signaling a push toward reliability but exposing an unresolved contract: are providers allowed to hit live APIs or must they be cache-only?
    Q1
    What is the Council’s official provider contract for the Framework: cache-only data access, best-effort live calls, or a tiered approach with strict time budgets?
    • core-devs: Odilitime argued providers should never make API calls and should only read from caches; Stan proposed parallel execution with configurable timeout (default 1s) and warnings for slow providers (PR #6263).
    1Cache-only contract: providers must not perform network I/O during the critical pipeline; live fetching belongs in tools/actions with explicit UX.
    Maximizes determinism and latency predictability, but requires more developer education and clearer tool/provider boundaries.
    2Best-effort live calls allowed: providers may call APIs, but must respect global timeouts and fail gracefully.
    Improves out-of-the-box usefulness, but risks tail latency, rate-limit failures, and inconsistent agent behavior across environments.
    3Tiered model: default providers are cache-only; an opt-in 'networked provider' class is allowed with explicit budget, circuit-breakers, and observability.
    Balances DX and reliability, but adds complexity to docs, interfaces, and test expectations.
    4Other / More discussion needed / None of the above.
    Q2
    How aggressive should the runtime be in enforcing performance budgets (e.g., aborting the pipeline at 1s) versus degrading gracefully with partial provider results?
    • core-devs: Agreement formed around a configurable timeout (default 1s) that would abort the pipeline if providers take too long; add warnings for slow providers.
    1Hard-fail budget: abort the pipeline when provider SLA is violated, surface a clear error and guidance.
    Forces ecosystem discipline and predictable UX, but may feel brittle during early plugin experimentation.
    2Soft-degrade: continue with partial provider data, emit warnings/telemetry, and let the agent respond with reduced context.
    Preserves continuity for users, but can hide systemic performance debt and complicate debugging.
    3Adaptive mode: hard-fail in Cloud/production presets, soft-degrade in local/dev presets.
    Aligns with Developer First while protecting Cloud reliability, at the cost of configuration surface area.
    4Other / More discussion needed / None of the above.
    Q3
    What is the fastest path to making streaming feel 'real' end-to-end (Framework → Cloud → Client) given remaining UI rendering issues?
    • Discord 2025-12-16: Stan: "Everything works in the monorepo, but for Actions the UI still displays the text all at once instead of streaming it."
    • GitHub 2025-12-18: PR #6212 'feat: enhance streaming support in text generation' merged.
    1Prioritize client/UI correctness: fix Actions UI streaming rendering before adding more streaming endpoints.
    Delivers visible user value quickly and boosts trust, but may delay backend refactors.
    2Prioritize Cloud transport: ensure Cloud streaming is stable and observable, accept temporary UI quirks with clear roadmap.
    Hardens the platform layer for scale, but risks perception that streaming is still 'broken'.
    3Ship a 'Streaming MVP preset': known-good model/provider + UI path, document limitations, expand coverage iteratively.
    Creates a reliable demo lane for credibility, while buying time to fix long-tail streaming paths.
    4Other / More discussion needed / None of the above.
    Token Migration & Exchange Coordination: Trust Incident Containment
    Migration confusion across exchanges (e.g., Bithumb vs Kraken handling) and user reports of a "disastrous" swap are creating a reputational gravity well; without crisp, multilingual guidance and verifiable exchange communications, the Cloud launch risks being drowned by governance noise.
    Q1
    What is the Council’s containment strategy for migration-related distrust: public evidence releases, partner-by-partner escalation, or a redesigned self-serve migration path?
    • Discord 2025-12-17: "Different exchanges (Bithumb and Kraken) are handling the AI16Z to ELIZAOS token swap differently, causing confusion."
    • Discord 2025-12-18 discussion: users described migration as "disastrous" and "dilution."
    1Publish verifiable timelines and receipts: snapshot rules, exchange contact logs (where allowed), and a single canonical FAQ.
    Restores credibility through transparency, but may expose sensitive partner dynamics and requires careful compliance review.
    2Escalate privately with exchanges first, then issue short public updates with milestones (no receipts).
    Preserves partner relationships, but may fail to satisfy communities demanding proof and could prolong distrust.
    3Invest in productized migration v2: wallet-agnostic claims, clearer UX, and safer recovery flows for edge cases (e.g., Tangem/WalletConnect gaps).
    Reduces future incidents and support load, but is slower and could miss the December execution window.
    4Other / More discussion needed / None of the above.
    Q2
    How should the Council address Korean community concerns about marginalization while maintaining operational focus on shipping?
    • Discord 2025-12-18 discussion: "Several Korean users expressed feeling marginalized by the project leadership."
    • Discord 2025-12-17: requests for evidence of communications with Bithumb regarding snapshot timing.
    1Establish a KR liaison cell: bilingual moderators + a weekly KR-specific migration bulletin and office hours.
    Directly reduces friction and misinformation, but requires staffing and consistent follow-through.
    2Treat it as a universal comms gap: ship one global migration playbook and translate it, without special programs.
    Scales better, but may not repair perceived exclusion or handle KR exchange-specific realities fast enough.
    3Defer community repairs until after Cloud launch, focusing all bandwidth on shipping and stability.
    Maximizes near-term delivery velocity, but increases the chance that legitimacy erosion undermines launch impact.
    4Other / More discussion needed / None of the above.
    Q3
    What is the Council’s posture on exchange-driven swap discrepancies: do we accept exchange snapshot sovereignty, or provide compensatory mechanisms where feasible?
    • Discord 2025-12-17: Serikiki explained Kraken would not give tokens to users who sold after the snapshot; confusion persists due to exchange differences.
    1Accept exchange sovereignty: reinforce 'self-custody recommended' and provide education; no compensation.
    Clear boundaries and lower liability, but may intensify backlash from affected users.
    2Compensate selectively: create an appeals process for provable edge cases (time-bounded, capped).
    Can defuse major grievances, but introduces fraud risk and sets precedent for future claims.
    3Offer technical alternatives: enable claims from more wallet types / manual verification paths instead of compensation.
    Improves fairness via tooling, but requires engineering effort and careful security controls.
    4Other / More discussion needed / None of the above.
    Developer-First Delivery: Plugin Integration Friction & Documentation Debt
    Builders are hitting friction integrating new plugins (Starknet type mismatches, missing handlers, unclear CLI flows) while major ecosystem PRs (Discord plugin) sit large and stale; combined with an open-ended 'Docs' issue (#6264), this threatens the 'Developer First' promise at the exact moment Cloud onboarding must be crisp.
    Q1
    Should the Council enforce stricter compatibility gates for plugins (types, runtime interfaces, action registration) before they are promoted as 'official'?
    • coders 2025-12-18: FenrirFawks hit TypeScript incompatibilities between AgentRuntime and IAgentRuntime; missing handler for DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN.
    • core-devs 2025-12-18: Decision to pin @elizaos/* versions in plugins rather than using latest (Stan).
    1Yes—introduce an 'official plugin bar' with CI matrices against supported Framework versions and required type checks.
    Improves reliability and trust, but raises contributor friction and may slow ecosystem growth.
    2Partially—keep community plugins flexible, but label compatibility explicitly and provide a 'known good' lockfile/pinning guidance.
    Balances openness with clarity, but still leaves users exposed to rough edges if labels are ignored.
    3No—prioritize speed and experimentation; rely on semver + community support to smooth edges.
    Maximizes experimentation, but conflicts with the Monthly Directive’s execution excellence and Cloud reliability goals.
    4Other / More discussion needed / None of the above.
    Q2
    How should we handle the large, aging Discord plugin PR (66 commits, ~3 weeks open): merge fast with follow-up fixes, or split/refactor before merging?
    • Discord 2025-12-17: "Discord Plugin: Large PR with 66 commits is ready to merge after being open for three weeks" (Odilitime).
    1Merge now with a rollback plan and immediate patch sprint (48–72h) to stabilize in main.
    Unblocks ecosystem velocity quickly, but increases short-term breakage risk.
    2Split into smaller PRs: isolate risky refactors vs safe fixes, then merge incrementally.
    Reduces blast radius and improves review quality, but delays shipping and may stall contributors.
    3Hold until Cloud launch stabilizes: freeze non-critical integrations to protect execution excellence.
    Protects the launch window, but harms Developer First momentum and leaves important integration work stranded.
    4Other / More discussion needed / None of the above.
    Q3
    What documentation artifact should be treated as the single source of truth for December: migration playbook, Cloud onboarding path, or plugin/provider best practices?
    • GitHub 2025-12-18: Issue #6264 titled 'Docs' opened with no comments.
    • Discord 2025-12-18: Freya requested clearer migration documentation; Odilitime requested documenting provider best practices (avoid API calls, use caching).
    1Migration playbook first: reduce support load and reputational harm; Cloud docs can follow.
    Stabilizes community trust, but may slow developer adoption if Cloud onboarding remains unclear.
    2Cloud onboarding first: make the happy path irresistible and reliable; handle migration via targeted FAQs.
    Accelerates platform adoption, but risks the narrative being dominated by unresolved migration complaints.
    3Provider/plugin best practices first: prevent performance and compatibility issues from multiplying as adoption grows.
    Improves framework quality at scale, but may not address the most visible user pain points immediately.
    4Other / More discussion needed / None of the above.