# Council Briefing: 2025-03-20

## 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 prioritized stabilization and developer trust: high-volume UI/CLI bugfixes landed while new issues were rapidly triaged/closed, but core adoption friction (RAG + dependency/version mismatches) remains a strategic choke point.

## Key Points for Deliberation

### 1. Topic: V2 Beta Launch Readiness vs. Stability Debt

**Summary of Topic:** Engineering velocity is high (multiple UX/CLI fixes merged; issue triage closed same-day), yet the beta narrative is still “works, but unstable,” risking developer confidence during the refactor-induced turbulence.

#### Deliberation Items (Questions):

**Question 1:** Do we hold the V2 line until a “golden path” install/start flow is deterministic for 90%+ of new builders, even if it delays ecosystem rollouts (Spartan, marketplace, hackathons)?

  **Context:**
  - `Discord (rhota): "Beta phase will last about 2 weeks" and "remains somewhat unstable" after repo consolidation.`
  - `GitHub: "Fixed CLI agent command" (#4028) and "Added validation and testing for CLI commands" (#4004).`

  **Multiple Choice Answers:**
    a) Yes—gate V2 on a hardened golden path (install → create → start → deploy) with strict release criteria.
        *Implication:* Maximizes trust through shipping and reduces support load, but slows downstream launches.
    b) No—ship on schedule and rely on rapid patch cadence plus community support to absorb instability.
        *Implication:* Maintains momentum and narratives, but risks reputation damage if early adopters churn.
    c) Hybrid—ship V2 as “preview” while maintaining a clearly supported stable track (0.25.9/1.x) with explicit migration windows.
        *Implication:* Preserves velocity without abandoning reliability, but requires disciplined comms and dual-track maintenance.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the Council’s preferred strategy for dependency/version fragmentation (e.g., plugin-sql mismatches) to prevent repeated install failures across the ecosystem?

  **Context:**
  - `Discord: "No matching version found for @elizaos/plugin-sql@^0.25.6" reported by multiple users; suggested pinning CLI beta versions.`
  - `GitHub top issues: dependency/version mismatch issue (#4101) was opened and later closed (March window).`

  **Multiple Choice Answers:**
    a) Enforce monorepo-pinned versions and a single blessed package set per release (lockstep).
        *Implication:* Reduces user confusion and support costs, but increases coordination overhead across packages.
    b) Adopt strict semver + compatibility matrix tooling, allowing multiple supported combinations.
        *Implication:* Improves flexibility, but requires rigorous documentation and automated validation to avoid drift.
    c) De-scope optional plugins from default installs and move them behind explicit opt-in templates.
        *Implication:* Stabilizes first-run experience, but may slow discovery of ecosystem capabilities.
    d) Other / More discussion needed / None of the above.

**Question 3:** Where should we invest next to maximize ‘Execution Excellence’ impact: UI polish, CLI determinism, or runtime/core correctness (e.g., embeddings, adapters, RAG performance)?

  **Context:**
  - `GitHub: multiple UI/UX fixes merged (memory viewer #4027, profile UI #4021, start/create UX #4007).`
  - `Discord: repeated pain points—CLI install/start issues and knowledge/RAG reliability complaints.`

  **Multiple Choice Answers:**
    a) CLI determinism first (install/start, clear errors, environment management).
        *Implication:* Improves onboarding conversion and reduces friction for every developer, reinforcing Developer First.
    b) Runtime/core correctness first (RAG, embeddings, adapters, DB stability).
        *Implication:* Prevents ‘it runs but it lies’ failures that erode trust and break flagship agent credibility.
    c) UI polish first (builder experience, memory/knowledge tooling, multi-agent chat UX).
        *Implication:* Boosts perceived quality and demos, but may mask unresolved underlying reliability debt.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: Knowledge/RAG Reliability as a Trust Primitive

**Summary of Topic:** Knowledge ingestion and retrieval are emerging as the system’s most visible reliability fault-line (directory ambiguity, PDF workflows, adapter gaps); documentation and tooling improvements are landing, but the feature still feels probabilistic to users.

#### Deliberation Items (Questions):

**Question 1:** Should RAG/Knowledge be elevated to a “first-class contract” with strict behavioral guarantees (tests + reference datasets), even if it constrains flexibility in directory structures and adapters?

  **Context:**
  - `Discord (Sabochee): knowledge feature "seems to work 10% ok" (reported sentiment).`
  - `Discord (multiple): conflicting advice on knowledge paths (e.g., `characters/knowledge/...` vs `./knowledge/...`).`

  **Multiple Choice Answers:**
    a) Yes—define a single canonical knowledge pipeline and enforce it with integration tests and fixtures.
        *Implication:* Transforms RAG from folklore into a reliable product surface, aligning with Execution Excellence.
    b) No—keep the pipeline flexible and prioritize documentation/examples over rigid contracts.
        *Implication:* Preserves composability but risks continued “it depends” support burden and trust erosion.
    c) Partial—guarantee core ingestion/retrieval semantics while allowing multiple directory layouts via explicit configuration.
        *Implication:* Balances reliability with composability, but requires precise DX and config validation.
    d) Other / More discussion needed / None of the above.

