# Intel — 2026-03-14 (ElizaOS)

## 1) Data Pattern Recognition

### Activity & velocity (last 72h view: 2026-03-11 → 2026-03-13)
- **Conversation intensity**
  - **Mar 11:** High breadth (launch + release + security + comms tooling).
  - **Mar 12:** High depth (runtime refactor proposal + tokenomics clarification + registry/orchestration demo).
  - **Mar 13:** Split signal: **light in general chat**, **practical “how-to” in coders** (scheduling/automation); recurring migration/scam questions.
- **Help interactions (counted from summaries)**
  - **Mar 11:** 5
  - **Mar 12:** 4
  - **Mar 13:** 2 (migration + moderation) *(coders channel likely had more back-and-forth, but only 2 explicitly logged as “help interactions” in provided rollups)*
  - **Trend:** Support load is shifting from “project status reassurance” (Mar 11) → “architecture correctness” (Mar 12) → “operational usage” (Mar 13 scheduling) plus persistent **security/migration** issues.

### Emerging patterns
- **Recurring security incidents cluster around token migration**
  - Migration is **closed (closed Feb 4, 2026)**, yet questions continue.
  - Scams are adapting: fake “support bot” + seed phrase collection; fake “Discord wallet linking required”.
  - **Pattern:** Each new “closed migration” inquiry creates a scam opportunity window.
- **Feature adoption / usage reality vs intended design**
  - Teams/users are actively building “agent wake-up / scheduled posting” behaviors.
  - Practice is bifurcated by version:
    - **ElizaOS 2.x:** `plugin-cron`
    - **ElizaOS 1.x:** `plugin-heartbeat`
  - Compatibility friction surfaced explicitly (user on **1.7.2** trying to adapt newer scheduling code).
- **Architecture pressure point**
  - Runtime refactor proposal is motivated by a concrete reliability failure mode:
    - `plugin-sql` registers DB adapter as **side-effect during parallel `init()`**
    - Downstream plugins (e.g., personality) can run before adapter exists → race condition
    - Mraidy workaround: pre-register `plugin-sql` manually (symptom treatment).

### Quant signals worth tracking (from provided data)
- **Agent registry orchestration (external)**
  - 14 live agents reported.
  - REST endpoints: `/api/agents/register`, `/api/agents`.
  - Auto-approver scoring: 1–10.
- **Roadmap timing**
  - Milady app: “~2 weeks from Mar 12” ⇒ target window ~**Mar 26, 2026**.

---

## 2) User Experience Intelligence

### Feedback themes (categorized by impact)

#### A) Security & Trust (High impact, high urgency)
- **User pain:** Confusion about migration status + urgent desire for late migration.
- **Observed behavior:** Users ask publicly for help → scammers DM quickly with fake flows.
- **Sentiment:** Anxiety + urgency (fertile ground for social engineering).
- **Opportunity:** Reduce “time-to-clarity” with canonical links and automated warnings at the point of question.

#### B) Reliability & Developer Ergonomics (High impact, medium urgency)
- **Pain point:** Plugin initialization order is non-deterministic in practice; required infrastructure appears as side-effects.
- **User impact:** “Works in one app (mraidy) with defensive ordering, breaks elsewhere” → undermines confidence in plugin ecosystem.
- **Opportunity:** Make runtime composition explicit; improve invariants (“if plugin depends on DB, it cannot construct without it”).

#### C) Agent Operations / Scheduling (Medium–High impact, immediate adoption demand)
- **Pain point:** “How do I schedule Discord posting / wake agents without manual triggers?”
- **Usage pattern:** People want autonomous operation (1–3 hour cron loops; scheduled tasks).
- **Friction:** Version split (1.x heartbeat vs 2.x cron) + scattered examples (Spartan repo references).
- **Opportunity:** Provide a single “Scheduling Cookbook” with versioned snippets and migration guidance.

#### D) Product/Token Narrative Clarity (Medium impact, ongoing)
- **Pain point:** Token holder value capture confusion (Milady token vs elizaOS token).
- **Resolution provided:** Cloud profits → buybacks of **elizaOS** (not Milady token); team allocation 10% vested; reported low selling.
- **Opportunity:** Convert Discord explanations into an official, frequently-linked doc; reduce repetitive Q&A load.

---

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

### Priority 0 — Security comms hardening around migration (High impact, low–medium engineering risk)
**Why now:** Migration questions are still arriving daily; scams are active and contextual.

**Recommendations**
1. **Canonical “Migration Is Closed” landing page** (single URL) with:
   - closure date (Feb 4, 2026), rationale, and “no late migration path currently”
   - explicit scam examples (seed phrase requests, wallet-linking claims)
   - what staff/mods will *never* ask for (seed phrase, private key)
