# ElizaOS Intel — 2026-02-28 ## Data Coverage / Signal Quality - **Discord daily log for 2026-02-28: missing** (“File not found”). Insights below are derived from **2026-02-25 → 2026-02-27 Discord** plus **Feb monthly GitHub rollup**. - **Recency bias risk:** High for runtime/plugin breakage and compliance topics (dominant on 02-27). --- ## 1) Data Pattern Recognition (Velocity, Engagement, Adoption, Pain Correlation) ### Development velocity (GitHub, Feb-to-date) - **PRs:** 38 opened / **18 merged** (≈47% merge rate) - **Issues:** 41 opened / **65 closed** (net negative backlog movement: **-24**) - **Contributors:** **35 active** - **Code churn:** **+18,576 / -3,807** across **160 files**, **140 commits** - **Qualitative trend:** Maintainers report **external PRs increasing again** (Discord, 02-27), consistent with 35 active contributors. **Interpretation** - Core throughput is healthy, but **integration stability is the limiting factor**: community reports **multiple “broken out-of-the-box” plugins** tied to runtime/version fragmentation. ### Community engagement patterns (Discord, 02-25 → 02-27) - **Recurring themes:** version fragmentation, plugin maintenance, autonomy roadmap confusion, and “real-world” regulated automation use-cases. - **Help interactions observed:** at least **6** (beginner onboarding, production guidance, version guidance, scam warnings). - **Unanswered questions accumulating:** at least **5** across 02-26/02-27 (Twitter input issue versioning, code-bot org behavior, token migration post-deadline, FCRA safeguards, Babylon/milady timing). **Interpretation** - Community is active and contributing, but **support load is being amplified by unclear version support and broken default paths**. ### Feature adoption / usage signals - **Autonomy:** Three competing/overlapping autonomy implementations are “in the wild”: 1) `plugin-autonomous` (periodic thinking) 2) v2.0.0 built-in (Shaw) 3) milaidy project (OpenClaw-like autonomy) - **Enterprise workflows:** concrete demand for agentic ops flows (Meet → Linear, blocked-issue monitoring, PR drafting) indicates **high-value adoption targets** if reliability and versioning are stabilized. - **Cross-platform publishing automation:** community member building bot to post to Discord/X/Telegram—suggests desire for **official “comms automation” reference implementation**. ### Pain point correlation across channels - **#1 correlated pain:** *Version fragmentation → plugin breakage → loss of confidence in “alive/maintained” perception.* - **#2 correlated pain:** *Autonomy roadmap ambiguity → users unsure which system to use / test.* - **#3 correlated pain:** *Compliance + safety concerns rising as plugins move into regulated domains (credit disputes).* - **#4 correlated pain:** *Security hygiene (scam links/DMs) needs consistent, repeated comms + automation.* --- ## 2) User Experience Intelligence (Impact, Themes, Sentiment, Opportunities) ### Feedback themes (categorized by impact) **High impact (blocks adoption / production)** - **Plugins broken out-of-box on 1.7.2** (`plugin-linear`, `plugin-rolodex`, `plugin-memory`) requiring manual patching. - **v2.0.0 alpha instability** + known **bcrypt issue** requiring patches. - **Twitter input not working** (needs version/product details to debug). - Confusion over **which branch to use**: guidance emerged to prefer **`v2-develop` for mature 1.x** over v2.0.0 release. **High impact (safety / legal / trust)** - **Credit-builder plugin** can send certified mail; triggers immediate concern: **FCRA compliance verification** and safeguards against improper disputes (unanswered). - **Hyperscape legal risk** (RuneScape/Jagex) raises contributor hesitation (time investment risk). - **Scam awareness:** users are receiving malicious links/DMs. **Medium impact (DX / clarity)** - Confusion around **token naming/migration** ($elizaOS vs $eliza; migration after deadline). - **Autonomy feature overlap** and unclear recommendation path. - Question about **code bot behavior in org repos** (unanswered). ### Sentiment - **Positive:** excitement about “real-world” plugins (credit-building), external PRs rising, enterprise use-cases being actively discussed. - **Negative/fragile:** “alpha” acknowledgment + broken plugins creates **credibility debt**; users ask if project is “alive.” ### Implementation opportunities (UX wins) - Provide a **single “Supported Paths” matrix**: - Runtime version → recommended branch → compatible plugin versions → known issues/workarounds. - Offer **one canonical autonomy track** (even if multiple exist), with a decision tree: - “If you need cron-like tasks” vs “full autonomy loops” vs “chat-configurable schedules”. - Introduce a **regulated-automation safety checklist** template for plugins (credit/finance/legal). --- ## 3) Strategic Prioritization (Impact vs Risk, Dependencies, Resource Allocation) ### Priority stack (next 2–4 weeks) #### P0 — Restore “works out-of-the-box” for common workflows (highest user impact, moderate tech risk) 1) **Plugin compatibility recovery plan** - Target: `plugin-linear`, `plugin-memory`, `plugin-rolodex` on the recommended stable line (**`v2-develop`/mature 1.x**). - Deliverable: “green path” installation + smoke tests. 2) **v2.0.0 bcrypt issue** - Treat as release-blocker for anyone evaluating v2.0.0; publish patch + advisory. **Why now:** This directly addresses the strongest adoption blocker and the “is this maintained?” perception. #### P0 — Compliance & safety scaffolding for regulated plugins (high impact, high risk if ignored) 3) **Credit-builder compliance guardrails** - Minimum: verification gates + audit logging + human confirmation + “do-not-send” policies by jurisdiction/rule checks. - Provide a reference “Compliance Mode” interface that other regulated plugins can reuse (tickets, collections, disputes). **Why now:** The plugin can trigger real-world harm (and reputational risk) because it sends certified mail. #### P1 — Reduce roadmap confusion and duplicated effort (medium impact, low-to-moderate risk) 4) **Autonomy unification roadmap** - Decide and document: which autonomy system is “recommended”, which are experimental, and migration guidance. 5) **Core vs plugin boundary enforcement** - Review PR **#6531** (plugins creeping into core). Publish architectural rule: what belongs in core vs registry. #### P2 — Trust, comms, and support scaling (medium impact, low risk) 6) **Anti-scam automation + pinned policy** 7) **Cross-platform posting bot** as an official example (Discord/X/Telegram), reducing ad-hoc duplication. --- ## Quantitative KPIs to Track (starting immediately) - **OOB Success Rate (weekly):** % of installs where “create agent + run + add Linear integration” succeeds without patching. Target **>90%** on one blessed path. - **Plugin CI Matrix Coverage:** number of plugins tested across supported runtime versions (target: top 10 plugins). - **Breaking-change frequency:** releases/month with breaking API changes; publish and track. - **Mean time to answer (Discord):** for “blocked” support questions; target <48h for P0 tags. - **Regulated action rate with human confirmation:** % of “send mail / file dispute / submit legal-like action” requiring explicit approval (target: 100% by default). --- ## Actionable Recommendations (Owner-ready) ### Engineering (stability + DX) - Stand up **compatibility CI**: - Nightly smoke tests for top plugins against (a) `v2-develop` (b) latest v2.0.0. - Output a public **“Compatibility Dashboard”**. - Publish a **single blessed installation guide**: - “If you want stability: use `v2-develop` + plugin set X + known patches.” - Add a **version handshake**: - Runtime advertises API/ABI version; plugins declare required range; fail fast with a clear error instead of runtime breakage. ### Product / Platform safety - Create a **Regulated Automation Policy** for the registry: - Required fields: jurisdiction assumptions, verification steps, logging, human approval points, red-flag detection. - For `plugin-credit-builder`: require a **pre-send validation hook** (even if initially manual) and **immutable audit log** of generated letters, evidence sources, and user approvals. ### Community / Support ops - Convert recurring Discord answers into: - A pinned “**Which version should I use?**” post - A pinned “**Autonomy options explained**” post - A pinned “**Scam warning + reporting process**” post - Triage unanswered questions weekly; assign a rotating “**Discord Triage Captain**”. --- ## Key Risks / Dependencies - **Reputational risk:** broken “default path” + alpha messaging without a stable lane can suppress enterprise adoption despite strong framework potential. - **Legal/compliance risk:** real-world certified mail automation without guardrails invites serious blowback. - **Roadmap dilution risk:** multiple autonomy systems without a recommended path increases maintenance burden and user confusion. --- ## Next-step Focus (48–72 hours) 1) Publish **official blessed path**: branch + runtime + known issues (bcrypt) + plugin versions. 2) Open/assign issues for **plugin OOB breakage** (Linear/memory/rolodex) with reproducible CI. 3) Create a **compliance checklist + “human approval required” default** for `plugin-credit-builder`. 4) Decide and document **core vs plugin boundary** while reviewing **PR #6531**.