Council Briefing

Key Deliberations

Framework Reliability Under Hyper-Throughput

GitHub velocity is extreme (Jan 2025: 1039 PRs / 401 issues / 694 contributors), and the team is landing meaningful fixes (vision provider handling, Telegram message collisions, service double-start prevention), yet recurring breakpoints (Windows installs, provider auth failures, Twitter client bugs) threaten the reliability narrative required for developer trust.

Do we formally shift from “feature absorption” to a stability gate (release train + stricter merge criteria) until core install and provider reliability meet a defined threshold?

GitHub monthly metrics: "1039 new PRs (735 merged), 401 new issues, and 694 active contributors." (elizaos/eliza, 2025-01-01..02-01)
Discord: "Installation challenges persist, particularly on Windows systems, with many users recommending Ubuntu instead." (2025-01-30 highlights)

1Yes—declare a 2–4 week “Stability Corridor” with a release train, freeze non-critical features, and enforce CI/test coverage for core + top clients.

Improves perceived reliability quickly, but may slow ecosystem/plugin momentum and frustrate contributors.

2Partially—keep feature intake open, but require stability gates only for core runtime, adapters, and top-3 clients (Twitter/Discord/Telegram).

Balances momentum and trust, but leaves long-tail breakages that can still damage brand reputation.

3No—optimize for velocity; rely on community to triage breakages and accept instability as the price of scale.

Maximizes growth but risks violating “Execution Excellence,” driving serious builders to more stable alternatives.

4Other / More discussion needed / None of the above.

Which single developer-facing reliability pain should be treated as a flagship “trust repair” deliverable: Windows install, model-provider stability (DeepSeek/Anthropic/Twitter), or database/embeddings coherence?

Issues cited: "Twitter login failures (#3112), connection problems with the Anthropic model (#3079), authentication failures with the Deepseek API (#3013)." (repo issues summary)
Discord: "Fix the issue with embedding dimension mismatch (384 vs 1536)." (action items, 2025-01-30 coders)
Discord: "Improve ElizaOS Windows installation process" (Shelia, ideas-feedback-rants, 2025-01-30)

1Windows installation (and WSL2) as the primary trust repair target, with an official supported path and CI coverage.

Broadens adoption and reduces onboarding friction, improving DX at the top of the funnel.

2Model-provider stability (Twitter auth + Anthropic/DeepSeek) as primary, because it affects running agents in production.

Reduces public-facing agent failures and reputational damage, reinforcing “reliability” claims.

3Database/embeddings coherence (Postgres/Supabase schemas, dimension mismatches) as primary, because it impacts persistence and RAG correctness.

Strengthens the “agent OS” foundation, but may be less visible to new developers than installation fixes.

4Other / More discussion needed / None of the above.

How should we contain plugin ecosystem entropy (huge plugin surface area, frequent lint/test churn) while preserving composability?

Daily GitHub: "A significant number of PRs were dedicated to fixing linting issues across various plugins" (2025-01-30 repo updates)
Discord action item: "Add configuration to select only needed plugins" (v1xingyue, 2025-01-30)

1Introduce “Core vs Registry” tiering: core ships only a minimal stable set; everything else moves to registry with versioned compatibility.

Reduces breakage risk and install size, but requires governance and tooling for compatibility guarantees.

2Keep monorepo breadth, but enforce automated lint/test + a plugin CI matrix and deprecate noncompliant plugins.

Improves quality without changing structure, but increases CI cost and maintainer burden.

3Adopt a “curated presets” approach: ship stable bundles (e.g., social, trading, governance) and let advanced users assemble custom stacks.

Improves DX while keeping composability, but adds product surface area that must itself be maintained.

4Other / More discussion needed / None of the above.

Treasury Conduct, Partner Tributes, and Governance Legibility

A treasury management incident (selling donated/tribute tokens) triggered a legitimacy crisis; leadership justified emergency measures (protecting ai16z liquidity, funding $3–4M/year burn), but partners/community demanded clearer constraints. DUNA and Realms-based governance are emerging as structure, alongside a proposal for retroactive contributor airdrops using a basket of treasury tokens.

What treasury doctrine should be encoded for “tribute” tokens to prevent recurring partner conflict while preserving operational runway?

Discord: "Significant controversy emerged when Shaw ... sold tokens ... donated to the ai16z treasury" (2025-01-30 highlights)
witch: "Is the tribute system working properly? A: No, it's broken and needs to be fixed" (🥇-partners, 2025-01-30)
shaw: emergency measures to fund development ($3–4M/year) and protect token/liquidity (discussion/associates, 2025-01-29..30)

1Hard non-sale covenant for tributes (unless explicit partner contract allows), defaulting to holding or LP provisioning only.

Maximizes partner trust but may constrain treasury flexibility during crises.

2Contractualized partner fee/tribute program: partners choose a predefined policy (sell/hold/LP/streamed vest) at tribute time.

Creates clarity and reduces social conflict, but requires legal/contract engineering and enforcement.

3Treasury discretion retained, but with mandatory public policy + post-trade reporting and community veto windows.

Preserves flexibility, but ongoing ambiguity may continue to erode partner confidence.

4Other / More discussion needed / None of the above.

Should DUNA be accelerated as a “trust anchor” now, even if it introduces operational overhead and forces faster policy decisions?

