Council Briefing

Key Deliberations

V2 Plugin Architecture Pivot & Build Stability

A sweeping plugin-system overhaul (including deleting monorepo plugins and shifting to dynamic loading) is strategically aligned with composability, but the transition is currently creating build and dependency hazards that erode DX trust.

Do we freeze further architectural refactors until the new dynamic plugin loading path is "boring-stable" for new developers (install → run → load character → UI)?

GitHub daily (2025-02-07): "Missing `cors` and `multer` dependencies in `@elizaos/agent` are causing build issues" (issue #3365).
GitHub daily (2025-02-07): "UI fails to load correctly when starting the service with a specific character file" (issue #3360).

1Yes—declare a stabilization window (1–2 weeks) with a hard gate: no new refactors, only build/UX blockers and docs.

Maximizes developer trust and reduces support load, but may delay V2 feature velocity.

2Partial freeze—allow refactors only if paired with tests, migration notes, and a green e2e "golden path" workflow.

Balances momentum with safety, but still risks churn if enforcement is inconsistent.

3No—continue the pivot at full speed and accept short-term instability as the cost of reaching V2.

Accelerates long-term architecture, but risks reputational damage and community burnout during the transition.

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

What is the Council’s preferred operational model for plugins post-split (elizaos-plugins org): centrally curated vs federated autonomy?

GitHub daily summary (2025-02-06): "All plugins were deleted (#3342) to support a new dynamic plugin loading system (#3339)."
Discord (2025-02-06, coders): "Eliza is moving plugins to separate repositories under elizaos-plugins organization" (Odilitime).

1Centrally curated: strict compatibility matrix, required CI, and version pinning enforced by the core team.

Improves reliability and DX, but increases governance overhead and slows plugin experimentation.

2Federated: minimal standards, community-owned plugins, and best-effort compatibility with fast iteration.

Maximizes ecosystem growth, but creates fragmentation and more breakage for builders.

3Hybrid: tiered plugin registry (Core/Verified/Community) with different guarantees and automation.

Creates a scalable trust ladder—aligns with composability while preserving execution excellence for critical paths.

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

Should Bun adoption be treated as mandatory now, or should we maintain a pnpm compatibility lane until Cloud + framework reliability targets are met?

GitHub daily (2025-02-07): "Replaced pnpm with Bun" (PR #2852).
GitHub issues mention: "pnpm build failed" style reports persisted during this period (e.g., issue #3316 in daily rollup).

1Mandatory Bun now—reduce matrix complexity and optimize for the future runtime-loading roadmap.

Simplifies core engineering but may alienate teams with locked CI/tooling or enterprise constraints.

2Dual-lane support—Bun preferred, pnpm supported via documented fallback until a defined deprecation date.

Protects DX during migration but increases maintenance overhead and can slow stabilization.

3Rollback to pnpm temporarily—only reintroduce Bun when integration tests and installer UX are mature.

De-risks short-term shipping but undermines architectural momentum and could confuse contributors.

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

Agent Reliability on Social Rails (Twitter/Embeddings/Telegram)

High-friction operational issues—Twitter auth/lockouts, rate limits, and embedding dimension mismatches—are repeatedly blocking builders, threatening the "reliable by default" promise and increasing community support burden.

Should we temporarily de-emphasize Twitter automation (posting/mentions) in the default experience until we ship safer auth + rate-limit safeguards?

Discord (2025-02-06): "Twitter authentication... aggressive login attempts causing account lockouts" (rubinovitz, efiz).
Discord Q&A (2025-02-06): "gateway timeout error on twitter" → "That's a rate limit, give it some space to breathe" (BOSSU).

1Yes—make Twitter features explicitly opt-in and disabled by default; prioritize safety guardrails.

Reduces user harm and support load, but slows growth of flagship social agents and demos.

2Keep defaults, but ship a hardened Twitter client: exponential backoff, session reuse, and clear warnings in setup.

Maintains momentum while reducing risk, but may still fail under API volatility and enforcement changes.

3Replace with alternative-first social rails (Farcaster/Telegram/Discord) and position Twitter as experimental.

Improves reliability perception, but may weaken market visibility where X is the primary distribution channel.

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

How do we enforce embedding dimension consistency across providers so that RAG and social memory do not crash at runtime?

Discord (2025-02-06, coders): "Vector dimension mismatch errors (384 vs 1536)" (engineer).
Discord Q&A (2025-02-06): fix suggestion: "Try turning on and off OpenAI embeddings" (Odilitime).

1Hard enforcement: store dimension in DB schema + block startup if configured model and DB dimension differ; auto-migrate with explicit user confirmation.

Strong reliability and predictability, but requires careful migrations and clearer error messaging.

2Soft enforcement: auto-detect and dynamically adapt by re-embedding silently when mismatches appear.

Smoother UX, but risks hidden costs (compute/time) and unclear provenance for vector stores.

3Documentation-first: provide a matrix of supported embeddings and leave enforcement to developers.

Low engineering cost, but contradicts execution excellence and keeps support load high.

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

Do we standardize a "safe-by-default" posture for credentialed integrations (X, Telegram, others) with an explicit OPSEC workflow and dev-mode sandbox accounts?

Discord (2025-02-06, discussion): "Is there a way for a dev to work on the agent without me giving them my X account password?" → "never share passwords" (BOSSU).
Action items (2025-02-06): "Create guide for setting up secure dev environments without sharing social media credentials" (Slothify⚡Daily Gmove).

1Yes—ship an official "Credential Proxy / Secrets Operator" pattern + docs + sample repos as a priority.

Builds deep trust and enterprise readiness, aligning strongly with the North Star.

2Add minimal warnings and best practices in docs, but no official workflow yet.

Fast and low-cost, but leaves users exposed and increases reputational risk if accounts are compromised.

3Defer entirely until after Cloud launch; rely on community guidance.

Preserves short-term focus, but violates "trust through shipping" and may slow adoption.

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

Governance Signal, Roadmap Clarity, and Launchpad/Tokenomics Readiness

Leadership messaging improved with the new COO and claims of 95% completion on launchpad/tokenomics, but partners and builders still experience uncertainty; we need a tighter comms cadence and a published roadmap to convert progress into trust.

Do we set a hard public roadmap checkpoint (date + scope) even if market conditions delay tokenomics/launchpad release?

Discord partners (2025-02-06): "Launchpad & tokenomics... 95% complete but awaiting better market conditions" (accelxr).
Discord partners (2025-02-06): "A CPO is putting together a roadmap... targeting next week" (accelxr).

1Yes—publish the roadmap with clear dependency flags (market-sensitive vs ship-ready engineering milestones).

Strengthens credibility and reduces rumor-driven volatility, even if releases are staged.

2Publish only engineering roadmap; keep tokenomics/launchpad timing private until conditions improve.

Reduces speculative pressure, but may prolong partner frustration about direction and utility.

3Delay roadmap until launchpad and tokenomics can be announced together for maximum narrative impact.

Optimizes marketing timing, but risks ongoing trust erosion and community fatigue.

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

What is our minimum viable communications protocol to uphold "Trust Through Shipping" across Discord/GitHub/X without overloading the core team?

Discord partners (2025-02-06): "New protocols for communicating updates across social media are being prioritized" (accelxr, witch).
Action items (2025-02-06): "Establish better communication protocols for updates across platforms" (accelxr).

1Weekly "Council Dispatch": one canonical update repo/page auto-syndicated to Discord/X/email, with owners per domain (core, cloud, flagship agents).

Creates a predictable heartbeat and reduces chaos, aligning with Taming Information goals.

2Daily micro-updates only when major PRs ship; otherwise keep comms ad-hoc.

Lower overhead, but perpetuates partner uncertainty and makes the project feel directionless.

3Delegate to community curators (with token incentives) to produce summaries, with core team only approving.

Scales communication, but requires governance controls to prevent misinformation and narrative drift.

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

How should we sequence brand unification (ElizaOS) with token identity (ai16z) to reduce confusion while preserving continuity?

Discord partners (2025-02-06): "Plans to clean up scattered branding under ElizaOS while maintaining ai16z as the token name" (accelxr).
Discord (2025-02-05): "transitioning from ai16zdao branding to elizaOS for better clarity".

1Immediate brand consolidation: one website/docs identity (ElizaOS), with clear token labeling (ai16z) and migration FAQ pinned everywhere.

Reduces onboarding friction quickly and improves developer confidence.

2Gradual migration: keep dual branding during a transition period with cross-links and a deprecation timeline.

Minimizes shock to existing holders, but sustains confusion longer.

3Token-first narrative: lead with ai16z brand and treat ElizaOS as a sub-brand until launchpad/tokenomics ship.

May help short-term market narrative, but conflicts with the goal of a developer-first framework identity.

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

North Star & Strategic Context

Key Deliberations