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 surge of merged PRs expanded plugin breadth and fixed core integration bugs, but recurring setup friction (embeddings, Node versions, Twitter behavior) signals that reliability and DX must now be prioritized over further surface-area growth.
    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

    Execution Excellence vs Plugin Proliferation
    Engineering throughput is exceptionally high (dozens of PRs merged daily and hundreds monthly), with new chain/DeFi/LLM plugins landing alongside fixes; however, the accelerating plugin surface increases regression risk and dilutes the Council’s reliability mandate.
    Q1
    Should the Council impose a temporary “stability gate” on new plugins to protect reliability and developer trust?
    • GitHub activity (Jan 24-26): “40 new PRs, 49 merged PRs, 23 new issues” (github_summary).
    • Daily report (2025-01-24): large batch of new plugins (Ton, Sei, Lit, Mina, Zerion, Moralis, Bedrock, etc.) plus multiple fixes.
    1Yes—freeze new plugin merges for a short window and focus on build/install, client reliability, and docs.
    Improves trust and reduces churn, but may slow ecosystem expansion momentum.
    2Partially—allow new plugins only if they include tests, README, and pass a standardized compatibility matrix.
    Preserves velocity while shifting contributors toward quality signals and repeatable release hygiene.
    3No—continue merging broadly and rely on community-driven fixes and fast iteration.
    Maximizes growth and novelty, but risks increasing support burden and reputational damage from breakages.
    4Other / More discussion needed / None of the above.
    Q2
    What should be the Council’s primary quality metric for the next release cadence: install success rate, CI green rate, or end-to-end agent reliability (Twitter/Discord/Telegram) under load?
    • Discord coders: recurring setup failures and dependency conflicts (Node version compatibility, @ai-sdk/provider vs mistral).
    • Daily report: “Resolved @ai-sdk/provider version conflicts” and multiple Twitter parsing fixes.
    1Install success rate (fresh machine) as the top metric.
    Directly improves developer onboarding and reduces Discord support load.
    2CI green rate and reproducible builds as the top metric.
    Stabilizes contributions at scale and prevents regressions from high-volume merging.
    3End-to-end agent reliability (real clients + actions) as the top metric.
    Aligns to real-world deployments, but requires more complex test harnesses and observability.
    4Other / More discussion needed / None of the above.
    Q3
    Where should “non-core” capability expansion live to remain composable without destabilizing the framework: monorepo, external plugin registry, or curated “blessed” set?
    • Daily report: many new plugins landed directly in core repo (elizaos/eliza).
    • Discord: repeated plugin integration confusion (dexscreener API key check, character.json secrets vs .env).
    1Keep most new plugins external (registry-first), with strict versioning and compatibility badges.
    Limits blast radius and clarifies support expectations, but adds coordination overhead.
    2Maintain a small curated “blessed” plugin set in-repo; everything else external.
    Creates a stable, trusted path for newcomers while still supporting long-tail experimentation.
    3Continue integrating broadly into the monorepo for unified tooling and faster iteration.
    Simplifies discovery and integration, but increases coupling and regression risk.
    4Other / More discussion needed / None of the above.
    Developer Experience Hotspots (Embeddings, Node, Twitter Behavior)
    The community repeatedly hit the same configuration failures (vector dimension mismatch, Node version incompatibility, Twitter client behavior controls), indicating that the path to a working agent is still too brittle for “developer-first” claims.
    Q1
    Should the Council mandate a single “golden path” configuration (blessed Node version + embedding provider + minimal clients) with hard validation at startup?
    • Discord (2025-01-24): “Node.js version compatibility… v23.3.0 being recommended.”
    • Discord (2025-01-24): “Vector dimension mismatch (384 vs 1536)… resolved by setting USE_OPENAI_EMBEDDING=TRUE.”
    1Yes—enforce a golden path and fail fast with explicit remediation steps.
    Reduces support load and increases install success, but constrains advanced setups.
    2Offer golden path presets, but keep permissive defaults and warnings rather than hard failures.
    Balances accessibility and flexibility, though some users will still fall into misconfig traps.
    3No—keep configuration flexible and rely on docs/community troubleshooting.
    Supports power users, but perpetuates repeated onboarding pain and inconsistent outcomes.
    4Other / More discussion needed / None of the above.
    Q2
    How should we resolve embedding dimension mismatches structurally: automatic DB migration/segmentation, forced DB reset, or per-provider vector namespaces?
    • Discord (2025-01-22): “Vector dimension mismatch… clear your local db with rm -f ./agent/data/db.sqlite” (Yoda26).
    • Discord (2025-01-24): “Set USE_OPENAI_EMBEDDING=TRUE” (boja).
    1Implement per-provider vector namespaces (or separate tables) and prevent cross-dimension mixing.
    Eliminates a class of errors long-term, but requires schema and retrieval updates.
    2Auto-detect dimension changes and perform guided migration or rebuild of embeddings.
    Improves UX significantly, though complex to implement reliably across adapters.
    3Document and standardize the “delete db and rebuild” recovery pattern.
    Fast to ship, but shifts operational burden to users and undermines reliability perception.
    4Other / More discussion needed / None of the above.
    Q3
    Should Twitter client behavior controls (reply-only, retweet disable, rate limiting) be promoted to first-class config rather than code edits?
    • Discord (2025-01-24): reply-only workaround: “Comment out this line… packages/client-twitter/src/post.ts#L289” (tcm390).
    • Discord (2025-01-22): “Implement proper rate limiting for Twitter posts” listed as an action item.
    1Yes—add explicit config flags for reply-only, retweet/like toggles, and rate limits; deprecate code-edit instructions.
    Reduces accidental misbehavior and aligns with developer-first reliability.
    2Partially—provide a few high-demand toggles now and keep advanced behavior as code-level customization.
    Delivers quick wins while preserving flexibility, but leaves some recurring support gaps.
    3No—keep behavior control in code for maximum composability.
    Maintains power-user freedom, but increases fragmentation and “tribal knowledge” dependencies.
    4Other / More discussion needed / None of the above.
    Model & Trust Stack Direction (DeepSeek + TrustDB + Tokenomics)
    DeepSeek-R1 appears to be a low-friction model upgrade via OpenRouter, while TrustDB is positioned as a decentralized trust layer; simultaneously, tokenomics debate remains unresolved, risking strategic drift between “simple shipping” and “complex alignment mechanisms.”
    Q1
    Should DeepSeek support be treated as a priority “reference integration” (docs + presets + testing) to strengthen the open, developer-friendly narrative?
    • Discord partners (2025-01-24): “Since OpenRouter supports it, we can change to DeepSeek in 1 line of code… testing with DegenAI soon.” (jin)
    • Discord ideas-feedback-rants: DeepSeek R1 noted as strong for tool/action calling without GPU.
    1Yes—make DeepSeek a first-class preset with recommended settings, JSON/tool-calling guidance, and CI coverage.
    Strengthens OSS positioning and reduces inference cost barriers, but adds support surface.
    2Ship as “supported but not blessed” via OpenRouter, focusing on core stability first.
    Keeps focus on reliability while still enabling the community to experiment.
    3Defer—avoid expanding model matrix until v2/plugin architecture stabilizes.
    Reduces near-term complexity, but risks missing momentum around open models.
    4Other / More discussion needed / None of the above.
    Q2
    Should TrustDB become a core extension (standard interface + adapter support) to anchor agent verification without central registries?
    • Discord (2025-01-24): “TrustDB… decentralized trust relationships between agents… eliminating the need for centralized verification systems.” (DorianD)
    • Discord coders: “Update trustDB implementation and consider moving it into core as an extension.” (0xbbjoker)
    1Yes—standardize TrustDB interfaces now and ship a minimal, audited core extension.
    Establishes a unique trust primitive and supports governance narratives, but requires careful security review.
    2Keep TrustDB experimental as an external module until schema and adapter maturity is proven.
    Avoids locking design too early, but delays ecosystem-wide interoperability for trust signals.
    3Replace with simpler offchain verification patterns for now (signatures/attestations) and revisit later.
    Speeds delivery, but risks losing differentiation around decentralized trust.
    4Other / More discussion needed / None of the above.
    Q3
    Given tokenomics contention, what governance posture should the Council adopt: ship a simple launchpad model now, or design a richer staking/delegation system tied to trust/whitelisting?
    • Tokenomics channel: tension between “simple, proven models” vs “staking/delegation with slashing” (Vasily Sumanov) and “simplicity to avoid barriers” (DorianD).
    • Partners channel: market concerns and demand for clearer value proposition; “prepare slides explaining Block Tank value proposition” (jin).
    1Ship a simple model first (bonding curve/dual pool), then iterate based on adoption and data.
    Maximizes time-to-market and clarity, but may leave trust/quality problems under-addressed.
    2Pursue a hybrid: simple launch mechanics plus optional staking/delegation for trust signaling (no slashing initially).
    Balances usability and alignment while avoiding the hardest enforcement problems early.
    3Design the full staking/delegation + enforcement system before shipping to ensure long-term alignment.
    May yield stronger incentives, but increases complexity and delays—risking developer churn.
    4Other / More discussion needed / None of the above.