# Council Briefing: 2025-02-21

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

- Core capability expansion (new model/RPC integrations and improved CLI/docs) advanced meaningfully, but immediate developer trust is threatened by unresolved knowledge/RAG correctness and WebSearchService usability gaps surfaced in new issues.

## Key Points for Deliberation

### 1. Topic: Reliability Breach: Knowledge/RAG & WebSearch Usability

**Summary of Topic:** Two high-signal issues indicate the framework can fail at its most visible promise—answering from provided knowledge and improving output quality via WebSearch—creating a direct risk to Execution Excellence and builder trust.

#### Deliberation Items (Questions):

**Question 1:** Do we treat “agent ignores provided knowledge” as a release-blocking defect for upcoming platform milestones, even if it delays new capability shipping?

  **Context:**
  - `github_summaries_daily_2025-02-21: "Needs Attention" — Issue #3628: "The agent is not responding based on provided knowledge"`

  **Multiple Choice Answers:**
    a) Yes—declare it a P0 and gate releases until fixed and regression-tested.
        *Implication:* Reinforces Execution Excellence and reduces churn, but slows feature velocity short-term.
    b) No—ship features, but allocate a parallel strike team with a hard SLA for the fix.
        *Implication:* Preserves momentum while still signaling seriousness; risk if SLA slips and trust erodes.
    c) Depends on scope—triage as configuration/documentation unless reproducible as core bug.
        *Implication:* Avoids overreacting to misconfigurations, but risks appearing dismissive if it is systemic.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the Council’s preferred “truth model” for knowledge grounding: strict citation-backed answers, or best-effort answers with softer guarantees?

  **Context:**
  - `Issue #3628: "agent isn't responding based on the provided knowledge."`

  **Multiple Choice Answers:**
    a) Strict grounding mode (citations/quotations required when knowledge is enabled).
        *Implication:* Higher trust and debuggability; may reduce fluency and require clearer UX/settings.
    b) Hybrid mode (grounded when confidence is high; otherwise transparently disclaim).
        *Implication:* Balances UX and reliability, but requires careful confidence heuristics and messaging.
    c) Best-effort mode (opt-in strictness only for regulated/mission-critical agents).
        *Implication:* Fastest path for general builders, but increases risk of silent hallucination under RAG.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we operationalize “tweet quality” and WebSearchService guidance so builders stop asking for bespoke help and the system self-corrects?

  **Context:**
  - `github_summaries_daily_2025-02-21: Issue #3626: "A user needs assistance with integrating WebSearchService for tweet quality"`

  **Multiple Choice Answers:**
    a) Write a canonical WebSearchService + “tweet-quality” recipe page with examples and defaults.
        *Implication:* Reduces support load immediately and aligns with Developer First; requires doc ownership.
    b) Bake opinionated defaults into the Twitter client and expose only minimal knobs.
        *Implication:* Improves out-of-box experience, but may frustrate advanced builders needing control.
    c) Create a “quality evaluation” plugin (scoring + rewrite loop) and document that workflow.
        *Implication:* More powerful and extensible, but increases complexity and time-to-value.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Capability Expansion: New Providers & Cross-Chain Defaults

**Summary of Topic:** Secret AI LLM and NEAR AI Inference API support plus standardized RPC defaults broaden composability, but the Council must ensure these additions don’t dilute stability or complicate support during an execution-focused directive.

#### Deliberation Items (Questions):

**Question 1:** What is the Council’s policy for adding new model providers: “ecosystem breadth” now, or “stability-first” with a smaller blessed set until Cloud is fully hardened?

  **Context:**
  - `github_summaries_daily_2025-02-21: PR #3615 "Support for Secret AI LLM provider added"`
  - `github_summaries_daily_2025-02-21: PR #3275 "NEAR AI Inference API integrated"`

  **Multiple Choice Answers:**
    a) Stability-first: freeze new providers except critical ones until reliability KPIs are met.
        *Implication:* Tightens quality and support burden; may slow ecosystem partners expecting integrations.
    b) Balanced: allow providers behind “experimental” flags with clear support boundaries.
        *Implication:* Preserves innovation while protecting core UX; requires disciplined labeling and docs.
    c) Breadth-first: keep integrating aggressively to win mindshare and chain alliances.
        *Implication:* Maximizes reach, but risks fragmentation and regressions that undermine trust-through-shipping.
    d) Other / More discussion needed / None of the above.

