# ElizaOS Intel — 2026-02-24

## 1) Data Pattern Recognition (velocity, engagement, adoption, pain-point correlation)

### Development velocity & trend signals (GitHub, rolling month snapshot)
- **PRs:** 38 opened / **18 merged** (≈**47% merge rate**)
- **Issues:** **41 opened**, **65 closed** (net negative backlog trend; good triage throughput)
- **Contributors:** **35 active**
- **Code churn:** **+18,576 / -3,807** across **160 files**, **140 commits**
- Macro-pattern: strong throughput and ecosystem expansion, but **large, still-open v2/“next” mega-PRs** indicate review/merge bandwidth and release-cohesion risk.

### Community engagement patterns (Discord, last 72h)
- Engagement is being pulled into two high-intensity areas:
  1) **Org/revenue pivot** discussion (core-devs) → high strategic attention, many unanswered operational questions.
  2) **Token migration confusion + scam anxiety** (discussion) → repeated, emotionally charged user posts; creates reputational drag and support load.
- Builder engagement is present but diffuse: multiple “available for work” posts suggest **supply of contributors** but unclear intake mechanism.

### Feature/implementation adoption signals
- **plugin-bootstrap** is becoming the de facto “default capabilities” pack (image generation action referenced as the recommended route vs. older plugin-image-generation).
- Performance pain points correlate with “baseline capabilities”:
  - Token/context bloat reported from **bootstrap providers + evaluations**, plus **recent messages/reflections** over-collecting context.

### Pain point correlation across channels
- **Cost/efficiency**: token-limit reports (200k context) + duplicated LLM work themes (seen in GitHub issues like URL double-processing; consistent with “prompt bloat” complaints).
- **Trust/safety**: migration confusion + scam warnings recur; users conflate similarly named assets/projects and distrust any workflow involving wallet addresses.

---

## 2) User Experience Intelligence (impact, themes, sentiment, opportunities)

### Feedback themes by impact

**P0 — Trust & Safety / User retention**
- Users missing migration deadlines and fearing scams are **exiting positions** or disengaging.
- Current guidance is mostly peer-to-peer (“don’t click DM links”), which is necessary but insufficient.
- Impact: reputational risk + reduces funnel into revenue products (Eliza Cloud/Milady/Eliza App).

**P0 — Cost & Reliability**
- Token/context overflow (“200k limits”) is an acute reliability/cost issue.
- Root cause (per core-devs): not actions alone; **recentMessages/reflections** are capturing excessive data.
- Impact: higher inference costs, slower responses, unpredictable agent behavior; directly harms revenue products that rely on consistent margins.

**P1 — Developer Experience (DX) clarity**
- Confusion about:
  - Which image generation plugin to use (resolved ad hoc: **use plugin-bootstrap**).
  - Migration paths and version priority (**v2.0.0 importance questioned** after revenue pivot message).
  - Backend ownership/boundaries (“are you and Shadow taking over cloud?” unanswered).
- Impact: slows contributions and increases support overhead.

### Usage patterns vs intended design (observed)
- Users treat Discord as a **primary support desk for financial/token issues**; this crowds out builder help and amplifies scam surface area.
- Builders appear ready to contribute, but intake lacks structure (no clear “pick up this ticket/project” workflow surfaced in chat).

### Implementation opportunities (high leverage)
- “Context budget” system: enforce **hard caps + summarization** on recentMessages/reflections, and expose per-provider token cost metrics (tie to existing “cost evaluator” direction in repo history).
- Standardize “recommended plugin set” docs: make plugin-bootstrap the canonical baseline, explicitly deprecate older equivalents.

---

## 3) Strategic Prioritization (impact vs risk, dependencies, resource allocation)

### Current strategic reality (from core-devs)
- Org has pivoted to **immediate revenue**, small fixed-budget teams, fast validation/kill decisions.
- Revenue-track initiatives named:
  - **Milady** (FOSS funnel → Eliza Cloud revenue)
  - **Eliza App onboarding + billing** (start charging)
  - **Babylon** rollout (1% → 100% users) + trading platform
  - **Hyperscape Agent Arena duel betting** (2% + 1% on winnings) launching next week
  - **Jeju** network (later)

### Critical path dependencies (what must be true to ship revenue)
1) **Backend readiness** (Shadow collaboration; workflow vs full sandbox modes)
   - Dependency for: Milady hosted, Eliza App, Babylon/Hyperscape integration.
2) **Cost control + context reliability**
   - Dependency for: viable unit economics in trading/betting flows and cloud-hosted agents.
3) **Trust/safety comms + migration clarity**
   - Dependency for: community confidence; reduces churn and scam incidents that poison acquisition.

### Prioritized recommendations (next 7–14 days)

**Priority A (P0): Ship revenue without margin leakage**
- **Implement “Context Budget Guardrails”**:
  - Cap recentMessages/reflections payload size; add summarization when exceeding thresholds.
  - Add per-provider/context section token attribution in logs by default (so teams can see what’s expensive).
  - Success metric: reduce “context overflow / 200k limit” incidents; measurable drop in prompt tokens per turn.

**Priority A (P0): Migration/scam containment to protect funnel**
- Publish a single pinned, immutable “**Migration & Safety**” page and Discord pinned post:
  - Canonical links, dates, snapshot info, what support will *never* ask for, and how tickets are opened.
  - Add an auto-mod response for keywords (“migration”, “ticket”, “deadline”, “wallet address”).
  - Success metric: fewer repeated questions; lower moderator time; fewer users publicly “rage quitting.”

**Priority B (P1): Reduce DX ambiguity to accelerate shipping**
- Declare “**plugin-bootstrap is canonical**” (and list what it replaces, including image generation).
- Clarify v2 track in one sentence: whether v2.0.0 is still the framework future vs. revenue apps shipping on a fork/branch.
  - Success metric: fewer Discord Qs about “which version/plugin”; higher PR conversion from community.

**Priority C (P1/P2): Framework-level optimization only if it unblocks revenue**
- “Metatool pattern for providers” is promising, but only do it now if it materially reduces costs for Milady/Eliza App production workloads.
  - If recentMessages/reflections are the primary culprit, fix those first; avoid a broad abstraction refactor that delays launches.

### Resource allocation suggestion (venture-team aligned)
- **Team 1 (Revenue Launch SWAT):** Milady hosted + Eliza App onboarding/billing + Babylon/Hyperscape integration readiness.
- **Team 2 (Cost/Perf Guardrails):** context budget + token attribution + regression tests for context growth.
- **Team 3 (Trust & Comms):** migration clarity page, Discord automation, and a lightweight support intake flow.

---

## Key Risks to Track (with triggers)
- **Release cohesion risk:** large open v2/next PRs continue to expand → trigger: review queue > 7 days, merge conflicts rising.
- **Unit economics risk:** token bloat persists into production → trigger: prompt tokens per request trending up week-over-week.
- **Reputational risk:** migration/scam narratives dominate public channels → trigger: repeated daily posts about scams/missed deadlines without authoritative link response.

---

## Actionable Next Steps (measurable)
1) **Within 48h:** ship pinned “Migration & Safety” canonical guidance + auto-mod keyword responses.
2) **Within 7d:** land context caps/summarization for recentMessages/reflections + token attribution logs.
3) **Within 7d:** publish “Recommended Baseline Plugins” doc (plugin-bootstrap first) and deprecation guidance for older packages.
4) **Before next week’s launches:** add a “cost per interaction” dashboard/log line for revenue apps (Babylon/Hyperscape/Eliza App) to prevent silent margin erosion.