# ElizaOS Intel — 2026-02-23

## 1) Data Pattern Recognition

### Development velocity & trend
- **Monthly (Feb to date, elizaos/eliza):** 38 PRs opened / 18 merged; 41 new issues; 65 issues closed; **35 active contributors**. Net code churn reported: **+18,576 / -3,807 across 160 files; 140 commits**.
- **Daily signal (2026-02-22):** 3 notable PR threads surfaced in comms:
  - **DB/RLS refactor:** PR **#6521** (standujar) aligning **SQL isolation/RLS with v1 patterns** and removing **~2,600 LOC** of auto-migration logic (1.4.x → 1.6.x).
  - **Docs/safety:** Base Network wallet safety guide (x402 diagnostics).
  - **Dependencies:** npm/yarn group bump across 3 dirs (maintenance hygiene).

**Trend callout:** Engineering effort is concentrated on **v2.0.0 stabilization + hardening (RLS/security) + prompt/bootstrapping efficiency** rather than end-user UI iteration.

### Community engagement patterns
- Engagement spikes around **ecosystem incentives** (token holder upgrades, NFT drops) and **platform readiness questions** (“team still active?”, “which version is stable?”, “how do migrations work?”).
- Cross-channel confusion persists (Discord ↔ X/Twitter ↔ Farcaster). Users are missing context unless they monitor multiple feeds.

### Feature adoption & ecosystem expansion signals
- **Plugin ecosystem remains a growth engine:**
  - New external plugin announced: **@buzzbd/plugin-solcex-bd** (autonomous BD agent for exchange listings) + registry PR **#263**.
  - Continued interest in **EVM/NFT capabilities** tied to ongoing `plugin-evm` work.
- **NFT drop integration as distribution lever:**
  - Milady announced **AGENTS ERC-8004 drop** using **ERC-8041** standard: **2,138 NFTs per chain** (ETH, BSC, Base, Solana), free mint, with “upgraded mints” for **elizaOS holders** and other collections.

### Pain point correlation across channels
A consistent set of frictions repeats across Discord + product feedback:
1. **Upgrade/migration ambiguity** (token benefit eligibility; DB migration paths).
2. **Performance ceilings** (200k token limits when many plugins enabled; bootstrap providers/evaluations implicated).
3. **Cloud UX regressions** (scrolling broken; API explorer “send request” fails with “api key is required”).
4. **Documentation gaps in v2** (recommended branch is v2.0.0, but documentation lags; users struggle with “how-to” and compatibility expectations).

---

## 2) User Experience Intelligence

### Feedback themes (categorized by impact)

**High impact (blocks adoption / causes user loss)**
- **ElizaCloud dashboard UX bugs (reported 2026-02-20):**
  - Broken mousepad scrolling on API explorer and other pages.
  - “Send request” test returning **“api key is required”** even when key appears present.
  - Pricing transparency missing (no per-model breakdown).
- **Versioning & migration clarity:**
  - Users unsure “most stable version”; guidance is “use v2.0.0” but docs are thinner.
  - DB migration path change (removal of 1.4.x → 1.6.x auto-migration) risks **hard failures** for long-tail upgraders unless surfaced explicitly.

**Medium impact (degrades efficiency / trust)**
- **Token holder upgrade confusion:** unresolved question whether benefits apply to **$milady.ai vs elizaOS**, plus “milady.ai token not launched yet” confusion.
- **Spartan vs Milady wallet relationship unclear:** users ask if Spartan routes Milady wallet orders; answer implies shared tech but not direct linkage.

**Low impact (opportunity / community momentum)**
- Builder showcase: DarmaStef demonstrated multiple agents (reservation/travel/db analysis) — evidence of broad applicability and potential for “reference implementations” to accelerate adoption.

### Usage patterns vs intended design
- Power users are enabling “numerous plugins” and hitting **200k token context ceilings**, indicating:
  - The default bootstrap + evaluation stack is **too verbose by default** for large plugin sets.
  - Users treat the system as a **plugin kitchen-sink runtime**, not a curated minimal capability set.

### Implementation opportunities (product + platform)
- **Make migrations explicit and deterministic** (fail fast with actionable instructions).
- **Introduce “capability profiles”** (minimal / standard / max) that bound prompt size and evaluator/provider inclusion.
- **Cloud dashboard should become the trust anchor** for pricing and key management (BYOK clarity, per-model cost, functional API explorer).

