# User Feedback Analysis — 2026-01-27 (elizaOS) ## 1) Pain Point Categorization (Top recurring friction areas) > Data basis: Discord summaries (2026-01-24 to 2026-01-26) + notable GitHub issues/roadmap signals surfaced in the same window. ### A. Documentation 1) **Token migration guidance is unclear and easy to spoof** - Evidence: - Discord users asked “How can I migrate from Ledger?” and “How do I migrate ai16z token to elizaos?” and were redirected to a ticket channel rather than a canonical doc. - A documented **migration scam** asked users to send tokens to a wallet for “manual migration” (wallet address shared publicly). - Another suspicious “Create A Ticket” bot requested wallet addresses. - Impact: High (users can lose funds); Frequency: High (migration + scam topics appear across multiple days). 2) **Action callback semantics are confusing vs docs** - Evidence: Victor Creed reported that in **v1.7.2** plugin action handler callbacks “only send the first callback” and callbacks appear **at action completion**, not as immediate feedback “as documented.” - Impact: Medium–High (breaks interactive UX patterns); Frequency: Medium (one deep thread, but high developer impact). 3) **Model naming / mapping confusion (Opus/Sonnet vs Ultra/Pro)** - Evidence: An “urgent” internal note about a proposed swap in understanding (“Opus to Ultra, Sonnet to Pro”), plus GitHub issue “Opus - pro and Ultra - sonnet? Is this right?” (#6390). - Impact: Medium (misconfiguration, wrong cost/perf expectations); Frequency: Medium (explicitly flagged urgent). --- ### B. Technical Functionality 4) **Plugin callback behavior appears planner-dependent, but defaults don’t match expectations** - Evidence: Troubleshooting centered on whether the user is using **onestep vs multistep** planner; user was on defaults (onestep). Multiple callbacks are “supported,” but the observed runtime behavior doesn’t align. - Impact: Medium (limits progressive UI, streaming-like interactions); Frequency: Medium. 5) **CLI / upgrade and migration failures during version changes** - Evidence: - Discord: YogaFlame hit persistent version conflicts updating **1.6.5 → 1.7.2**, SQL migration failures, and Discord plugin bootstrap errors due to caching. - GitHub: “Can not generate project” (#6388) shows a real-world onboarding failure path (ERR_PACKAGE_PATH_NOT_EXPORTED) when running `elizaos create`. - Impact: High (blocks adoption); Frequency: Medium–High (multiple separate reports, different failure modes). --- ### C. Security (Integration + Community) 6) **Active scam attempts exploiting support flows and token migration confusion** - Evidence (at least 3 distinct scam vectors mentioned): - Fake “Create A Ticket” bot requesting wallet addresses + suspicious links. - Fake “manual migration” instruction with destination wallet address. - “BitMart listing team inquiry” flagged as potential scam in coders channel context. - Impact: Very High (direct user loss + reputational damage); Frequency: High. --- ### D. Community / Expectation Management 7) **Ecosystem token strategy and “project focus” are polarizing** - Evidence: - Jan 24 debate: backlash over launching separate ecosystem tokens (e.g., Hyperscape “gold”) vs focusing on $elizaos; concerns about dilution and reputation. - Jan 26: token ATL anxiety and “lack of team communication during downturn.” - A question about relationships between tokens and ElizaOS core went unanswered (Jan 25). - Impact: High (trust + retention); Frequency: High. --- ## 2) Usage Pattern Analysis (Actual vs intended usage) ### How users are actually using elizaOS 1) **Eliza Cloud as an orchestration layer for external tools via MCP** - SATA’s use case: adding **external MCP servers** to Cloud agents for **AI red teaming** with human-in-the-loop workflows, using `POST /api/v1/mcps`. - This indicates real demand for “agent as a proxy/router” patterns, not just chat agents. 2) **Always-on/self-hosted agents on low-power hardware** - Community reports: deploying Eliza on **mini PCs** to keep agents running 24/7; interest in **Oracle Cloud free tier** specs (4 vCPU, 24GB RAM) suggests cost-sensitive “home lab” usage. 3) **Automation-heavy creative workflows** - DaVinci Resolve MCP integration work targets timeline operations, effects, audio management, transcription-based trimming, and even style transformation. This is closer to “agentic RPA for creative tools” than typical chatbot usage. 4) **Consumer assistant distribution via third-party platforms** - Partnership discussion: ship Eliza as a “Claude-style assistant” on Seeker phone Dapp store, aiming for standout distribution. 5) **Emerging “AI companion/game agent” experimentation** - Community explored stacks combining Eliza + other memory/agent systems (Clawde/Letta/local LLMs) and asked “why not Digimon-like companions,” implying demand for long-lived persona + memory + multi-modal hooks. ### Feature requests aligned with real usage patterns - Better **MCP server registration UX** (not just raw API) + examples. - Stronger **deployment templates** (mini PC, Oracle, Docker, reverse proxy). - More reliable **progressive feedback** patterns (callbacks/streaming events) for tool automation and multi-step tasks. - Clear **multi-tenant/session isolation** and secrets management (already on roadmap; matches Cloud + external tools + always-on hosting). --- ## 3) Implementation Opportunities (Concrete solutions per major pain point) ### Pain Point 1: Token migration confusion + scams (High impact, moderate effort) **Solutions (prioritized):** 1) **Publish a single canonical “Migration & Support Safety” page and pin it everywhere** - Include: official domains, “we never ask for wallet seed / send-to-migrate,” known scam patterns, and the only valid ticket entry point. - Add a short “verify before you click” checklist. - Similar approach: Solana/Uniswap-style permanent “scam warning” pages linked from all official comms. 2) **Harden Discord support flows** - Disable or tightly permission any “ticket bots”; require verified roles; add AutoMod rules blocking wallet-address solicitations and common scam phrases. - Add an official bot command `/support` that only posts the real ticket channel + doc links. 3) **Add signed verification to migration portal communications** - Put a “Support will never DM you first” banner on migrate portal. - Optional: publish a rotating “support signing key” concept (PGP-like) or an on-chain verification message for announcements. --- ### Pain Point 2: CLI/project creation & upgrades breaking (High impact, moderate–high effort) **Solutions (prioritized):** 1) **Add “doctor” and “clean install” commands to CLI** - `elizaos doctor`: checks Node/Bun versions, global install conflicts, cache state, and plugin version mismatches; prints exact remediation. - `elizaos repair --clean`: automates cache removal (`bun pm cache rm`), reinstalls CLI, and validates package.json versions. - Similar approach: `flutter doctor`, `rustup doctor`-style guided diagnostics. 2) **Ship an upgrade guide that matches real failure modes** - Add a “1.6.x → 1.7.x” migration doc with: cache pitfalls, SQL migration troubleshooting, Discord plugin compatibility notes (e.g., plugin-discord 1.3.8 fixed bootstrap errors). - Include copy-paste sequences like 0xbbjoker provided (proven in the wild). 3) **Reduce global install ambiguity** - Ensure docs recommend the correct package (`@elizaos/cli` vs `elizaos`) and verify that `elizaos create` path is robust under Node 22+ ESM export rules (as seen in #6388). - Add a preflight check that fails with a friendly message instead of raw ESM errors. --- ### Pain Point 3: Plugin action handler callbacks not behaving as expected (Medium–high impact, moderate effort) **Solutions (prioritized):** 1) **Create a minimal reproducible test and a “callback contract” spec** - Add an integration test asserting: - multiple callbacks reach the client - callback timing semantics (immediate vs completion) are consistent across planners - Similar approach: Temporal and LangChain add “event stream contract tests” to ensure tool-running UIs don’t regress. 2) **Unify callbacks with streaming/events** - Expose a single “ActionEvent stream” API (progress, partial result, completion) that works in onestep and multistep. - This reduces planner-specific surprises and aligns with emerging streaming patterns already present elsewhere in the codebase. 3) **Document planner interaction explicitly** - Add a table: onestep vs multistep behaviors for callbacks, retries, and intermediate outputs; include “recommended config for tool automation.” --- ### Pain Point 4: Model naming/mapping confusion (Medium impact, low effort) **Solutions (prioritized):** 1) **Centralize model aliases and display them in UI/docs** - One canonical mapping file used by code + docs generation. - UI should show “Provider model name” and “Eliza alias” side-by-side. 2) **Add validation warnings** - If a user selects Opus but the config maps to “Pro,” show a warning: “Check mapping: Opus ↔ Ultra (expected).” 3) **Release-note style comms** - When mapping changes, ship a short migration note: “This affects cost/perf; verify config.” --- ### Pain Point 5: Ecosystem token strategy + trust gaps (High impact, high complexity) **Solutions (prioritized):** 1) **Publish a clear “Token & Ecosystem Policy”** - Explicitly define: which tokens are official, how ecosystem tokens relate (or don’t), and what holder expectations should be. - Include “why” (runway constraints were shared in chat; formalize this context). 2) **Add $elizaos utility hooks in ecosystem apps (align incentives)** - Implement the proposed pattern: platform fees for compute/storage, burns/fees on item/agent creation where appropriate. - Similar approach: many ecosystems tie utility to network fees rather than proliferating governance tokens. 3) **Introduce a transparent grants/launch framework** - If ecosystem tokens exist, standardize: - disclosure requirements - (optional) airdrop/pairing guidelines - conflict-of-interest statements - Reduces reputational volatility and sets predictable expectations. --- ## 4) Communication Gaps (Expectation vs reality) 1) **“Migration is simple” vs reality of hardware wallets + snapshots** - GitHub migration issue (#6369) shows edge cases (Tangem snapshot mismatch) that users can’t self-resolve. - Improvement: publish a “known issues” section with timelines and a manual-review SLA. 2) **“Multiple callbacks supported” vs user-observed behavior** - Users expect immediate progress updates; they’re seeing callbacks only at completion under defaults. - Improvement: explicitly document that planner choice may alter callback delivery semantics, or (better) make semantics consistent. 3) **Token ecosystem ambiguity** - Repeated questions: token validity, migration legitimacy, relationships between tokens ($STUDIO, ecosystem “gold,” $elizaos). - Improvement: maintain a single canonical “Official assets & relationships” page and link it whenever token talk arises. 4) **Support entry points are discoverable only socially** - Users ask “How do I open a ticket?” and are given a channel ID. That’s fragile and easy for scammers to spoof. - Improvement: add support links in docs UI, migration portal, README, and a Discord `/support` command. --- ## 5) Community Engagement Insights ### Power users & what they need - **Odilitime**: repeatedly troubleshooting + confirming framework capabilities (callbacks), security warnings, and ecosystem coordination. Needs: better tooling for triage (templates, reproducible bug kits) and authority to pin canonical answers. - **0xbbjoker**: effective “fix steps” for CLI/version conflicts; needs: those steps upstreamed into docs + automated via CLI. - **SOLOMON VANDY**: provides concrete Cloud API guidance (`POST /api/v1/mcps`); needs: an official MCP “how-to” and possibly a first-class UI. - **DorianD**: proposing token utility integration mechanics; needs: a venue (RFC process) where proposals become trackable decisions. - **Irie_Rubz / PatoVeloso**: building/validating DaVinci MCP; needs: plugin showcase + API limitation documentation patterns. ### Newcomer questions indicating onboarding friction - “What is Seeker app?” - “How do I open a ticket?” - “How do I migrate from Ledger / ai16z?” - “Why doesn’t `elizaos create` work?” These are “first 30 minutes” questions—ideal targets for a tightened onboarding funnel. ### Converting passive users into contributors - Add a “Good First Issue: docs fixes” track specifically for: - migration safety page - CLI upgrade troubleshooting - MCP examples - Recognize helpers weekly (Odilitime/0xbbjoker/SOLOMON VANDY) and invite them to co-own docs pages they already answer repeatedly. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord**: great for rapid help, but answers are ephemeral and scammers exploit the same social pathways. - **GitHub issues**: strong for technical bugs (CLI errors, model mapping), but token/migration/support questions spill into Discord and tickets. - **Ticket channel**: works for case handling, but is currently discoverable mainly by asking publicly, increasing scam surface area. ### Improvements for more structured, actionable feedback 1) **Standardized intake forms** - “Migration issue” form: wallet type, snapshot tx, portal screenshot, error codes. - “CLI issue” form: OS, Node/Bun versions, install method, `elizaos --version`, logs. 2) **Monthly “top recurring Discord questions” digestion** - Auto-summarize and convert into docs PRs (closing the loop). 3) **Underrepresented segments to actively solicit** - **Non-crypto developers** exploring agent automation (e.g., video editors, creative tool users) — currently represented by a few individuals, but likely to grow. - **Self-hosters** on low-cost infra — need official “supported deployment matrix.” - **Enterprise/security users** (red teaming, compliance) — MCP use case suggests demand, but requirements aren’t systematically captured. --- ## Prioritized High-Impact Actions (Next 1–2 weeks) 1) **Ship an official “Migration & Scam Safety” hub page + pin/automate it in Discord** (highest user-risk reduction; low–moderate effort). 2) **Add `elizaos doctor` + publish a “clean reinstall / upgrade” guide (1.6→1.7)** (unblocks onboarding; moderate effort, high impact). 3) **Close the callback gap: reproduce on v1.7.2 defaults + document planner semantics or unify via event streaming** (developer trust; moderate effort). 4) **Resolve model naming confusion with a single canonical mapping + UI/docs surfacing** (low effort; prevents costly misconfiguration). 5) **Publish a concise “Token & Ecosystem Policy” FAQ answering relationship/strategy questions** (trust stabilization; moderate effort, high impact).