# ElizaOS Intel — 2026-02-04

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

### Development velocity & delivery signals
- **PRs surfaced for review (Discord): 2**
  - elizaOS/eliza **PR #6457**
  - elizaOS/eliza-cloud-v2 **PR #278**
- **Repo activity telemetry mismatch**
  - GitHub monthly rollup (2026-02-01 → 2026-03-01) reports **0 new PRs** and **7 new issues / 3 closed** in `elizaos/eliza`, while Discord indicates active PR flow.  
  - **Intel implication:** reporting pipeline likely undercounting PRs (e.g., branch/repo mismatch, ingestion lag, or PRs in adjacent repos). This blocks accurate throughput tracking.

### Community engagement patterns (where energy is concentrating)
- High-signal engineering conversations clustered in:
  - **#coders:** plugins, OpenClaw integration, skill security
  - **#core-devs:** branch guidance (odi-dev), tooling compatibility, PR review workflow (“prr”)
  - **#discussion:** migration support and frustration
  - **#partners:** product/marketing insight (privacy UX friction)
- Engagement trend: **support load + risk conversations rising** (migration losses; malicious skills), alongside **ecosystem-building** (plugins, DIaaS, CICADA-71).

### Feature adoption & ecosystem pull
- **Plugins are the primary extensibility path** (DIaaS API consumption explicitly routed to “build a plugin”).
- **OpenClaw → Eliza phased rollout** is understood by builders, but introduces a short-term expectation gap: “everyone gets Eliza first; custom agents later.”
- CICADA-71: ElizaOS assigned **Shard 66**; indicates external interest in benchmarking/competition frameworks.

### Pain point correlation across channels (cross-cutting issues)
1. **Trust & Safety for skills/plugins** (malicious skills on clawhub) ↔ **Skill invocation reliability** (skills not triggering)  
   - Reliability and security both push toward more deterministic execution, explicit tool selection, and sandboxing.
2. **Migration incidents** ↔ **Communication gaps**  
   - Financial loss reports amplify reputational risk; lack of “one canonical migration playbook” increases support churn.
3. **Developer experience fragmentation** ↔ **Branch divergence**  
   - Recommendation to use **odi-dev over main** suggests main is not the practical “source of truth,” increasing confusion and inconsistent builds.

---

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

### Feedback themes (categorized by impact)

**High impact (user trust / money / account access)**
- **Token migration failures + reported losses (>$4k case)**  
  - Users being redirected to support channels indicates triage exists, but not resolution transparency.
- **ElizaCloud account duplication / “agent disappeared”** (email aliasing: `@proton.me` vs `@protonmail.com`)  
  - This is a severe UX trust break: perceived data loss.

**High impact (core product functioning)**
- **Skill invocation reliability:** reported **56% of eval cases where skills never triggered** even with docs available.  
  - A workaround exists: a forced 3-step “YES/NO → call Skill() → then proceed” hook pattern.

**Medium impact (growth / adoption friction)**
- **Billing/payment gating:** API key creation failing without credit card even for free credits; x402 disabled on free tier.  
  - Blocks testing, bot iteration, and “try-before-buy,” which directly harms activation.

**Medium impact (creator workflows / retention)**
- **Image generation consistency:** inability to keep character identity across iterations; forces prompt retries or external tool use.  
  - Impacts storytelling/branding segments; lowers “flow” inside ElizaCloud.

**Medium impact (developer tooling accessibility)**
- Codex app **Apple Silicon only**; desire for browser-based tooling (Cursor in browser) suggests demand for cross-platform parity.

### Usage patterns vs intended design (what users are actually doing)
- Users are building *real integrations* (trading signal DIaaS) and expect a **standard plugin contract** rather than bespoke guidance.
- Users expect “agents that relentlessly try to do stuff” (autonomy default) and minimal setup; current friction points (billing gates, tool incompatibility, unreliable skill triggers) push the opposite behavior (manual prompting, workaround hooks).

### Community sentiment (qualitative)
- **Negative spike risk:** migration loss narratives (money + difficulty) are emotionally sticky and likely to spread beyond Discord.
- **Positive builder sentiment:** plugin examples (plugin-cskills) + hands-on help (0xbbjoker) increase confidence among developers.
- **Pragmatic concern:** security discussions are mature, but absence of visible enforcement (sandboxing/signing) may reduce marketplace trust.

