# ElizaOS Intel — 2026-02-22

## 1) Data Pattern Recognition (Velocity, Engagement, Adoption, Pain-Point Correlation)

### Development velocity (GitHub, month-to-date window: 2026-02-01 → 2026-03-01)
- PRs: **35 opened / 18 merged** (merge rate **51%**)
- Issues: **41 opened / 65 closed** (net burn-down **-24**)
- Contributors: **34 active**
- Code churn: **+18,576 / -3,807 across 160 files**, **136 commits**
- Notable trend: multiple **very large, long-lived PRs** remain open (e.g., v2 branch + multi-language runtime work). This is a **throughput risk**: review bandwidth and integration complexity can bottleneck “time-to-stable.”

**Inference:** Core engineering throughput is strong (issues burn-down, contributor count), but stability perception is being harmed by (a) a recommended branch (v2.0.0) that is under-documented and (b) user-facing cloud/dashboard regressions.

### Community engagement patterns (Discord, last 3 days of available data)
- Engagement is **high on positioning/token migration clarification**, **medium on technical onboarding**, and **low on deep coding discussion in public channels** (explicitly attributed to a separate dev Discord).
- Repeated questions cluster into:
  1) “**Which version should I use**?” (v2.0.0 recommended, docs lag)
  2) “**How do DB options work**?” (pglite vs Neon, no migration)
  3) “**How do I use ElizaCloud features**?” (API explorer broken, key handling unclear)
  4) “**Token migration / contract confusion**” (ai16z vs elizaOS, missed deadlines, mintability)

**Inference:** Public Discord is acting as a **support + narrative** channel more than a build channel; support load is elevated by missing docs and unclear product surfaces.

### Feature adoption / demand signals
- **Babylon waitlist** opened to **top 5,000** users → clear demand and an imminent onboarding wave.
- Plugin ecosystem expansion reported:
  - New plugin proposals: **@elizaos/plugin-xproof**, **micronoise-eliza-plugin** (x402 swaps)
  - Continued interest: **MoltBridge** “trust & discovery layer” (now live)

**Inference:** Adoption is shifting from “framework interest” to “ecosystem + distribution,” but onboarding friction (docs + cloud UX) is the limiting factor.

### Pain point correlation across channels (high confidence)
| Pain Point | Evidence | Likely Root Cause | Impact |
|---|---|---|---|
| v2.0.0 is “recommended but under-documented” | Discord guidance + doc requests | Fast-moving architecture; docs not keeping pace | Builder drop-off, fragmented community support |
| Cloud dashboard usability + API explorer failures | Scrolling bugs; “API key required” despite key present | Frontend event handling + auth state mismatch | Blocks trial/activation; increases support burden |
| Confusion about tokens/migration | ai16z vs elizaOS; missed migration; mintability | Messaging fragmentation + insufficient canonical FAQ | Trust/reputation risk; partner sentiment volatility |
| Database choice confusion (pglite vs Neon) | Asked explicitly; no auto-migration | Missing migration tooling + unclear “intended path” | Production fragility; data-loss fear |

---

## 2) User Experience Intelligence (Themes, Impact, Usage vs Intended, Opportunities, Sentiment)

### Feedback categorization by theme & impact

**A. Activation blockers (High impact, immediate)**
- ElizaCloud dashboard:
  - Broken mousepad scrolling on API explorer; hard-to-see scrollbar
  - “Send request” test fails with **“api key is required”** while key appears present
  - Unclear “use a different key” semantics (BYOK question)
  - Pricing transparency request: per-model breakdown

**Why it matters:** These are first-session failures. They convert curiosity into churn and amplify негатив sentiment after prior “delivery timeline” concerns.

**B. Onboarding & build-path ambiguity (High impact, near-term)**
- v2.0.0 recommended, but documentation lags.
- Separate dev Discord reduces visibility of “how to build,” increasing repeated Q&A loops in public channels.

**C. Reliability / correctness issues (Medium impact, needs triage)**
- “openclaw agent started responding in Korean” (unexpected locale behavior)
- URL duplication bug (GitHub issue #6486): URL processed as text + attachment → **double LLM calls** and duplicated output (cost + UX)

**D. Ecosystem clarity (Medium impact, strategic trust)**
- Token migration confusion (ai16z deprecated; elizaOS multi-chain liquidity)
- Outstanding questions: missed migration path; mintability explanation; chain validity (Milady on BNB vs Solana)

### Usage patterns vs intended design (observed mismatch)
- Users treat Discord as a **primary source of investment thesis and canonical truth** → indicates missing or hard-to-find “single source of truth” docs/FAQ.
- Builders want to mix **local (pglite) + hosted (Neon)** and expect **automatic migration**; current architecture requires explicit choice and manual data movement.

### Implementation opportunities (highest leverage)
1) **“Golden path” builder onboarding for v2**  
   A minimal, opinionated quickstart (one DB, one deployment target, one plugin set) will reduce support load more than broad documentation.

