# Council Briefing: 2025-04-17

## 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 Council’s critical event is a trust-and-reliability stress test: auto.fun’s imminent launch is colliding with version/documentation confusion in ElizaOS, risking reputational drag precisely when we need execution excellence.

## Key Points for Deliberation

### 1. Topic: Auto.fun Launch Readiness & Trust Discipline

**Summary of Topic:** Auto.fun is confirmed to launch “this week” with meaningful differentiators (AI-generated token content, vanity contract suffixes, Raydium LP integration), but community trust is strained by a fake token incident and unclear buyback economics.

#### Deliberation Items (Questions):

**Question 1:** What is our minimum viable trust posture for launch week: ship fast with reactive comms, or delay/soft-launch until tokenomics and scam-prevention messaging are airtight?

  **Context:**
  - `Partners channel: “Auto.fun launch is happening this week” (shaw).`
  - `Partners channel: fake “auto.fun” token controversy; drainer link mentioned; “there is no fun token” (HoneyBadger).`

  **Multiple Choice Answers:**
    a) Proceed with launch as scheduled, publish a short ‘Official Links + No New Token’ bulletin and staff real-time moderation.
        *Implication:* Maximizes momentum, but depends on strong ops discipline to avoid trust bleed from confusion/scams.
    b) Soft-launch (limited creators/partners) for 48–72 hours, then public launch after monitoring scam vectors and UX friction.
        *Implication:* Preserves launch timing while reducing blast radius; may frustrate impatient community but improves reliability narrative.
    c) Delay until tokenomics/buyback mechanics and security posture are fully specified and documented.
        *Implication:* Optimizes long-term trust, but risks losing the window and undermining “Trust Through Shipping.”
    d) Other / More discussion needed / None of the above.

**Question 2:** How explicit should we be about the AI16z buyback flywheel economics at launch, given that specifics are “not finalized”?

  **Context:**
  - `Partners channel: “Revenue … will contribute to buying back AI16z tokens, though specific economics haven't been finalized” (summary; shaw).`
  - `Discord: “The plan is to make the number go up, but specific economics haven't been worked out” (shaw).`

  **Multiple Choice Answers:**
    a) Publish full provisional tokenomics (formulas, cadence, custody) with clear ‘subject to change’ disclaimers.
        *Implication:* Signals seriousness and reduces rumor space, but creates commitment pressure and legal/PR risk if changed.
    b) Publish a principle-based statement (targets, priorities, governance path) without numeric promises.
        *Implication:* Balances transparency with flexibility; still requires disciplined wording to avoid being read as a promise.
    c) Defer tokenomics detail until post-launch metrics stabilize; keep messaging focused on product utility.
        *Implication:* Avoids premature commitments, but amplifies speculation and may weaken holder alignment during launch week.
    d) Other / More discussion needed / None of the above.

**Question 3:** Do we treat scam-prevention as a product feature (default guardrails) or a community ops function (moderation and advisories) for day 1?

  **Context:**
  - `Discord summary: “Security measures to prevent scams and drainers.”`
  - `DAO-organization: “Monitor and moderate the auto.fun channel during launch” (accelxr).`

  **Multiple Choice Answers:**
    a) Product-first: implement hard guardrails (link sanitization, allowlists, warnings) as defaults before public launch.
        *Implication:* Best aligns with execution excellence; may slow release but reduces systemic risk.
    b) Ops-first: launch with moderation playbooks, pinned advisories, and rapid-response takedowns.
        *Implication:* Fastest path to shipping, but operationally intensive and more error-prone at peak attention.
    c) Hybrid: ship minimal guardrails now (pinned official links + UI warnings) and schedule deeper protections for week-2.
        *Implication:* Pragmatic compromise; requires a visible roadmap to avoid being perceived as under-secured.
    d) Other / More discussion needed / None of the above.

---


### 2. Topic: ElizaOS v2 (1.x beta) DX Fracture: Versions, Plugins, and Docs

**Summary of Topic:** Developers are colliding with version naming confusion (v0.x stable vs v1.x beta), plugin migration gaps, .env placement ambiguity, and runtime/tooling differences (npm/pnpm/bun), directly conflicting with our reliability and developer-first principles.

#### Deliberation Items (Questions):

**Question 1:** What is the Council’s policy for ‘beta exposure’: should v1.x remain discoverable by default, or should we route most builders to v0.25 stable until plugin parity is achieved?

  **Context:**
  - `Coders channel: “V2 is 1.x, v1 is 0.x” (cocaine7499).`
  - `Support guidance: “Try using v0.25 with the openai plugin… For v1.0x, we’ll let the community know when plugins have been migrated” (Kenk).`

  **Multiple Choice Answers:**
    a) Make v0.25 the primary default path; label v1.x as ‘beta—limited plugins’ across docs and CLI outputs.
        *Implication:* Reduces support load and restores trust, but may slow v2 adoption and partner timelines.
    b) Keep v1.x front-and-center; accept friction as the price of rapid iteration and ecosystem migration.
        *Implication:* Accelerates v2 maturation via real usage, but risks reputation damage from broken first experiences.
    c) Dual-track: default to v0.25 for new users; offer a clear ‘beta ramp’ checklist for v1.x (known issues + required plugins).
        *Implication:* Balances adoption and reliability, but requires disciplined documentation and release gating.
    d) Other / More discussion needed / None of the above.