---

## 3) Strategic Prioritization (Impact × Risk, Dependencies, Resourcing)

### Priority stack (next 1–2 weeks)

#### P0 — Stop trust erosion (money, safety, account integrity)
1) **Migration incident response program (product + comms + support + engineering)**
   - Deliverables:
     - Public, canonical **migration status page** + “known issues” list (bridge detection, max amount errors, wallet zero cases).
     - A **single intake form** that generates a trackable ticket ID users can reference in Discord (reduces repeated posts).
     - Post-deadline policy clarity: remediation windows, edge-case handling, and proof requirements.
   - KPI targets:
     - Reduce new migration complaint posts by **>50% week-over-week**
     - Median time-to-first-human-response **<4 hours**

2) **Skill/plugin supply-chain security baseline (clawhub)**
   - Adopt a layered approach already suggested in community discussion:
     - **Static scanner skills** (lint + dependency checks + secrets detection)
     - **Packaging rewrite/adaptation phase** (normalize for Eliza runtime)
     - **LLM-based review** as assistive triage (not sole gate)
     - Add **sandboxing** for execution (mandatory for untrusted/community skills)
   - Critical path dependencies:
     - Define a **skill manifest** schema (permissions, network/file access, model/tool usage)
     - Choose sandbox tech (container/wasm/VM) and performance budget
   - KPI targets:
     - 100% of published skills have manifest + scan report
     - Sandbox coverage for “untrusted” skills at **100%**

3) **Account identity unification (email aliasing)**
   - Fix strategy:
     - Canonicalize email identities or implement **account linking** for equivalent addresses (esp. Proton variants).
     - Add “recover my agent” flow in UI using wallet/session proofs.
   - KPI targets:
     - Duplicate-account incidents: **near-zero**
     - Self-serve recovery success rate: **>80%**

#### P1 — Make agents reliably act (core UX reliability)
4) **Skill invocation determinism**
   - Product decision needed: accept “weird but works” forced activation, or implement a cleaner planner.
   - Recommended implementation path:
     - Add an **internal planning step** that scores skills and *must* emit tool calls when score exceeds threshold.
     - Standardize **skill descriptions + examples** (not optional) to improve tool selection.
     - Instrument: log “available skills vs called skills” per session.
   - KPI targets:
     - Skill non-invocation rate from **56% → <15%** on the same eval suite within 2 iterations.

#### P2 — Remove adoption friction (activation + retention)
5) **Billing & API key creation without credit card (free tier)**
   - Make “API keys for testing” available with:
     - Rate limits + spend caps + abuse detection
     - Optional x402 top-ups even on free tier (if strategically aligned)
   - KPI targets:
     - Free→Activated developer conversion up (define baseline), API key creation failure rate **<2%**

6) **Image consistency roadmap (LoRA / identity lock)**
   - Near-term: ship as an **agent app** or integration (as suggested by community) to avoid blocking core roadmap.
   - Longer-term: first-class “character identity” primitive (seed/embedding/LoRA management).
   - KPI targets:
     - Task success rate for “edit image but keep character” improves (define internal benchmark)

---

## Resource Allocation Recommendation (pragmatic, risk-weighted)

- **40%**: Migration remediation + comms (short-term reputational protection; support load reduction)
- **30%**: Skill security + sandboxing baseline (ecosystem trust; prevents catastrophic incidents)
- **20%**: Skill invocation reliability + instrumentation (directly improves perceived intelligence)
- **10%**: Billing friction + identity/image workflow quality-of-life (activation/retention)

---

## Immediate Actionable Next Steps (72 hours)

1) **Stand up a unified incident board** (Migration + Account Access) with public-facing status updates and internal owners.
2) **Publish “Skill Safety v0” spec**: manifest, scanning requirements, and what gets sandboxed by default.
3) **Decide mainline branch policy**: if `odi-dev` is the recommended path, either fast-forward main or clearly label main as “stable/lagging” and document contributor flow.
4) **Add telemetry hooks**:
   - Skill available vs invoked
   - Billing/API key funnel drop-off
   - Duplicate-account detection triggers (same user signals, wallet/session correlations)
5) **Close the PR review loop**: ensure PR #6457 and PR #278 have explicit review owners + SLA (e.g., first review within 48h).