### Community sentiment (qualitative)
- Generally positive on “team still active” reassurance and new ecosystem drops, but **trust is fragile** due to:
  - inconsistent comms across platforms,
  - UX bugs in cloud,
  - ambiguity on token/NFT eligibility.

---

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

### Critical-path priorities (next 7–14 days)

1) **Performance: reduce baseline context bloat (High impact / Medium risk)**
- **Problem:** frequent 200k token limit hits with many plugins; bootstrap providers and evaluations are primary contributors.
- **Action:** prioritize a “prompt budget” initiative:
  - default to **ActionFilterService-style filtering** for providers/evaluators (only include what’s relevant to the current step / recent context),
  - add instrumentation to log **token contribution by provider/evaluator** (top-N offenders).
- **Success metric:** p95 prompt tokens reduced by **30–50%** in multi-plugin configurations; fewer “token limit” runtime failures.

2) **DB refactor integration + safe migration gates (High impact / Medium risk)**
- **Dependency:** deconflict/rebase **PR #6521** with Odilitime’s parallel “great db refactor PR”.
- **Action:**
  - implement explicit guardrails: if DB schema indicates **1.4.x**, throw a clear error: “upgrade to 1.6.x first” + link to migration guide.
  - ensure RLS semantics remain consistent (v1 parity is a stated goal).
- **Success metric:** zero “silent corruption” paths; clear, test-covered failure mode for unsupported upgrade jumps.

3) **ElizaCloud dashboard: fix 2 blocking UX bugs (High impact / Low–Medium risk)**
- **Bugs to ship immediately:**
  - API explorer scrolling behavior (trackpad + scrollbar visibility).
  - “Send request” incorrectly requiring API key.
- **Add-on:** clarify “use a different key” behavior (BYOK vs internal key switching).
- **Success metric:** API explorer can successfully execute a request end-to-end for a first-time user in <5 minutes.

### Secondary priorities (2–4 weeks)

4) **Docs & onboarding for v2.0.0 (Medium–High impact / Low risk)**
- Publish a single canonical “v2 getting started” that includes:
  - DB selection (pglite vs Neon) and limitations (no automatic migration between them),
  - recommended “capability profile” setups for common use cases (chat agent, workflow agent, trading agent),
  - NFT/EVM plugin capability status and roadmap notes.

5) **Comms consolidation for token/NFT benefits (Medium impact / Low risk)**
- Ship a short “Eligibility & Terminology” post in Discord pinned message:
  - which asset receives what benefit (elizaOS holders, OG Milady, Remilio),
  - milady.ai token launch status (“not launched”),
  - chain coverage (ETH/BSC/Base/Solana) for the AGENTS drop.

---

## Quantitative Summary Dashboard (today’s snapshot)
- **Engineering throughput (Feb to date):** 38 PRs opened; 18 merged; 35 contributors active.
- **Refactor magnitude (DB/migrations):** ~**2,600 LOC deleted** in migration removal; RLS alignment work active.
- **Ecosystem expansion:** 1 notable new plugin announced (**SolCex BD agent**) + registry PR **#263**.
- **Distribution event:** **AGENTS NFT drop** planned with **2,138 NFTs per chain × 4 chains** (8,552 total across chains, excluding any extra mechanics).

---

## Recommended Resource Allocation
- **Platform/Core (2 engineers):** prompt-budget + bootstrap/evaluator slimming + token attribution tooling.
- **Data/DB (1–2 engineers):** merge path for PR #6521 + migration guardrails + RLS regression tests.
- **Cloud UX (1 engineer + 1 QA half-time):** scrolling + API explorer request fix; add minimal BYOK/pricing clarity.
- **DevRel/Docs (0.5–1 engineer or tech writer):** v2 canonical onboarding + migration FAQ + pinned comms for NFT/token benefits.

---

## Actionable Next Steps (owner-ready)
1. **Assign an owner to ship migration guardrail** (1.4.x → 1.6.x requirement) + doc link; add CI test for expected error message.
2. **Instrument prompt composition** (per provider/evaluator token contribution) and publish a weekly “prompt budget report”.
3. **Hotfix ElizaCloud API explorer** (scroll + API key false-negative) and add a simple integration test that executes a sample request.
4. **Resolve benefits ambiguity publicly**: one pinned message clarifying **elizaOS holder upgrade** vs **milady.ai token** status to prevent repeated confusion.
5. **Fast-track registry PR #263** if it meets security/quality bars, but require a minimal README section: permissions, key handling, and rate-limit expectations.