# ElizaOS Intel — 2026-03-13

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

### Development velocity & trend
- **Major releases / milestones (last 72h):**
  - **Eliza 2.0.0 alpha published** (2026-03-11) → indicates active core framework shipping.
  - **Runtime refactor RFC posted** with **Sunday feedback deadline** (2026-03-12) → imminent architecture work.
  - **Cloud repo brought into pipeline tracking** (2026-03-12) → cloud moving from private → public operations.
- **Architecture hotspot intensity:**
  - `AgentRuntime` called out as **~6,273 lines (“god object”)** → refactor is not optional long-term; it’s now a delivery risk.
- **Repo/tooling throughput signals:**
  - Branch analysis tool PR demonstrated (`elizaOS/prr` PR #5) (2026-03-11).
  - Docs PR queued: **elizaos.github.io PR #243** (cloud content).

**Trend call:** Shipping is happening, but the **critical path is shifting from “new features” to “runtime correctness + init determinism + cloud readiness”** to support Milady and external integrations.

### Feature adoption & ecosystem usage (observable metrics)
- **Babylon launch:** reached **50,000 users** and expanding (2026-03-11).
- **Agent registry (aiprox.dev):** **14 live agents**; achieved “**unprompted external agent self-registration**” event (strong organic discoverability signal).
- **Token migration:** window closed **Feb 4, 2026** after 3 months; continued inbound support requests indicate lingering user base needing comms + tooling.

### Community engagement patterns & sentiment
- **High-volume themes across channels:**
  1) **Token utility / price / selling pressure** → recurring anxiety, requires structured comms.
  2) **Security incidents (phishing/scams)** → repeated attempts (wallet-linking scam on 3/11; seed-phrase support-bot scam on 3/12).
  3) **Roadmap clarity & deadlines** → pressure increases when timelines are vague; Milady “~2 weeks” becomes a focal point.
- **Contributor pipeline:**
  - New engineer intro (genife) with relevant skillset (RAG, orchestration, multi-agent) → opportunity to convert interest into scoped issues.

---

## 2) User Experience Intelligence (Feedback, Pain Points, Implementation Opportunities)

### Feedback categorized by impact/theme

**A) High impact (blocks adoption / causes failures)**
- **Plugin initialization race condition**
  - Root: `plugin-sql` registers DB adapter as **side-effect in `init()`**, while plugins init in parallel.
  - Symptom: `plugin-personality` may run before adapter exists.
  - Current mitigation: Milady defensively **pre-registers plugin-sql** before `initialize()`.
  - User impact: intermittent startup failures, non-determinism, hard-to-debug production incidents.

**B) High impact (trust & safety)**
- **Scam/phishing repetition**
  - Incidents: fake “Discord wallet linking” + fake “support ticket bot” sending users to seed-phrase site.
  - User impact: potential asset loss; reputational damage; support load spikes.

**C) Medium impact (conversion & retention)**
- **Token model confusion**
  - Repeated questions about:
    - “No token use case?”
    - “Which token benefits—MILADY or elizaOS?”
    - “Are team members selling?”
  - Current answer: value accrual via **cloud profits → elizaOS buybacks**; **no direct MILADY token utility**; team holds **10% vested**, minimal selling reported.

### Usage patterns vs intended design (where reality diverges)
- Intended: plugins initialize cleanly as composable units.
- Actual: plugins behave like **implicit infrastructure providers** (DB adapter registration), creating hidden dependencies and ordering assumptions.

### Implementation opportunities (UX + DX)
- **Deterministic runtime composition**
  - Move from side-effects to explicit dependency injection (DB adapter required in constructor).
  - Introduce “capability readiness” gates (e.g., storage ready before personality/evaluators start).
- **Security UX**
  - “Official support flow” pinned + bot-verification guidance + in-app warnings during migrations/token tasks.
- **Comms UX**
  - Convert ad-hoc Discord answers into a **canonical “Token + Cloud Value Accrual” explainer** and a **Milady launch checklist/status page**.

---

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

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

