# Council Briefing: 2025-01-22

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

- The fleet expanded capability surface area via new plugins and fixes, but the Council’s critical pressure point is execution excellence: stabilizing CI, installs, and safety/compliance so growth translates into developer trust rather than entropy.

## Key Points for Deliberation

### 1. Topic: Execution Excellence: CI, Install Reliability, and Release Discipline

**Summary of Topic:** GitHub activity remains high and feature velocity continues, but persistent install/startup failures and CI flakiness threaten the North Star of reliability and the Monthly Directive’s emphasis on trust through shipping.

#### Deliberation Items (Questions):

**Question 1:** Should the Council impose a temporary “stability gate” (merge/release constraints) until CI and top install/startup issues are reduced?

  **Context:**
  - `GitHub daily update (2025-01-22): "Integration tests are failing in CI ... despite passing locally." (#2663)`
  - `GitHub activity update (Jan 22-23): "37 new pull requests with 12 merged" (merge rate dropped vs prior day).`

  **Multiple Choice Answers:**
    a) Yes—activate a stability gate: prioritize CI + top onboarding issues; defer new plugins unless critical.
        *Implication:* Improves developer trust and support load, but slows ecosystem expansion and partner momentum.
    b) No—keep current throughput; fix CI in parallel and rely on community triage.
        *Implication:* Maintains growth narrative, but risks compounding breakage and eroding DX with each release.
    c) Hybrid—gate only the release branch (main), allow develop to accept features with stricter test requirements.
        *Implication:* Preserves innovation while protecting production stability, at the cost of heavier release engineering.
    d) Other / More discussion needed / None of the above.

**Question 2:** Which operational metric should be treated as the Council’s primary “reliability beacon” for the next cycle?

  **Context:**
  - `GitHub issues summary: "Installation issues ... startup failures ... connectivity issues" (e.g., #2624, #2652, #2623, #2613, #2622, #2648).`

  **Multiple Choice Answers:**
    a) Time-to-First-Working-Agent (fresh install to first response) across OS targets (Win/macOS/Linux).
        *Implication:* Directly optimizes onboarding and adoption, aligning with Developer First and execution excellence.
    b) CI pass rate + mean time to green for integration tests on main/develop.
        *Implication:* Strengthens shipping cadence and reduces regressions, enabling Cloud/flagship stability downstream.
    c) Support burden proxy: weekly count of repeated Discord troubleshooting incidents (Docker/DB/Twitter).
        *Implication:* Turns community pain into prioritization fuel, but may lag behind latent engineering risk.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should ElizaOS govern plugin ingestion to avoid quality dilution while remaining open and composable?

  **Context:**
  - `Discord (partners/coders): repeated troubleshooting across Docker, DB adapters, and clients; request for better plugin PR templates (DorianD).`
  - `Discord (partners): "Partners discussed the need for better documentation of plugins and their capabilities, as many PRs have minimal descriptions."`

  **Multiple Choice Answers:**
    a) Introduce tiering: “Core-certified” plugins vs “Community” plugins with automated checks and required READMEs.
        *Implication:* Creates clarity and trust for builders while keeping the ecosystem open, but adds governance overhead.
    b) Keep a single registry but enforce a strict PR template: tests + docs + maintainer sponsor required.
        *Implication:* Raises baseline quality without fragmenting the ecosystem, but may reduce casual contributions.
    c) Decentralize: accept broadly into repo/registry, but add telemetry-based “reliability scoring” surfaced in docs/CLI.
        *Implication:* Aligns incentives via usage/health signals, but allows unstable plugins to exist and potentially harm perception.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Compliance & Platform Risk: Telegram Policy Shift + Social Media Ethics

**Summary of Topic:** A near-term external shock looms: Telegram’s policy change restricting third-party blockchains (non-TON) plus rising scrutiny on “unethical use” of agents on social platforms; both can strand integrations and threaten distribution channels.

#### Deliberation Items (Questions):

**Question 1:** What is our response posture to Telegram’s February enforcement window—retreat, adapt, or reroute distribution?

  **Context:**
  - `Discord (2025-01-21): "Kirsten warned about Telegram's updated terms of service ... restricting 'third-party blockchains' aside from TON, with enforcement starting February 21."`

  **Multiple Choice Answers:**
    a) Retreat: deprecate or pause Telegram blockchain features; focus on compliant chat-only mode.
        *Implication:* Minimizes risk of bans but reduces Web3 differentiation and cross-chain demonstrations.
    b) Adapt: implement a Telegram compliance layer (TON-only pathways, feature flags, runtime policy enforcement).
        *Implication:* Preserves Telegram presence while aligning with ToS, but adds complexity and ongoing compliance maintenance.
    c) Reroute: shift primary distribution to Discord/X/Farcaster/others; Telegram becomes optional or enterprise-only.
        *Implication:* Protects growth from platform capture, but may alienate Telegram-heavy communities and ecosystems.
    d) Other / More discussion needed / None of the above.

