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
    A major client overhaul and rapid plugin expansion are shipping in parallel with a growing tail of stability issues (GPU/runtime errors, client integrations), creating an urgent need to rebalance “more capabilities” toward “more reliable defaults.”
    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

    Stability vs. Velocity in Core + Client Overhaul
    The new client overhaul and broad feature throughput are strong signals of momentum, but recurring runtime failures (CUDA/llama_local, plugin regressions, inconsistent Twitter behavior) risk undermining developer trust unless a quality gate and “golden path” are enforced.
    Q1
    Do we temporarily slow new plugin merges to establish a reliability gate (tests, CI, compatibility matrix) for the core runtime + flagship clients?
    • GitHub summary: “Complete overhaul of the client application” (PR #2038).
    • GitHub issues: “CUDA error when using 'llama_local'” (issue #2080); “CUDA not being detected… transcription runs on CPU” (issue #1994).
    1Yes—enforce a reliability gate immediately (CI + smoke tests for core, Twitter, Telegram, Discord, and top providers).
    Short-term velocity drops, but reduces public-facing breakage and increases builder confidence.
    2Partial—keep merges flowing, but quarantine new plugins behind “experimental” tags and require minimal test coverage.
    Maintains ecosystem momentum while narrowing blast radius from unstable additions.
    3No—optimize for breadth now; let community triage instability via issues and rapid patching.
    Maximizes feature surface area, but risks reputational damage and contributor burnout from constant firefighting.
    4Other / More discussion needed / None of the above.
    Q2
    Which runtime failures deserve “red alert” prioritization as the canonical developer experience blockers?
    • GitHub issues: “WhatsApp plugin… cannot read properties of undefined (reading 'actions')” (issue #2078).
    • Discord (2025-01-07/08): frequent Twitter login, JSON formatting, rate limit, and shadowban discussions; PR #1974 created to fix Twitter scraper/login attempts.
    1GPU/local inference failures (CUDA/llama_local) and embedding/vector DB errors—block local self-hosting credibility.
    Strengthens the “runs anywhere” promise and reduces support load for serious builders.
    2Social client reliability (Twitter/Telegram/Discord) because these are the flagship onramps and most visible failures.
    Protects public brand and reduces churn among new users trying to deploy social agents.
    3Plugin API consistency and regression-proofing (e.g., WhatsApp undefined actions) to stabilize the long tail ecosystem.
    Improves composability, but may delay addressing the most common user-facing breakpoints.
    4Other / More discussion needed / None of the above.
    Q3
    What should be designated as the “Golden Path” reference stack for builders (the default opinionated setup we guarantee)?
    • Discord (2025-01-08): debates about minimum viable specs (2GB vs 4GB RAM) and deployment strategies (VPS/AWS/Docker).
    • GitHub updates: “Local Embedding Manager… fixing high RAM issues” (PR #1950).
    1Cloud-first Golden Path (ElizaOS Cloud + managed storage + curated providers), with local as best-effort.
    Optimizes reliability and supportability but may alienate self-host purists.
    2Local-first Golden Path (Docker + SQLite/Postgres + one recommended local model), with cloud as optional acceleration.
    Maximizes open-source autonomy, but raises the bar for stability guarantees across varied hardware.
    3Dual-path: officially supported “Local Lite” and “Cloud Pro,” each with explicit constraints and compatibility matrix.
    Clarifies expectations and reduces confusion, at the cost of maintaining two tested tracks.
    4Other / More discussion needed / None of the above.
    Knowledge System & Documentation as Operational Infrastructure
    The new Knowledge system (multi-agent RAG), Obsidian integration, and doc improvements directly advance the “Taming Information” mandate, but the Council must ensure these capabilities are delivered as a coherent, beginner-friendly workflow rather than scattered primitives.
    Q1
    Should the Knowledge system become a first-class default (enabled by default in starter agents), or remain opt-in until its UX and migration story are stable?
    • GitHub updates: “Implemented a separate Knowledge system with Multi-Agent RAG Optimization (PR #1620).”
    • GitHub updates: “Added methods… getKnowledge, searchKnowledge, createKnowledge… (PR #2005).”
    1Enable by default for all new agents and treat it as a core pillar of ElizaOS.
    Accelerates adoption and capability, but increases risk of confusing failures for beginners.
    2Keep opt-in; ship a guided onboarding and a migration wizard before defaulting it on.
    Protects execution excellence while building a smoother path to broader adoption.
    3Hybrid: default on only in curated “reference agents” (Eli5/Otaku), opt-in for general users.
    Provides working exemplars without forcing complexity on every new builder.
    4Other / More discussion needed / None of the above.
    Q2
    How should we standardize knowledge ingestion to avoid fragmentation across Obsidian, GitBook, Discord logs, and ad-hoc character.json knowledge blocks?
    • GitHub updates: “Introduced Obsidian integration plugin for improved knowledge management (PR #1943).”
    • Discord (2025-01-08): user question about alternatives to character.json knowledge text section for larger datasets (unanswered in coders channel).
    1Define a single canonical “Knowledge Source” spec (folders/URLs/connectors) and make all integrations conform to it.
    Improves composability and reduces duplicated tooling, but requires coordination across plugin authors.
    2Support multiple ingestion paths but publish an official “recommended stack” with templates and examples.
    Balances flexibility with guidance; risk remains that third-party patterns diverge over time.
    3Keep it decentralized; let the ecosystem evolve organically and curate later.
    Maximizes experimentation now, but increases long-term documentation and support complexity.
    4Other / More discussion needed / None of the above.
    Q3
    Do we operationalize a “Scribe Agent” pipeline that converts Discord/GitHub/X activity into issues, digests, and docs as a core governance function?
    • Discord (2025-01-08): action item “Develop a bot that can take intent from Discord and generate GitHub issues” (jin).
    • Discord (2025-01-08): action item “Create an automated daily digest from X, Discord, and GitHub” (jin).
    1Yes—make it a top-level initiative with a single owner and weekly output targets (issues triaged, docs updated, digest shipped).
    Directly supports “Trust Through Shipping” by turning conversation into execution artifacts.
    2Pilot it as an optional community-run tool first; only formalize after proving accuracy and low hallucination risk.
    Reduces governance risk, but may delay benefits to developer experience and transparency.
    3No—keep this manual to avoid automation errors and reputational risk.
    Avoids agent mistakes, but sustains high coordination overhead and slows knowledge consolidation.
    4Other / More discussion needed / None of the above.
    Ecosystem Alignment: Tribute Model, Partnerships, and Multichain Token Direction
    The community is coalescing around a tribute-based alignment mechanism and aggressive partnership expansion (Roblox, Arbitrum, Hyperfy), but governance clarity, wallet verification reliability, and an explicit multichain token strategy are now prerequisites for credibility.
    Q1
    Should the tribute model be codified into a standard agreement and on-chain enforcement primitives, or remain a social norm?
    • Discord (partners, 2025-01-08): “Projects using Eliza tech should send 5-10% of their tokens to the DAO as a form of alignment” (jin).
    • Discord (2025-01-08): “Roblox integration… with 10% tribute paid to the DAO” (StealthSDK announcement).
    1Codify it: publish a standard deal + lightweight on-chain attestations for “Eliza-aligned” projects.
    Strengthens legitimacy and reduces ambiguity, but raises coordination and legal/compliance complexity.
    2Keep it social: maintain norms, publish best practices, and spotlight compliant partners on the website.
    Moves fast and stays flexible, but may allow free-riders and create ecosystem resentment.
    3Hybrid: social norm now, with a future migration path to optional on-chain enforcement for major partners.
    Balances momentum with a credible roadmap toward stronger alignment guarantees.
    4Other / More discussion needed / None of the above.
    Q2
    What is our near-term multichain token strategy to prevent liquidity fragmentation while still enabling cross-chain agent economies?
    • Discord (tokenomics, 2025-01-08): “Explore Hyperlane integration for multi-chain token deployment” (wit).
    • Discord (tokenomics, 2025-01-08): “Develop canonical bridged token to Ethereum or Base for adoption” (wit).
    1Canonical bridge first (Ethereum/Base), treat other chains as satellites with unified liquidity routing.
    Minimizes fragmentation and simplifies messaging, but delays true omnichain reach.
    2Go omnichain via Hyperlane/LayerZero now, accept fragmentation and solve with market-making and routing later.
    Maximizes expansion speed, but increases operational complexity and risk of price inconsistencies.
    3Defer multichain token moves; prioritize framework/cloud reliability and revisit after execution excellence milestones.
    Protects focus and trust, but may miss strategic windows for ecosystem distribution.
    4Other / More discussion needed / None of the above.
    Q3
    How should leadership and public communication be structured to reduce reputational risk while preserving founder authenticity?
    • Discord (partners, 2025-01-08): partner concerns about founder engagement with memecoins and public perception.
    • Discord (overall, 2025-01-08): “Requests for better transparency about partnerships and development roadmaps.”
    1Create an official comms protocol: a single source of truth for partnerships/roadmaps and clear separation between personal and project accounts.
    Reduces narrative volatility and increases trust, but constrains informal community energy.
    2Maintain current informal comms, but add rapid-response clarification posts and an always-updated partnerships page.
    Preserves agility, but continues exposure to recurring confusion and reputational flare-ups.
    3Delegate outward comms to a council-elected spokesperson while founders focus on shipping and internal coordination.
    Professionalizes external messaging, but may introduce bureaucracy and dilute founder voice.
    4Other / More discussion needed / None of the above.