**Question 2:** Do we want a single “default RPC doctrine” (like Lava) across chains, or per-chain best-of-breed selection with explicit transparency?

  **Context:**
  - `github_summaries_daily_2025-02-21: PR #3323 "Default RPC URL for NEAR and Starknet set to Lava"`

  **Multiple Choice Answers:**
    a) Single doctrine: standardize on Lava (or one provider) wherever possible.
        *Implication:* Simplifies docs and support, but concentrates operational risk in one dependency.
    b) Per-chain best-of-breed with a published rubric (latency, uptime, terms, censorship-resistance).
        *Implication:* More resilient and mission-aligned, but increases maintenance and communication overhead.
    c) Let builders choose; provide no defaults beyond “localhost/testnet” templates.
        *Implication:* Maximum flexibility, but worsens new-user onboarding and increases misconfiguration incidents.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Developer Experience: Plugin Ecosystem & Operator Tooling

**Summary of Topic:** The plugin registry path is becoming the backbone of composability; recent fixes, a plugin showcase page, and new agent/character CLI methods are positive, but the ecosystem still needs hardened workflows and clearer “source of truth” documentation to reduce setup friction.

#### Deliberation Items (Questions):

**Question 1:** Should we formalize the plugin registry as the canonical distribution channel and enforce compatibility/testing requirements for registry admission?

  **Context:**
  - `Daily Report 2025-02-20: "Fixed issues with importing and installing plugins from the registry (PRs #3611, #3609)"`
  - `Discord 2025-02-20: "moved away from hosting plugins in the main repository to a new plugin registry system"`

  **Multiple Choice Answers:**
    a) Yes—introduce a strict admission gate (tests, metadata, versioning, security checks).
        *Implication:* Improves reliability and trust, but raises the bar for community contributions.
    b) Partially—two-tier registry: “verified” and “community” with different guarantees.
        *Implication:* Maintains openness while clarifying risk, but requires governance and UI signaling.
    c) No—keep it lightweight and rely on social trust + rapid patching.
        *Implication:* Fast growth, but higher incidence of breakage that harms developer-first objectives.
    d) Other / More discussion needed / None of the above.

**Question 2:** How should we prioritize “operator ergonomics” (CLI/server refactors) versus end-user features in the near term?

  **Context:**
  - `github_summaries_daily_2025-02-21: PR #3613 "New CLI commands implemented for managing agents and characters"`

  **Multiple Choice Answers:**
    a) Prioritize operator ergonomics now (CLI + debugging + reproducible deploys) as a force multiplier.
        *Implication:* Reduces support burden and speeds all future development; may delay flashy features.
    b) Split the roadmap: keep 1–2 flagship features shipping while hardening tooling in parallel.
        *Implication:* Balances perception and substance, but requires disciplined release coordination.
    c) Defer tooling improvements; focus on features and let power users self-manage complexity.
        *Implication:* Short-term excitement, but risks compounding maintenance debt and onboarding failures.
    d) Other / More discussion needed / None of the above.

**Question 3:** Do we elevate documentation artifacts (like the plugin showcase) into a “Council-controlled truth beacon” with explicit ownership and update SLAs?

  **Context:**
  - `github_summaries_daily_2025-02-21: PR #3620 "Plugin Showcase documentation page introduced"`

  **Multiple Choice Answers:**
    a) Yes—treat docs as product, assign owners, and require docs updates with breaking changes.
        *Implication:* Directly advances Developer First and Trust Through Shipping; increases process overhead.
    b) Somewhat—prioritize only onboarding + troubleshooting docs for SLAs; keep the rest community-led.
        *Implication:* Targets the biggest pain points while staying open; may leave gaps in advanced areas.
    c) No—keep docs emergent; rely on Discord and community support to fill gaps.
        *Implication:* Lowest internal cost, but repeats the “scattered information” failure mode the mission opposes.
    d) Other / More discussion needed / None of the above.