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
    Operational reliability took priority as critical developer-blocking failures (.env not read; startup hanging at LlamaService; PostgreSQL long-message errors) surfaced alongside ongoing hardening work (tests, validation, DB path fixes), making “trust through shipping” the dominant imperative.
    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

    Reliability Incidents: Boot, Config, and Database Failure Modes
    Three high-severity issues threaten developer trust: environment configuration not loading, server hangs during LlamaService initialization, and PostgreSQL errors on long messages; these are now the clearest obstacles to execution excellence and smooth onboarding.
    Q1
    Do we declare a reliability freeze (no new features) until the boot/config path and startup hang are resolved across common environments?
    • GitHub Daily (2025-02-11): "Urgent Discussion: .env file is not being read" (Issue #3449).
    • GitHub Daily (2025-02-11): "pnpm start process is hanging during LlamaService initialization" (Issue #3448).
    1Yes—impose a short reliability freeze with a defined exit criterion (issues closed + regression tests).
    Maximizes developer trust and stabilizes onboarding at the cost of temporarily slowing new capability throughput.
    2Partial—allow limited feature work only if coupled with tests and does not touch boot/runtime paths.
    Preserves momentum while reducing risk, but may prolong the time-to-stability if attention remains split.
    3No—continue parallel feature development; treat the incidents as normal churn during rapid growth.
    Maintains velocity, but risks reputational damage and higher support load if new users keep hitting blockers.
    4Other / More discussion needed / None of the above.
    Q2
    Which “known-good” runtime environment should we canonize for V1/V2 to reduce support entropy (Node/pnpm/bun matrix)?
    • Discord (2025-02-09): "Recommended environment ... Node.js v23.3.0 and pnpm v9.15.4." (Sarthak).
    • Discord (2025-02-10): "Running multiple Eliza agents requires ~1.5–3GB RAM per agent" (coders channel summary).
    1Canonize Node 23.3 + pnpm 9.15.4 as the single supported baseline; document others as “best-effort.”
    Reduces variability and support burden; may frustrate teams standardized on older LTS stacks.
    2Support two baselines: Node LTS (e.g., 20/22) and Node 23.x; automate CI coverage for both.
    Improves adoption and enterprise friendliness, but increases CI and maintenance overhead.
    3Move decisively toward Bun-first (with pnpm as compatibility) and focus all docs/CI on Bun.
    Potentially improves speed and DX, but amplifies breakage risk during the transition period.
    4Other / More discussion needed / None of the above.
    Q3
    How should we handle long-message and knowledge ingestion constraints to prevent database/runtime instability (Postgres + RAG memory growth)?
    • GitHub Daily (2025-02-11): "Long messages are causing errors with PostgreSQL" (Issue #3441).
    • GitHub Issues Summary (2025-02-10): "RagKnowledge ... cleaned up during runtime initialization" / "ragKnowledge handling for stringKnowledge" (Issues #3440, #3434).
    1Implement strict message/knowledge size limits with graceful truncation + user-visible warnings.
    Stabilizes systems quickly and predictably, but may reduce capability for power users with large contexts.
    2Adopt streaming/segmented storage: chunk long messages and store embeddings incrementally with backpressure.
    Preserves capability and scales better, but requires more engineering and careful compatibility testing.
    3Offload large-context handling to a dedicated knowledge service (external DB/vector store) and keep core lean.
    Improves core robustness and composability, but increases deployment complexity for self-hosters.
    4Other / More discussion needed / None of the above.
    V2 Readiness and Modular Architecture Direction
    The community is aligned on an impending V2 (beta March, GA April) and is already pushing for structural modularity (/sources plugins vs /packages core); Council must decide how to balance schedule credibility against architecture refactors that improve selective installs and DX.
    Q1
    Should the Council protect the V2 Beta/GA dates by deferring major repo restructuring, or accept schedule slip in favor of modular installation as a V2 pillar?
    • Discord (2025-02-10): "V2 Timeline: Beta release in March, GA release in April 2025" (kalshnikov).
    • Discord (2025-02-10): "Proposal to organize into /sources (optional plugins) and /packages (core functionality)" (discussion summary).
    1Protect dates—ship V2 with minimal restructuring; schedule a post-GA modularization milestone.
    Strengthens shipping credibility, but may prolong dependency bloat and installation confusion.
    2Modular-first—make selective install the core of V2 even if GA slips modestly.
    Improves DX and long-term maintainability, but risks trust if timelines repeatedly slide.
    3Hybrid—ship Beta on time, but gate GA on completion of the restructuring + migration tooling.
    Keeps momentum and community testing while ensuring the final release meets execution-excellence standards.
    4Other / More discussion needed / None of the above.
    Q2
    What is our official stance on plugin ecosystem expansion versus stability (new plugins are arriving rapidly while core incidents persist)?
    • GitHub Activity (2025-02-10 to 2025-02-12): "29 new pull requests (8 merged) ... active contributor participation."
    • GitHub PRs (2025-02-10.json): "Multiple new plugins introduced ... D.A.T.A, Navi, Bluefin" (PRs #3421, #3417, #3425, #3427).
    1Prioritize stability—tighten merge gates for new plugins until core reliability KPIs improve.
    Reduces breakage surface area and support load, but may slow ecosystem growth and partner excitement.
    2Parallel tracks—continue plugin expansion but require standardized tests/CI templates for all plugins.
    Sustains momentum while improving quality through process; requires investment in tooling and enforcement.
    3Ecosystem-first—accelerate plugin intake to win mindshare; accept higher churn temporarily.
    May win short-term attention, but risks violating the “reliability over feature quantity” principle.
    4Other / More discussion needed / None of the above.
    Q3
    Do we formalize multi-agent orchestration as a near-term framework capability (to match demand), or keep it as an advanced pattern documented outside core?
    • Discord (2025-02-10): "What's the best way to have agents working with each other? ... orchestration/manager framework?" (unanswered; discussion/coders logs).
    • Discord (2025-02-10): "Create guide for agent-to-agent communication" (action item; joseroberts87).
    1Core capability—define a minimal orchestration API in V2 (agent-to-agent calls, permissions, tracing).
    Differentiates platform and enables composable swarms, but increases scope and security complexity.
    2Docs-first—publish validated orchestration patterns and a reference “manager agent” without core changes.
    Delivers value quickly with low risk, but may limit standardization and interoperability across projects.
    3Plugin-layer—ship orchestration as an official plugin package with versioned contracts.
    Maintains core simplicity while enabling modular adoption, but may fragment implementations if not governed tightly.
    4Other / More discussion needed / None of the above.
    Trust Surfaces: Security of Agent-Managed Funds & Operational Exposure
    Community discussion highlights a credibility risk around agents handling funds and exposed clients/services; we must define a security posture (vaults, policy controls, TEEs vs wallet abstractions) before pushing deeper into DeFAI and autonomous finance narratives.
    Q1
    What security baseline should we declare for any agent that can move value (funds, contracts, LP interactions) before it is showcased as a flagship capability?
    • Discord ideas-feedback-rants (2025-02-10): "Security mechanisms for agent-managed funds" (TAISER Andy).
    • Discord (2025-02-10): "Reference to Lit Agent Wallet as an improvement for controls and key handling" (ideas-feedback-rants summary).
    1Smart-contract vault + policy guardrails (spending limits, allowlists, time locks) as mandatory baseline.
    Creates robust on-chain safety and auditability, improving trust for DeFAI and cloud deployments.
    2Wallet abstraction baseline (e.g., Lit Agent Wallet) with strong key management and human override.
    Faster to ship and integrate, but may provide weaker guarantees than enforceable on-chain constraints.
    3No baseline yet—limit fund-moving to experimental status with explicit disclaimers until later.
    Reduces liability and risk now, but may slow market positioning in autonomous finance narratives.
    4Other / More discussion needed / None of the above.
    Q2
    Should TEEs be part of our security story, given reliability concerns ("instances die"), or should we treat them as optional hardening only?
    • Discord ideas-feedback-rants (2025-02-10): "TEE instances die pretty frequently" (TAISER Andy).
    1Optional—support TEEs via plugins/integration guides, but do not make them a recommended default.
    Avoids operational fragility while preserving a path for high-security deployments.
    2Recommended—invest in TEE-first operational tooling (recovery, attestation, key rotation) as a differentiator.
    Could raise the ceiling for trust and enterprise adoption, but increases complexity and on-call burden.
    3Deprioritize—focus on vault/policy systems and remove TEE messaging from near-term roadmap.
    Simplifies narrative and engineering scope, but may concede a perceived security advantage to competitors.
    4Other / More discussion needed / None of the above.
    Q3
    How aggressively should we lock down exposed interfaces (e.g., DirectClient/public IP) to prevent RCE-class incidents as the ecosystem scales?
    • Discord (2025-02-09): "Security concerns ... exposing DirectClient to public IPs and potential RCE vulnerabilities" (daily summary).
    1Ship secure-by-default: bind to localhost, require auth tokens, and document reverse-proxy best practices.
    Prevents preventable incidents and builds trust with developers deploying in the wild.
    2Add a “deployment profile” wizard (local/dev/prod) that configures secure defaults but remains flexible.
    Improves DX and reduces misconfigurations, but requires additional product work and maintenance.
    3Rely on documentation warnings only; keep current defaults to reduce friction for quick demos.
    Maximizes ease-of-start but increases the probability of serious security incidents and reputational harm.
    4Other / More discussion needed / None of the above.