**Question 2:** Which developer experience fix has the highest leverage in the next 72 hours: plugin loading stability, environment variable clarity, or version naming/packaging clarity?

  **Context:**
  - `Coders channel: “Plugin loading failures with @elizaos/plugin-openai and @elizaos/plugin-sql… confusion about where .env files should be placed.”`
  - `Dev Discord: “System appears to default to Anthropic even when OpenAI keys are provided” (summary; DeFine/0xbbjoker discussion).`

  **Multiple Choice Answers:**
    a) Prioritize plugin loading stability (openai/sql) and deterministic provider selection.
        *Implication:* Directly reduces breakages and support churn; aligns with execution excellence.
    b) Prioritize environment variable and setup clarity (single canonical .env location + tooling checks).
        *Implication:* Prevents the largest class of self-inflicted failures; fastest documentation-to-impact ratio.
    c) Prioritize version naming/packaging clarity (v0.x vs v1.x, branch guidance, starter vs monorepo).
        *Implication:* Reduces confusion and misinstalls; improves trust even before deeper bugs are fixed.
    d) Other / More discussion needed / None of the above.

**Question 3:** Do we expand provider compatibility (e.g., Google/Gemini) now to meet demand, or defer until core/plugin migration stabilizes?

  **Context:**
  - `Coders channel: “We don't have a way for google/gemini models yet… use plugin-openai/plugin-anthropic/plugin-groq/plugin-venice” (cocaine7499).`

  **Multiple Choice Answers:**
    a) Defer new providers; focus on stability and plugin migration first.
        *Implication:* Optimizes reliability and reduces surface area, but may lose some developers to competing frameworks.
    b) Build Gemini support as a ‘thin adapter’ plugin with strict scope and strong tests.
        *Implication:* Captures demand while limiting complexity, but still competes for engineering attention.
    c) Partner-led integration: accept community PRs for Gemini while core team focuses on v2 hardening.
        *Implication:* Scales via open source, but increases review burden and risk of uneven quality.
    d) Other / More discussion needed / None of the above.

---


### 3. Topic: Reliability Signal: Quality Gates, Testing, and Observability

**Summary of Topic:** Engineering throughput is strong (multiple merged fixes; new CLI test suite; remote attestation fixes; GUI enhancements), but we need to convert this activity into a visible reliability narrative and enforceable release gates to build developer trust.

#### Deliberation Items (Questions):

**Question 1:** Should we define a formal ‘Execution Excellence Gate’ for releases (tests + docs + upgrade path), and make shipping contingent on passing it?

  **Context:**
  - `GitHub: “Introduced a new CLI test suite” (PR #4301).`
  - `Discord: “Breaking changes pushed to documentation requiring fixes” (jin).`

  **Multiple Choice Answers:**
    a) Yes—mandate a release gate: CI green + smoke tests + docs deploy + upgrade notes before tagging.
        *Implication:* Improves trust-through-shipping, but may slow cadence and require stronger release management.
    b) Partial—apply gates only to ‘stable’ channels; allow beta to move fast with looser constraints.
        *Implication:* Maintains velocity while protecting new users, but requires clear channel separation to avoid confusion.
    c) No—opt for continuous deployment; rely on quick rollback and community triage.
        *Implication:* Maximizes iteration speed, but conflicts with the stated priority of reliability over feature quantity.
    d) Other / More discussion needed / None of the above.

**Question 2:** Where do we invest first in observability: LLM instrumentation/tracing, client UX diagnostics, or security/attestation reporting?

  **Context:**
  - `PRs: “LLM instrumentation capabilities” (PR #4304) and “API endpoint for querying trace data” (PR #4308).`
  - `PRs: “Fixed the Remote Attestation Action” (PR #4305).`

  **Multiple Choice Answers:**
    a) Prioritize LLM tracing end-to-end (instrumentation + trace query API) to reduce model/provider ambiguity and failures.
        *Implication:* Shortens debugging loops and improves reliability perception for developers building agents.
    b) Prioritize client UX diagnostics (GUI validation, onboarding, error surfacing) to prevent setup failures.
        *Implication:* Improves first-run success rates, likely the highest driver of developer trust and retention.
    c) Prioritize security and attestation visibility (clear status, failure reasons, audit hooks).
        *Implication:* Strengthens long-term platform credibility, especially for cloud/TEE deployments and cross-chain operations.
    d) Other / More discussion needed / None of the above.

**Question 3:** How do we operationalize community throughput without losing coherence: tighter PR governance or broader merging with fast follow fixes?

  **Context:**
  - `GitHub summary: “11 new pull requests with 7 successfully merged… 12 active contributors.”`
  - `Dev/Discord: multiple user-facing breakages and confusion around versions and plugins.`

  **Multiple Choice Answers:**
    a) Tighten governance: stricter review requirements, smaller PRs, and designated maintainers for high-risk areas (CLI, plugins, docs).
        *Implication:* Reduces regressions and doc breakages, but may discourage contributors if turnaround slows.
    b) Keep high merge velocity but add automated checks (lint/tests/docs build) and rapid patch releases.
        *Implication:* Preserves community energy while reducing risk via automation; requires investment in CI and release tooling.
    c) Split repos/ownership: isolate plugins and docs into governed subprojects with their own release cycles.
        *Implication:* Improves modularity and composability, but introduces coordination overhead and potential fragmentation.
    d) Other / More discussion needed / None of the above.