2) **ElizaCloud trial success checklist**  
   Instrument and enforce a “first successful API call” funnel: scrolling usable, key recognized, pricing visible, BYOK explicitly labeled.

3) **Canonical clarity pack (token + product + comms)**  
   A pinned FAQ + one permalink that answers: token contracts, migration status, mintability, chain support, where updates are posted.

### Community sentiment (directional)
- Sentiment is **bifurcated**:
  - Positive on mission/positioning when clarified by engineering leadership
  - Negative/fragile around delivery confidence (cloud UX bugs, comms fragmentation, partner comms gaps, token confusion)

---

## 3) Strategic Prioritization (Impact vs Risk, Dependencies, Resource Allocation)

### Priority matrix (next 7–14 days)

**P0 — Unblock activation & reduce trust damage**
1) **Fix ElizaCloud “Send request” / API key state bug**
   - Impact: prevents product validation; likely highest churn driver.
   - Risk: medium (auth/session state + frontend/back coordination).
   - Dependency: clarify whether “use a different key” = BYOK; align backend validation with UI state.

2) **Fix critical dashboard scrolling regressions (API explorer + other pages)**
   - Impact: immediate usability; reduces “product feels broken” perception.
   - Risk: low–medium (frontend event/overflow handling).

3) **Ship a canonical “Token + Migration + Contract” FAQ**
   - Impact: reduces repeated confusion and reputational bleed.
   - Risk: low (content), but requires alignment with legal/ops on mintability language.

**P1 — Reduce builder friction (compounds adoption)**
4) **v2.0.0 documentation sprint (minimum viable set)**
   - Must include: recommended branch rationale, project structure, plugin-sql DB selection, deployment examples, troubleshooting.
   - Target outcome metric: reduce repeated “which version / how DB works” questions by **50%**.

5) **DB migration stance**
   - Either (a) provide a simple migration utility pglite → Postgres or (b) explicitly document “no migration; choose early” with best practices.
   - Without this, teams will build on pglite then stall at productionization.

**P2 — Ecosystem expansion with guardrails**
6) **Plugin intake operationalization**
   - With new proposals coming in, enforce lightweight standards: security notes, version compatibility (v2), minimal docs, example config.
   - Otherwise plugin growth increases support and breakage.

7) **Investigate “Korean responses” anomaly**
   - Triage checklist: locale env vars, model routing, prompt injection, character file language, metadata parsing.
   - Tag as “correctness + safety adjacent” (unexpected language can be exploited as obfuscation).

### Resource allocation recommendation (practical)
- **1 FE engineer (1–2 days):** scrolling + API explorer usability fixes, plus automated UI regression checks for scroll containers.
- **1 full-stack engineer (2–4 days):** API key validation + “send request” pipeline; add telemetry for key-present vs key-accepted mismatch.
- **1 DX/Docs owner (2–3 days):** v2.0.0 “golden path” quickstart + DB selection guide + troubleshooting.
- **1 community/ops (0.5–1 day):** token/migration FAQ + pinned links + “where updates happen” consolidation; partner comms cadence.

### Critical path dependencies to call out
- **Babylon onboarding scale (top 5,000)** depends on: ElizaCloud usability + clear documentation. Otherwise support load spikes and sentiment deteriorates.
- **v2.0.0 adoption** depends on: docs + a stable reference implementation (“known good” template + recommended DB).
- **Trust/discovery layers (MoltBridge, xproof, etc.)** depend on: plugin governance (security, compatibility) or they become reputational liabilities.

---

## Actionable “Next Deliverables” (by 2026-03-01)
1) ElizaCloud: “Send request” works end-to-end; BYOK explicitly labeled; per-model pricing displayed.
2) ElizaCloud: scrolling fixed on API explorer + at least one other affected page; add a quick UI regression test for scroll.
3) Docs: v2.0.0 Quickstart (30 minutes to first agent) + DB decision tree + “no auto-migration” warning and workaround guidance.
4) Comms: pinned canonical FAQ covering ai16z deprecation, elizaOS contracts, migration status/options, mintability explanation, and update channels (Twitter vs Farcaster).
5) Triage: openclaw Korean-response incident categorized, reproduced or closed with root cause notes; URL double-processing bug (#6486) prioritized due to direct cost amplification.