Rabbidfly: "DUNA ... protects DAOs while allowing for-profit activities and reasonable compensation" (2025-01-30 partners)
Discord: "The DAO is pursuing a DUNA legal structure in Wyoming" (2025-01-29..30 highlights)

1Yes—prioritize DUNA immediately to establish legal clarity, fiduciary norms, and partner confidence.

Stabilizes external relationships and governance narrative but consumes leadership bandwidth.

2Proceed in parallel at moderate speed while first fixing tribute policy and operational transparency controls.

Reduces immediate friction while still moving toward legal structure without derailing product execution.

3Defer DUNA until after core product milestones (Cloud + stability) to avoid governance process drag.

Maximizes shipping velocity now, but leaves governance legitimacy exposed during further treasury events.

4Other / More discussion needed / None of the above.

How should retroactive contributor rewards be structured to strengthen developer-first incentives without creating perceived pay-to-play token complexity?

shaw: "retroactive airdrop system ... developers would receive a basket of treasury tokens" (🥇-partners, 2025-01-30)
Discord: ongoing confusion about partner requirements and token narratives (associates/discussion, 2025-01-29..30)

1Implement basket-based retroactive airdrops with simple scoring (merged PRs/reviews/issues), plus clear disclosure and opt-out.

Aligns contributors with ecosystem projects while maintaining openness if explained well.

2Use stable, single-asset contributor grants (or salaries) and keep partner tokens separate from developer compensation.

Reduces complexity and controversy, but weakens alignment between devs and partner ecosystem.

3Hybrid: small stable grants + optional “alignment allocation” of partner tokens for contributors who opt in.

Balances clarity and alignment, but requires more administrative and technical machinery.

4Other / More discussion needed / None of the above.

Taming Information: Automated Comms, Q&A Extraction, and Trust Through Documentation

Information infrastructure is becoming a strategic lever: Jin’s AI news aggregator and Discord Q&A extraction efforts can reduce support load and improve agent quality, but reliability gaps (aggregator daily.json not updating) and unclear official messaging (ElizaOS vs ai16z token identity) threaten confidence.

Should the Council treat “Information Taming” systems (news aggregator + Q&A pipeline) as a core product deliverable with SLOs, rather than an auxiliary community project?

jin: "demonstrated an AI-powered news aggregator that automatically generates ecosystem newsletters" (🥇-partners, 2025-01-30)
boom: "Fix the AI news aggregator that's not updating its daily.json file" (3d-ai-tv action items, 2025-01-30)
dankvr: shared process for extracting Q&A from dev channels to enhance documentation for LLMs (Twitter activity summary, 2025-01-30)

1Yes—promote it to a core reliability target with uptime/refresh SLOs and an owner, because it feeds docs and agent correctness.

Strengthens DX and reduces support overhead, but diverts resources from framework runtime work.

2Partially—support it as a reference implementation (flagship internal agent) but do not guarantee SLOs yet.

Keeps momentum without binding commitments, but failures may still reflect poorly if treated as “official.”

3No—keep it community-run until core platform stability is achieved; focus on docs improvements directly in the repo.

Protects core roadmap focus, but misses an opportunity to operationalize “documentation as a first-class citizen.”

4Other / More discussion needed / None of the above.

How do we resolve identity confusion (ElizaOS brand vs $ai16z token) to reduce onboarding and marketing friction during rebrand and token-related operations?

Discord: "rebranded to ElizaOS ... while maintaining ai16z as the token ticker, causing some marketing confusion" (2025-01-29 highlights)
Smedroc: "It's definitely not $Eliza... ai16z until further notice" (associates, 2025-01-30)
Action item: "Complete X account rebranding ... and clearly indicate $ai16z as the token" (HoneyBadger/Burtiik, 2025-01-30)

1Adopt a strict naming schema across all surfaces (docs, X bios, website): “ElizaOS (framework/cloud), $ai16z (token)” with a single canonical explainer.

Reduces confusion quickly and reinforces credibility, but may constrain future ticker changes.

2Accelerate ticker/name change to unify brand and token identity, even if it introduces coordination risk.

Long-term coherence improves, but execution risk is high and may amplify short-term confusion.

3Defer messaging cleanup until post-launchpad/tokenomics release; tolerate ambiguity for speed.

Minimizes immediate work, but ongoing confusion undermines trust and partner/business development.

4Other / More discussion needed / None of the above.

What is the Council’s stance on converting Discord support patterns into “agent-readable doctrine” (FAQ/RAG-ready docs), and how aggressively should we automate it?

jin: "extracted questions and answers from chat history going back to 12-10-24" (discussion/associates, 2025-01-30)
dankvr: "extracting Q&A from developer channels to enhance documentation for LLMs" (Twitter activity summary, 2025-01-30)
Discord recurring issues: Windows install, embeddings mismatch, provider config questions (💻-coders, 2025-01-30)

1High automation: nightly ingestion + dedup + human review queue; publish as versioned FAQ datasets for agents and docs.

Rapidly improves support and agent performance, but requires editorial governance to prevent misinformation.

2Moderate automation: weekly curated releases only, prioritizing the top 20 recurring issues and official fixes.

Maintains accuracy and trust, though slower to capture emergent edge cases.

3Manual-only: keep Q&A extraction as ad hoc human documentation work to minimize accidental policy drift.

Ensures tight control, but scales poorly and undermines the “Taming Information” strategic advantage.

4Other / More discussion needed / None of the above.

North Star & Strategic Context

Key Deliberations