2. **Discord automations**
   - Auto-reply keyword triggers for “migrate”, “AI16Z”, “deadline”, “support ticket” linking to the canonical page.
   - Mod-only pinned message in relevant channels with the same link.
3. **Incident telemetry**
   - Lightweight internal log: count migration inquiries/week, scam reports/week, and “user claimed compromised” count.

**Success metrics**
- ≥50% reduction in repeated migration questions within 2 weeks (proxy: keyword-trigger counts).
- Increased scam-report-to-compromise ratio (more reports, fewer victims).

---

### Priority 1 — Runtime refactor to eliminate plugin side-effect initialization (High impact, medium engineering risk, critical dependency)
**Why now:** This is a foundational correctness issue that affects plugin ecosystem reliability and blocks clean scaling.

**Critical path dependencies**
- Define a **runtime composition contract**:
  - required resources passed via constructor/DI (e.g., DB adapter)
  - plugin capabilities declared (needs/provides)
- Update `plugin-sql` and any plugins relying on implicit adapter registration.
- Provide migration guidance for plugin authors.

**Recommendations**
1. **Adopt “explicit provides/requires” manifest**
   - Minimum viable: `requires: ["dbAdapter"]`, `provides: ["dbAdapter"]`
2. **Change DB adapter acquisition**
   - “Adapter is a required constructor arg” (as discussed) or resolved via runtime DI container before plugin init.
3. **Integration test**
   - A deterministic test that runs plugin init in parallel and asserts no plugin accesses DB before adapter is available.

**Success metrics**
- Eliminate mraidy’s defensive manual pre-registration.
- Reduced “order-dependent” bug reports; stable init across parallel execution.

---

### Priority 2 — Scheduling & automation UX: unify guidance across 1.x and 2.x (Medium–High impact, low engineering risk)
**Why now:** Clear demand; immediate productivity unlock; reduces support burden.

**Recommendations**
1. Publish a **“Scheduling Cookbook”**:
   - 2.x: `plugin-cron` examples (Discord posting, wake-ups)
   - 1.x: `plugin-heartbeat` equivalents
   - “If you are on 1.7.2” compatibility notes and minimal backport steps
2. Extract Spartan examples into a small “reference implementations” folder or docs:
   - `tsk_discord_post.ts`, DM utilities, cron patterns
3. Add a short “Autonomy patterns” guide:
   - cadence selection (e.g., 1–3 hours), rate limiting, safe retries, idempotency

**Success metrics**
- Fewer scheduling questions in coders channel week-over-week.
- More agents running unattended without manual triggers (proxy: community self-reports).

---

### Priority 3 — Release readiness: Milady app (~Mar 26 target) + cloud/buyback narrative (High impact, higher execution risk)
**Why now:** Time-bound milestone; narrative and product experience will strongly affect sentiment.

**Recommendations**
1. Create a **Milady release checklist** with owners:
   - reliability (cron/jobs, embeddings endpoint if required)
   - security model alignment (wallet isolation principles)
   - operational monitoring + rollback plan
2. Publish **tokenomics explainer** derived from Discord Q&A:
   - cloud revenue → elizaOS buybacks
   - what token holders should expect (and what not)
3. Prepare comms assets:
   - concise release announcement
   - “how to get started” onboarding
   - FAQ addressing the most repeated Discord questions

**Success metrics**
- On-time release within stated window.
- Reduced “is there any token use case?” repeats (proxy: FAQ link shares vs repeated explanations).

---

## Resource Allocation (next 2 weeks)
- **Engineering (core runtime): 45%**
  - runtime refactor + plugin dependency contract + regression tests
- **DevEx/docs: 25%**
  - scheduling cookbook + version compatibility notes + reference snippets
- **Security/community ops: 20%**
  - migration/scam automations, canonical pages, moderation playbooks
- **Product launch support (Milady): 10%**
  - release checklist, onboarding, metrics instrumentation

---

## Watchlist (signals to monitor)
- **Scam evolution:** new domains, fake bots, impersonation patterns.
- **Version fragmentation:** continued 1.x vs 2.x confusion; measure how many users are blocked on 1.7.2.
- **Sentiment drivers:** token price anxiety correlates with “devs left?” questions; mitigate with visible shipping artifacts (release notes, demos, roadmap checkpoints).
- **External ecosystem pull:** agent registry/orchestration work (14 agents) and new plugins (e.g., PumpFun buyback payments) suggest growing composability needs—strengthens the case for explicit runtime contracts and stable plugin init semantics.