| Initiative | User Impact | Tech Risk | Why now | Key dependency |
|---|---:|---:|---|
| **Fix plugin init race (plugin-sql / adapter injection)** | Very High | Medium-High | Blocks reliable Milady + cloud runtime | Runtime refactor decisions |
| **Runtime refactor (split setup logic, reduce god-object)** | High | High | Architectural debt is now causing production behavior | Clear RFC + staged rollout |
| **Milady app launch (~2 weeks target)** | Very High | Medium | External milestone; sets perception of shipping | Stable runtime + cloud infra |
| **Cloud infra + buyback accounting pipeline** | High | Medium | Token narrative depends on credible execution | Ops instrumentation, finance process |
| **Security hardening + anti-phishing protocol** | Very High | Low-Med | Repeated scams; high reputational risk | Moderator + bot tooling |
| **Docs: merge PR #243 + cloud public docs** | Medium | Low | Reduces confusion; supports adoption | Review bandwidth |

### Critical path dependencies (explicit)
1) **Milady launch reliability** depends on:
   - Deterministic runtime init
   - Storage adapter availability guarantees
   - Cloud service readiness (embeddings endpoint concept is adjacent)
2) **Token narrative credibility** depends on:
   - Shipping cloud product
   - Transparent buyback mechanism/process (even if numbers aren’t disclosed, the process must be)

---

## Quantitative Summary (What changed / what we can count)
- **Babylon users:** 50,000 (initial cohort shipped; now expanding).
- **Agent registry:** 14 live agents; multi-rail payments (Lightning/Solana/x402); auto-approver scoring 1–10.
- **Runtime complexity:** AgentRuntime ~6,273 LOC.
- **Security incidents:** 2 distinct scam patterns reported across 2 days (wallet-linking + seed-phrase “support bot”).
- **Milady timeline:** ~2 weeks from 2026-03-12 (now ~13 days).
- **Token migration:** closed Feb 4, 2026; ongoing requests persist (support tail).

---

## Actionable Recommendations (Owner-ready)

### A) Engineering (highest leverage)
1) **Implement explicit storage dependency injection (stop side-effects)**
   - Deliverable: `AgentRuntime` (or runtime builder) requires `DatabaseAdapter`/storage provider in constructor (or pre-init phase).
   - Add: runtime “readiness barrier” so dependent plugins cannot run until storage is ready.
   - Success metric: eliminate need for Milady manual pre-registration; deterministic startup in CI.

2) **Staged runtime refactor plan (reduce blast radius)**
   - Week 1: introduce runtime builder + adapter injection behind compatibility layer.
   - Week 2: migrate first-party plugins; deprecate side-effect registration.
   - Guardrails: API complexity cap (documented by “s” concern); add migration guide + codemod if feasible.

3) **Cloud service integration path**
   - Convert embeddings REST endpoint discussion into a concrete ADR:
     - request/response contract
     - storage semantics
     - auth/rate-limits
   - Tie to Milady “cloud profits → buybacks” narrative by ensuring metering exists (usage tracking).

### B) Security / Trust
4) **Harden official support + anti-phishing**
   - Pin a single “Never share seed phrase” + official links message in key channels.
   - Add a “Known scams” rotating banner in Discord + elizaos.news.
   - Establish a lightweight incident playbook: report → mod verify → broadcast.

### C) Product & Community Comms
5) **Replace repeated token Q&A with canonical artifacts**
   - Publish a short “How value accrues to elizaOS” page (cloud revenue → buybacks; MILADY token utility status).
   - Add a **Milady launch status checklist** (runtime stability, cloud infra, migration/support posture).
   - Success metric: reduce repeated tokenomics questions in 💬-discussion; fewer ad-hoc clarifications needed.

### D) Resourcing (next 2 weeks)
- Allocate:
  - **1 senior engineer** focused on runtime refactor + init determinism (single-threaded ownership).
  - **1 engineer** on Milady launch hardening + cloud metering hooks.
  - **Mod/support lead** to operationalize scam response + migration messaging.
  - **Docs reviewer** to merge PR #243 and keep cloud documentation synchronized with product reality.