# Council Briefing: 2025-01-25

## 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.

## Daily 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.

## Key Points for Deliberation

### 1. Topic: Execution Excellence vs Plugin Proliferation

**Summary of Topic:** 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.

#### Deliberation Items (Questions):

**Question 1:** Should the Council impose a temporary “stability gate” on new plugins to protect reliability and developer trust?

  **Context:**
  - `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.`

  **Multiple Choice Answers:**
    a) Yes—freeze new plugin merges for a short window and focus on build/install, client reliability, and docs.
        *Implication:* Improves trust and reduces churn, but may slow ecosystem expansion momentum.
    b) Partially—allow new plugins only if they include tests, README, and pass a standardized compatibility matrix.
        *Implication:* Preserves velocity while shifting contributors toward quality signals and repeatable release hygiene.
    c) No—continue merging broadly and rely on community-driven fixes and fast iteration.
        *Implication:* Maximizes growth and novelty, but risks increasing support burden and reputational damage from breakages.
    d) Other / More discussion needed / None of the above.

**Question 2:** 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?

  **Context:**
  - `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.`

  **Multiple Choice Answers:**
    a) Install success rate (fresh machine) as the top metric.
        *Implication:* Directly improves developer onboarding and reduces Discord support load.
    b) CI green rate and reproducible builds as the top metric.
        *Implication:* Stabilizes contributions at scale and prevents regressions from high-volume merging.
    c) End-to-end agent reliability (real clients + actions) as the top metric.
        *Implication:* Aligns to real-world deployments, but requires more complex test harnesses and observability.
    d) Other / More discussion needed / None of the above.

**Question 3:** Where should “non-core” capability expansion live to remain composable without destabilizing the framework: monorepo, external plugin registry, or curated “blessed” set?

  **Context:**
  - `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).`

  **Multiple Choice Answers:**
    a) Keep most new plugins external (registry-first), with strict versioning and compatibility badges.
        *Implication:* Limits blast radius and clarifies support expectations, but adds coordination overhead.
    b) Maintain a small curated “blessed” plugin set in-repo; everything else external.
        *Implication:* Creates a stable, trusted path for newcomers while still supporting long-tail experimentation.
    c) Continue integrating broadly into the monorepo for unified tooling and faster iteration.
        *Implication:* Simplifies discovery and integration, but increases coupling and regression risk.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Developer Experience Hotspots (Embeddings, Node, Twitter Behavior)

**Summary of Topic:** 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.

#### Deliberation Items (Questions):

**Question 1:** Should the Council mandate a single “golden path” configuration (blessed Node version + embedding provider + minimal clients) with hard validation at startup?

  **Context:**
  - `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.”`

  **Multiple Choice Answers:**
    a) Yes—enforce a golden path and fail fast with explicit remediation steps.
        *Implication:* Reduces support load and increases install success, but constrains advanced setups.
    b) Offer golden path presets, but keep permissive defaults and warnings rather than hard failures.
        *Implication:* Balances accessibility and flexibility, though some users will still fall into misconfig traps.
    c) No—keep configuration flexible and rely on docs/community troubleshooting.
        *Implication:* Supports power users, but perpetuates repeated onboarding pain and inconsistent outcomes.
    d) Other / More discussion needed / None of the above.

**Question 2:** How should we resolve embedding dimension mismatches structurally: automatic DB migration/segmentation, forced DB reset, or per-provider vector namespaces?

  **Context:**
  - `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).`

  **Multiple Choice Answers:**
    a) Implement per-provider vector namespaces (or separate tables) and prevent cross-dimension mixing.
        *Implication:* Eliminates a class of errors long-term, but requires schema and retrieval updates.
    b) Auto-detect dimension changes and perform guided migration or rebuild of embeddings.
        *Implication:* Improves UX significantly, though complex to implement reliably across adapters.
    c) Document and standardize the “delete db and rebuild” recovery pattern.
        *Implication:* Fast to ship, but shifts operational burden to users and undermines reliability perception.
    d) Other / More discussion needed / None of the above.

**Question 3:** Should Twitter client behavior controls (reply-only, retweet disable, rate limiting) be promoted to first-class config rather than code edits?

  **Context:**
  - `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.`

  **Multiple Choice Answers:**
    a) Yes—add explicit config flags for reply-only, retweet/like toggles, and rate limits; deprecate code-edit instructions.
        *Implication:* Reduces accidental misbehavior and aligns with developer-first reliability.
    b) Partially—provide a few high-demand toggles now and keep advanced behavior as code-level customization.
        *Implication:* Delivers quick wins while preserving flexibility, but leaves some recurring support gaps.
    c) No—keep behavior control in code for maximum composability.
        *Implication:* Maintains power-user freedom, but increases fragmentation and “tribal knowledge” dependencies.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Model & Trust Stack Direction (DeepSeek + TrustDB + Tokenomics)

**Summary of Topic:** 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.”

#### Deliberation Items (Questions):

**Question 1:** Should DeepSeek support be treated as a priority “reference integration” (docs + presets + testing) to strengthen the open, developer-friendly narrative?

  **Context:**
  - `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.`

  **Multiple Choice Answers:**
    a) Yes—make DeepSeek a first-class preset with recommended settings, JSON/tool-calling guidance, and CI coverage.
        *Implication:* Strengthens OSS positioning and reduces inference cost barriers, but adds support surface.
    b) Ship as “supported but not blessed” via OpenRouter, focusing on core stability first.
        *Implication:* Keeps focus on reliability while still enabling the community to experiment.
    c) Defer—avoid expanding model matrix until v2/plugin architecture stabilizes.
        *Implication:* Reduces near-term complexity, but risks missing momentum around open models.
    d) Other / More discussion needed / None of the above.

**Question 2:** Should TrustDB become a core extension (standard interface + adapter support) to anchor agent verification without central registries?

  **Context:**
  - `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)`

  **Multiple Choice Answers:**
    a) Yes—standardize TrustDB interfaces now and ship a minimal, audited core extension.
        *Implication:* Establishes a unique trust primitive and supports governance narratives, but requires careful security review.
    b) Keep TrustDB experimental as an external module until schema and adapter maturity is proven.
        *Implication:* Avoids locking design too early, but delays ecosystem-wide interoperability for trust signals.
    c) Replace with simpler offchain verification patterns for now (signatures/attestations) and revisit later.
        *Implication:* Speeds delivery, but risks losing differentiation around decentralized trust.
    d) Other / More discussion needed / None of the above.

**Question 3:** 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?

  **Context:**
  - `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).`

  **Multiple Choice Answers:**
    a) Ship a simple model first (bonding curve/dual pool), then iterate based on adoption and data.
        *Implication:* Maximizes time-to-market and clarity, but may leave trust/quality problems under-addressed.
    b) Pursue a hybrid: simple launch mechanics plus optional staking/delegation for trust signaling (no slashing initially).
        *Implication:* Balances usability and alignment while avoiding the hardest enforcement problems early.
    c) Design the full staking/delegation + enforcement system before shipping to ensure long-term alignment.
        *Implication:* May yield stronger incentives, but increases complexity and delays—risking developer churn.
    d) Other / More discussion needed / None of the above.