**Question 2:** Should we formalize a “Responsible Agent Operations” standard (defaults, guardrails, disclosure) across social clients?

  **Context:**
  - `GitHub daily update (2025-01-22): "A new issue was raised regarding the potential for unethical use on social media platforms ... Terms of Service." (#2680)`

  **Multiple Choice Answers:**
    a) Yes—ship a baseline policy pack (rate limits, approval workflows, disclosure tags) enabled by default.
        *Implication:* Reduces platform enforcement risk and supports enterprise adoption, but may constrain degen experimentation.
    b) Optional—provide guardrails as templates/plugins; leave defaults permissive for power users.
        *Implication:* Keeps flexibility, but exposes newcomers to risky defaults and reputational fallout.
    c) No formal standard—handle case-by-case; focus engineering on core features and speed.
        *Implication:* Maximizes velocity short-term, but increases probability of ecosystem-wide bans and trust degradation.
    d) Other / More discussion needed / None of the above.

**Question 3:** Where should “policy intelligence” live: in core runtime, client plugins, or ElizaOS Cloud control plane?

  **Context:**
  - `Discord (coders): repeated client integration issues (Twitter/Telegram/Discord), rate limiting requests (mr.code).`

  **Multiple Choice Answers:**
    a) Core runtime: unified enforcement (rate limiting, action gating) regardless of client.
        *Implication:* Most consistent and developer-friendly, but risks bloating core and slowing iteration.
    b) Per-client: keep enforcement close to platform-specific rules and capabilities.
        *Implication:* Best ToS fit per platform, but creates fragmented behavior and inconsistent UX across clients.
    c) Cloud control plane: centralized policy toggles + telemetry with client adapters reading directives.
        *Implication:* Enables rapid response and governance at scale, but makes Cloud a stronger dependency for safety posture.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Model Provider Strategy: DeepSeek R1 Disruption and Provider UX Coherence

**Summary of Topic:** DeepSeek R1’s cost/performance claims and MIT license create an opportunity to improve affordability and openness, but community reports show provider configuration confusion and integration gaps; model selection must become predictable and documented to maintain trust.

#### Deliberation Items (Questions):

**Question 1:** Should DeepSeek R1 be elevated to a first-class default option for cost-efficient reasoning in ElizaOS (and/or Cloud)?

  **Context:**
  - `Discord (2025-01-21): "Deepseek R1 ... performance comparable to o1/sonnet models at 30x cheaper cost and is MIT licensed." (jin)`
  - `GitHub daily update (2025-01-22): "A request for support for the DeepSeek API was submitted." (#2658)`

  **Multiple Choice Answers:**
    a) Yes—prioritize DeepSeek integration and documentation; make it a recommended default for “small/medium reasoning.”
        *Implication:* Could dramatically reduce agent operating costs and increase adoption, but adds dependency and QA burden.
    b) Selective—support it as an advanced option; keep defaults on the most stable provider while we harden adapters.
        *Implication:* Protects reliability while capturing upside, but misses momentum and may cede mindshare to competitors.
    c) Defer—focus on provider abstraction and config correctness first, then add new models once UX is stable.
        *Implication:* Aligns with execution excellence, but delays cost improvements and “open” narrative benefits.
    d) Other / More discussion needed / None of the above.

**Question 2:** What should be the Council’s mandate for model selection correctness (character file settings vs env defaults)?

  **Context:**
  - `Discord (2025-01-20): "Model Selection Issues: character files with 'model': 'small' still default to using large models."`

  **Multiple Choice Answers:**
    a) Character file is source of truth; env vars only provide fallbacks and global defaults.
        *Implication:* Improves predictability and DX, but requires careful migration and clear error messaging.
    b) Env vars override character files to ensure operator control in production deployments.
        *Implication:* Helps ops and compliance, but confuses developers and undermines portability of agent configs.
    c) Explicit precedence model with tooling: CLI prints the resolved provider/model and why (audit trail).
        *Implication:* Reduces confusion and support load, but requires investing in introspection and UX polish.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we balance “open & composable” provider breadth with “execution excellence” quality guarantees?

  **Context:**
  - `Discord (coders): recurring provider setup friction (OpenAI/Anthropic/Gaia/DeepSeek) and env variable confusion.`
  - `GitHub daily update (2025-01-22): ongoing additions (plugins) alongside bugfixes and CI instability.`

  **Multiple Choice Answers:**
    a) Narrow the supported “blessed” providers; everything else is experimental behind flags.
        *Implication:* Higher reliability and clearer docs, but reduces composability and slows ecosystem experimentation.
    b) Keep breadth, but require conformance tests + a provider certification checklist before listing as stable.
        *Implication:* Scales openness with quality, but needs investment in automated testing and maintainer bandwidth.
    c) Outsource breadth to community plugins; core ships only abstractions and a minimal stable set.
        *Implication:* Protects core stability, but risks fragmentation and inconsistent behavior across provider implementations.
    d) Other / More discussion needed / None of the above.