# ElizaOS Intel — 2026-05-03

## 1) Data Pattern Recognition (Dev + Community)

### Development velocity & trend
- **Repo activity (rolling month window 2026-05-01 → 2026-06-01, elizaos/eliza):**
  - **15 new PRs**, **22 merged PRs**
  - **9 new issues**, **4 closed issues**
  - **7 active contributors**
  - Code churn (month-to-date): **+1,295 / -363 across 110 files**, **257 commits** (high churn; likely multiple large refactors + dependency work)
- **Stabilization theme is dominant** over net-new product features:
  - **ESM alignment/build unblocks** completed across **plugin-ollama, plugin-openai, plugin-openrouter, plugin-pdf** (removal of incompatible CJS bundles).
  - **Headless Linux runtime stability** improved (keychain/D-Bus segfault bypass).
  - **Windows Server 2025 CI stability** improved (Inno Setup exit code handling).
  - **Dependency modernization** continuing (Node **v24**, viem, tsdown).

### Cross-repo/architecture signals
- The platform is converging on a **“runtime OS” posture** (v3 described as full application runtime; multi-platform, multi-social, workflow + monetization), while current execution focus is **infra hardening** to support that posture.
- **Large consolidation risk** emerging:
  - PR **#7235** (“add cloud and plugins, remove rust and python”) is extremely large (**~1.35M additions / 249k deletions**) → likely to increase merge conflicts, review time, and regression surface area.

### Community engagement patterns
- Discord (May 2): **low technical interaction density**; mostly greetings.
- High-signal community items:
  - A community-built **spot trading agent** announced (SOL, SUI + 5 tokens; **1–2 signals/week** planned).
  - Emergence of an **“eliza army steering”** group invitation → indicates community trying to self-organize to maintain momentum.

**Actionable observation:** Engineering output is strong but skewed toward platform hardening; community discussion is not reflecting that progress yet (low “feedback loop bandwidth”), which can reduce perceived momentum unless paired with demos, release notes, and onboarding improvements.

---

## 2) User Experience Intelligence (Pain Points, Sentiment, Adoption)

### Feedback/themes by impact

#### P0/P1: Messaging connector reliability (Telegram)
Evidence indicates multiple compounding Telegram failures:
- **Token passing failures** (#7240)
- **Bun runtime error on `bot.launch()`** (#7241)
- **Dual-polling race condition causing silent message loss** (#7245)  
  - Two Telegraf pollers consume the same bot token (plugin + wrapper). Because Telegram long-poll delivers updates to only one consumer, **~50% message drop** is plausible and hard to diagnose from user perspective.

**UX impact:** “Bot ignores me sometimes” → catastrophic trust loss. Silent failure mode is worse than hard failure.

#### P1: Auth/config schema drift + fragmentation
- **auth.json schema expectations outdated** → `hasCodexCliSubscriptionAuth` failures (#7238, #7243)
- **MiladyClient prototype fragmentation** (#7233, #7244)
- **Discord env var discrepancy** (`voice.ts` vs `messages.ts` handling; issue #49) + WIP standardization of **DISCORD_AUTO_REPLY** env var (#50)

**UX impact:** Onboarding + configuration reliability degradation (users face “it should work” flows that fail based on subtle schema/env differences).

#### P2 (emerging, long-horizon): Long-lived agent “memory rot”
- Reported failure mode: retrieval-only memory systems degrade after ~**3 months** due to stale facts persisting.
- Proposed mitigation: reconciliation pass with **freshness gates**, periodic diffs, and re-embedding under current ontology; reportedly effective in production.

**UX impact:** Long-lived agents become inconsistent/non-credible over time; costs accrue silently until contradictions surface.

### Usage patterns vs intended design
- Intended: plugin-first architecture (single source of truth per connector).
- Observed: wrappers/workarounds (Telegram) create **duplicate ownership** of the same external integration → violates intended “one connector owns polling + lifecycle” model.

### Community sentiment
- Sentiment: cautiously supportive (partners channel reaffirmations), but conversation volume is light.
- Optimism spikes around practical demos (robot integration) and trading-agent potential.

**Implementation opportunities**
- Add **connector lifecycle invariants** (e.g., “single poller per token” guardrails) and **self-diagnostics** surfaced in UI/logs.
- Convert known failure modes into **setup-time checks** (schema version checks; env var validation; connector conflict detection).

---

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

### Priority A — Fix Telegram end-to-end reliability (highest user impact, moderate technical risk)
**Goal:** “Send 10 messages → receive 10 replies” deterministically.

**Recommended plan (sequenced):**
1. **Enforce single owner for Telegram polling**
   - Make plugin and wrapper **mutually exclusive** (config-time assertion).
   - If wrapper remains temporarily, auto-disable plugin polling (or vice versa).
2. **Resolve Bun `launch()` issue at source**
   - Prefer upstream plugin fix so consumers don’t invent wrappers.
3. **Add a connector integration test**
   - Simulate updates and assert exactly-once processing; add a regression test for dual-poller conditions.
4. **Improve observability**
   - Emit explicit warning when two Telegram consumers start with same token.
   - Surface connector health in runtime UI (“Connected, polling, last update timestamp”).

**Resourcing:** assign **1–2 engineers for 2–4 days** to reach a stable minimal fix (single poller + guardrails), then follow-on for Bun launch.

### Priority B — Unify auth/config schemas + env var standards (high impact, low/moderate risk)
**Problems:** auth.json drift, prototype fragmentation, inconsistent env handling.

**Actions:**
- Define and version **auth.json schema**; add migration + validation with actionable errors.
- Resolve **MiladyClient prototype fragmentation** by consolidating client creation patterns and ensuring consistent interfaces across apps/wrappers.
- Decide and document a single standard for **Discord env vars** (voice/messages parity) and implement consistently.

**Dependency:** reduces churn and improves reliability for self-hosting + multi-platform builds.

### Priority C — Manage “large refactor” risk (PR #7235) (medium impact, high risk if mishandled)
**Risk:** a massive consolidation PR can stall velocity or introduce regressions.

**Actions:**
- If not already, **split #7235** into smaller PRs by subsystem (cloud import, plugin restructuring, removals).
- Require a **release-candidate checklist**: build matrix + smoke tests (Linux headless, Windows build, packaged apps, connector sanity).

### Priority D — Product credibility for long-lived agents (memory rot mitigation) (strategic differentiator, moderate risk)
**Actions:**
- Turn the reconciliation approach into an **official “Memory Freshness” module** or recommended architecture pattern.
- Define metrics: contradiction rate, stale-claim incidence, freshness gate hit rate.
- Publish the requested **field report** as a canonical doc; this can become a differentiating technical narrative.

---

## Quantitative Watchlist (Next 7 Days)
- **Telegram:** reduce open high-severity Telegram issues (#7240/#7241/#7245) from **3 → 0–1**, and add at least **1 regression test**.
- **Config/Auth:** close at least **2** of (#7233/#7234/#7238/#7243/#7244/#49) with schema/env standard decisions documented.
- **Community feedback loop:** target **1 demo post + 1 changelog-style summary** translating infra wins (ESM build unblocks, headless stability, self-hosted auth) into user-perceivable improvements.

---

## Immediate Recommendations (Do Now)
1. **Ship a hotfix** preventing Telegram dual polling (fail fast with explicit error if two pollers start).
2. **Create a “Connector Ownership” guideline** (1-page doc) and enforce with runtime checks.
3. **Add schema validation + migration** for auth.json (block confusing runtime errors).
4. **Operationalize memory-rot mitigation**: schedule a short technical write-up + add backlog item for “freshness gates” as a supported pattern.