**Question 2:** What is the Council’s preferred approach to PDF knowledge ingestion: mandate preprocessing to markdown/text, or ship an official PDF pipeline that is robust by default?

  **Context:**
  - `Discord (Midas): "Folder2knowledge — knowledge2character" converts PDFs to plain text then to character knowledge.`
  - `Discord: PDF + RAG issues repeatedly cited as a common pain point.`

  **Multiple Choice Answers:**
    a) Mandate preprocessing (PDF → text/markdown) and keep core minimal; provide scripts and guardrails.
        *Implication:* Reduces complexity in core and improves determinism, but adds steps for end users.
    b) Ship an official, batteries-included PDF pipeline (extraction + chunking + embedding) with sane defaults.
        *Implication:* Improves out-of-box success and demos, but increases maintenance surface and edge-case load.
    c) Dual-path: official pipeline for common PDFs plus explicit advanced hooks for custom extraction.
        *Implication:* Covers mainstream needs while retaining composability, but requires careful DX to avoid confusion.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we operationalize “Taming Information” internally: do we treat docs tooling (llms.txt, mermaid maps, doc-chat) as critical infrastructure with dedicated ownership and SLAs?

  **Context:**
  - `GitHub: docs frontpage improvements + llms.txt added (#3991); docs versioning (#3963).`
  - `Discord (jin): improving doc navigation with mermaid flow charts; requests for clearer onboarding (incl. Chinese community).`

  **Multiple Choice Answers:**
    a) Yes—create a Docs & DX guild with explicit metrics (time-to-first-agent, doc freshness, issue deflection).
        *Implication:* Turns documentation into a compounding asset and reduces operational chaos across channels.
    b) No—keep docs community-driven and opportunistic; prioritize code shipping.
        *Implication:* Maximizes short-term feature velocity, but perpetuates support load and fragmented knowledge.
    c) Hybrid—core team owns onboarding/golden paths; community owns long-tail pages with curated review cycles.
        *Implication:* Maintains focus while leveraging open-source energy, but needs governance and editorial processes.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Flagship Agents, Public Trust, and Token Utility Alignment

**Summary of Topic:** Spartan’s functionality is tightly coupled to V2 stability, while token utility discussions are active but not yet grounded in shipped mechanisms; public information asymmetry (private holder channels vs broader community) risks undermining trust-through-shipping.

#### Deliberation Items (Questions):

**Question 1:** Should Spartan (and other flagship agents) be treated as release-blocking acceptance tests for V2, rather than post-launch integrations?

  **Context:**
  - `Discord (rhota): focus is "getting Spartan working" after merging repos; beta ~2 weeks.`
  - `Discord (Odilitime): "trying to get spartan chatting before the v2 official launch".`

  **Multiple Choice Answers:**
    a) Yes—flagship agents are the proof-of-reliability; if they fail, V2 is not ready.
        *Implication:* Strengthens trust and sets quality bar, but may slow platform release cadence.
    b) No—ship platform first; flagship agents can lag and stabilize independently.
        *Implication:* Increases platform velocity, but weakens narrative and real-world validation of the framework.
    c) Split—define a minimal flagship capability set (chat + knowledge + one client) as blocking; advanced features can follow.
        *Implication:* Creates an achievable quality gate while preserving momentum for iterative improvements.
    d) Other / More discussion needed / None of the above.

**Question 2:** What token utility direction best aligns with the North Star (developer-friendly infra) without turning ElizaOS into a commodity compute reseller?

  **Context:**
  - `Discord (Patt): token as commodity for paying for compute; comparisons to Venice AI staking model.`
  - `Discord (DorianD): skepticism about compute reselling; push for token integration into agent functionality.`

  **Multiple Choice Answers:**
    a) Compute/payment utility first (API credits, discounts, staking-to-inference power).
        *Implication:* Simple and legible, but risks positioning ElizaOS as a wrapper/reseller rather than a protocol.
    b) Security/quality utility first (staking to secure plugins/agents, reputation, slashing for non-delivery).
        *Implication:* Aligns incentives with ecosystem reliability, but requires careful governance design and legal/UX considerations.
    c) Identity/registry utility first (agent registration via public keys, usage metrics, attestations).
        *Implication:* Builds composable trust fabric for a decentralized agent economy, but value accrual may be slower to surface.
    d) Other / More discussion needed / None of the above.

**Question 3:** How should we balance private holder experiences with public transparency to maximize community trust and developer adoption?

  **Context:**
  - `Discord (Toni): concern that private channels leave the public "no way to get any info"; rhota cites Telegram as public channel.`
  - `Discord: structured social amplification proposed (Typefully drafts → ben review → main account posting).`

  **Multiple Choice Answers:**
    a) Open-first: move status updates, roadmaps, and technical progress to public channels; keep only product perks private.
        *Implication:* Maximizes developer trust and reduces rumor cycles, but may reduce perceived holder exclusivity.
    b) Holder-first: keep core updates in private channels and publish curated summaries when ready.
        *Implication:* Strengthens holder retention, but risks alienating builders and external partners.
    c) Two-lane comms: public weekly engineering briefings + private “alpha features” access, with clear boundaries.
        *Implication:* Preserves exclusivity while maintaining credibility, but requires disciplined publishing cadence.
    d) Other / More discussion needed / None of the above.