## User Feedback Analysis — 2026-02-05 (elizaOS) ### Data sources reviewed Discord digests for **2026-02-02, 2026-02-03, 2026-02-04** + GitHub monthly issue rollup (Feb 2026-to-date). --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1. Technical Functionality — **Skill invocation is unreliable (high severity)** **What users report** - Skills often **do not trigger even when available and documented**; one community eval found **skills never triggered in 56% of cases** (R0am, 2026-02-02). - Workarounds require “forced” multi-step prompting/hooking (UserPromptSubmit hook), which makes conversations “weird” but functional. **Who it affects most** - Builders shipping agents with multiple skills/tools; anyone relying on autonomous execution. --- ### 2. Documentation / Communication — **Feature discoverability & “packaging” gap (high frequency, high impact)** **What users report** - Core sentiment: elizaOS has capabilities (cron jobs, autonomy, skills) but **“nobody uses any of it”** due to **poor packaging/presentation** (s, 2026-02-04). - Confusion over core concepts that *should* be obvious: - “dynamic providers vs skill.md” (clarified as effectively the same, but this question repeats) - whether autonomous mode is a plugin vs default (now default via `AgentRuntime({ autonomous: true })`) **Who it affects most** - New developers evaluating framework vs competitors (OpenClaw comparison thread shows UX/presentation is a competitive differentiator). --- ### 3. UX/UI — **Babylon.market onboarding/login is blocking (high severity for that product)** **What users report** - Internal launch testing found multiple hard blockers: - **Farcaster login failures** - **Infinite loading spinners** when switching networks - **Waitlist position not loading** - Users can’t complete the “first session” needed to provide further feedback. **Who it affects most** - All internal testers; likely external users post-launch. --- ### 4. Integration — **OAuth integrations are “architecturally easy” but operationally slow (medium severity, recurring)** **What users report** - OAuth added for X/GitHub/Slack/Linear; Notion next. - Main friction is **credential collection + redirect URI setup per platform** (sam, 2026-02-04). - MCP testing is delayed until OAuth is done; users are already asking if MCP is ready. **Who it affects most** - Developers trying to connect business systems quickly; slows “time to first useful workflow.” --- ### 5. Technical Functionality / Community — **Token migration & staking/unstaking flows create repeated support load (high frequency)** **What users report** - Multiple distinct issues across days: - Missed migration deadline due to notification overload (avirtualfuture) - Bridge site not detecting older tokens (Gumball) - “Max amount reached” migration error (StefanB) - Users reporting **large losses** during transition (one report “over 4k”) - Unstaking “poolparty” tokens confusing/error-prone (Loliño19) - Confusion: **bridging optional vs required**; post-snapshot purchases not auto-migrated - Moderators repeatedly redirect to support channels, indicating the main channels can’t absorb the load. **Who it affects most** - Non-technical holders and newcomers; drains moderator time and damages trust. --- ### 6. UX/UI / Feature Gap — **Image generation lacks visual consistency for iterative design (medium severity, emerging)** **What users report** - In elizacloud.ai, follow-up image edits regenerate an entirely new character; no consistent identity across generations. - Impacts storytelling/branding workflows; users either over-invest in prompt engineering or leave the platform (yojo, 2026-02-02). **Who it affects most** - Creators/marketers using Eliza Cloud for brand assets, narratives, or UI mockups. --- ### 7. Technical Functionality — **Skill ecosystem security concerns (emerging, potentially high severity)** **What users report** - Risk of **malicious skills** (raised re: clawhub); community proposes scanners, rewrite phases, LLM review, and/or sandboxing (Jin, Odilitime, 2026-02-03). **Who it affects most** - Anyone installing 3rd-party skills/plugins; becomes critical once skill distribution scales. --- ## 2) Usage Pattern Analysis (actual vs intended) ### Observed real usage 1. **Autonomous media + community intelligence pipelines** - Jin’s automated AI news show system uses cron jobs + feedback aggregation + publishing. This is effectively “agents as media ops + community ops,” not just chat agents. 2. **Business system integrations via OAuth** - Users are pushing toward “agent in the workflow” (Slack, Linear, GitHub, Notion next) more than standalone assistants. 3. **Crypto/on-chain utility agents** - DIaaS for Solana token signals (Lucas Alpes) + migration/bridging support requests show a strong “agent + on-chain operations” segment. 4. **Local RAG + VPS deployment as a competitive baseline** - OpenClaw praised for smooth CLI/VPS deployment and “self-modifying loops,” setting expectations for elizaOS onboarding and iteration speed. 5. **Creator workflows (branding/storytelling)** - Visual consistency requests indicate an emergent creator segment using Eliza Cloud like an iterative design tool. ### Mismatch vs intended usage (implied) - elizaOS positions as a robust business framework, but users benchmark first impressions on **packaging/UX parity with OpenClaw**. - The platform has autonomy/skills, yet users need “forced activation” patterns, indicating the *intended* “agent chooses tools naturally” isn’t happening reliably. ### Feature requests aligned with actual usage - Default, reliable **tool/skill activation orchestration** - Faster “connect your apps” **OAuth/MCP onboarding** - Safer **skill marketplace / execution sandbox** - **Visual identity persistence** for creator workflows - Better “front door” packaging: quickstarts, templates, examples that match these real use cases (media pipelines, DIaaS plugin, OAuth workflows) --- ## 3) Implementation Opportunities (solutions per major pain point) Below, each pain point includes **2–3 implementable solutions**, prioritized by **Impact / Difficulty**. ### A) Skill invocation unreliability (56% miss rate) 1) **Adopt a default “Tool Selection Gate” in runtime (high impact / medium difficulty)** - Productize R0am’s pattern: a built-in pre-execution step that: - enumerates candidate skills - forces explicit YES/NO selection with brief rationale - triggers selected Skill() calls before free-form response - Similar approach: **Zapier/Composio-style deterministic tool routing** (explicit tool selection step before action). 2) **Improve skill metadata quality + enforce schema linting (medium impact / low difficulty)** - Add CI checks for skill descriptions: required fields, examples, “when to use” prompts. - Ship a `eliza lint-skill` command to catch vague triggers. - Similar approach: **VS Code extension marketplace** style manifest validation. 3) **Add tracing + eval harness for skill calling (high impact / medium difficulty)** - Log “skill considered / skill selected / skill executed / skill failed” events. - Provide a small benchmark suite to measure invocation rate regression over time. --- ### B) Packaging/presentation & feature discoverability 1) **Create 3 opinionated “golden path” starter templates (high impact / low–medium difficulty)** - Templates aligned to observed usage: - “OAuth workflow agent” (Slack/Linear/GitHub) - “Autonomous cron media agent” - “On-chain signals consumer plugin agent” - Similar approach: **Next.js examples directory** and **Supabase starter kits**. 2) **Add an in-product “Capabilities tour” + copy-pastable snippets (medium impact / low difficulty)** - Show the autonomous runtime snippet (`autonomous: true`) and a minimal scheduled task example. - Put “dynamic providers vs skill.md” explanation in the tour + docs glossary. 3) **Ship LLM-optimized docs artifacts (medium impact / low difficulty)** - Implement `llms.txt` + skill creation guides (already discussed by Jin). - Add “common questions” sections sourced from Discord (see Communication Gaps). --- ### C) Babylon.market onboarding blockers (spinners/login/waitlist) 1) **Instrument and fail gracefully (high impact / low–medium difficulty)** - Add client-side timeout + “retry with diagnostics” instead of infinite spinner. - Add error codes for: Farcaster auth failure, RPC/network switch failure, waitlist API failure. - Similar approach: **Stripe-style** actionable error messages; **Sentry** session replay for signup funnels. 2) **Add a “network + wallet preflight checker” (high impact / medium difficulty)** - Before user starts: confirm wallet connected, chain supported, API reachable, Farcaster session valid. 3) **Publish a lightweight status page + known issues list (medium impact / low difficulty)** - Reduces repeated “is it just me?” reports during launch weeks. --- ### D) OAuth integrations operational friction (credentials + redirect URIs) 1) **Build an “Integration Wizard” that outputs provider-specific setup steps + redirect URIs (high impact / medium difficulty)** - Generate exact redirect URIs, env vars, callback routes, and copy buttons. - Similar approach: **NextAuth provider docs + guided setup**, **Supabase OAuth setup UX**. 2) **Provide “managed OAuth” presets for common providers (medium impact / high difficulty)** - Where feasible, offer a hosted callback + managed client IDs (users bring secrets only when necessary). 3) **Add MCP readiness messaging + milestone checklist (medium impact / low difficulty)** - Prevent repeated questions by publishing: “OAuth done for X/Y/Z; MCP testing starts after Notion.” --- ### E) Token migration + unstaking support burden 1) **Create a single “Migration Hub” page with decision tree (high impact / low difficulty)** - Covers: missed deadline, pre-Nov tokens not detected, “max amount reached,” post-snapshot buyers, bridging optional, unstaking steps. - Include screenshots and exact error-message mapping. 2) **Add multi-channel deadline & incident notifications (high impact / medium difficulty)** - Discord announcements are not enough; add: - email (if available) - in-app banner - pinned posts per relevant channel - calendar reminders for major deadlines - Similar approach: **Ethereum L2 migrations** and **CEX token swap comms** use repeated multi-channel reminders + pinned hub. 3) **Structured support intake form that generates a support ticket (medium impact / low difficulty)** - Collect wallet chain, token age, error message, txid; routes to the right helpers and reduces back-and-forth. --- ### F) Visual consistency in image generation (creator workflows) 1) **Add “character/brand identity lock” via LoRA or embedding-based identity (high impact / high difficulty)** - Expose a simple UI: “Create Identity → reuse in variations.” - Similar approach: creator tools that support “character reference” workflows. 2) **Support partial edits (inpainting / edit region) instead of full regeneration (high impact / medium difficulty)** - Meets user request: remove accessory / change context while keeping face/style. 3) **Short-term workaround: official recipe + template prompts (medium impact / low difficulty)** - Document a “consistency pack” prompt format, seed handling, and negative prompts while native identity is built. --- ### G) Skill ecosystem security (malicious skills risk) 1) **Sandbox skill execution (high impact / high difficulty)** - Run untrusted skills in constrained environments (network/file/system call restrictions). - Similar approach: **browser extension permission model** + **serverless sandboxing** patterns. 2) **Introduce skill signing + trust tiers (high impact / medium difficulty)** - Verified publisher badges, signed releases, checksum pinning. 3) **Automated scanning pipeline (medium impact / medium difficulty)** - Static analysis + “LLM review” + rewrite/adaptation step (as proposed). - Block or flag suspicious behavior (exfiltration attempts, hidden network calls). --- ## 4) Communication Gaps (expectations vs reality) ### Recurring expectation mismatches - **“Bridging is required” vs reality:** bridging from Solana is **optional**, but users repeatedly ask. - **Migration deadline comprehension:** users missed the 3-month window due to **notification overload**, indicating announcements didn’t “land.” - **Autonomous mode availability:** users still treat autonomy as optional/add-on; reality is it’s integrated by default in new Eliza. - **Concept confusion:** “dynamic provider vs skill.md” repeatedly asked, suggesting terminology isn’t anchored in docs/UI. - **Branch confusion (dev reality vs user expectations):** suggestion to use `odi-dev` over `main` implies “main” may not be the best user experience, but this isn’t communicated as a stable/recommended path. ### Specific doc/onboarding fixes - Add a **“Top 10 questions from Discord”** page updated weekly (migration, bridging, unstaking, autonomy default, providers vs skill.md). - Add **one canonical “Getting Started (2026)”** page that matches what maintainers actually recommend (branch/version clarity). - Add a **“Competitor comparison”** page that explicitly acknowledges OpenClaw’s UX strengths and shows elizaOS equivalents (with runnable demos). --- ## 5) Community Engagement Insights ### Power users and what they need - **Jin**: building agentic media infrastructure; needs reliable autonomy primitives, scheduling, deployment, and feedback loops. - **Odilitime**: heavy community support + plugin/security thinking; needs structured support tools and clearer docs to reduce repetitive Q&A. - **Stan ⚡**: standardization (providers/skills), Cloud patterns; needs better developer ergonomics and consistent abstractions. - **Sam**: OAuth/integration execution; needs tooling to reduce provider-by-provider setup overhead. - **R0am**: evaluation-driven reliability improvements; needs a path to upstream proven orchestration patterns. - **0xbbjoker**: plugin/dev support; needs clearer plugin standards and “known working” integration baselines. ### Newcomer friction signals (common questions) - Token migration/bridging/unstaking basics - Babylon waitlist status and login problems - “Is feature X available yet?” (MCP after OAuth) - Confusion about skills standards (Claude skills vs Moltbot skills) ### Converting passive users into contributors - Create “micro-contribution lanes”: 1) **Docs bounty board** (migration hub, glossary, quickstarts) 2) **Reproducers wanted** (Babylon spinner/login, migration errors) 3) **Skill metadata improvements** (examples, triggers, manifests) - Run monthly “office hours” focused on one theme (e.g., “OAuth + MCP integrations day”, “Skill reliability day”). --- ## 6) Feedback Collection Improvements ### Current effectiveness - Discord is producing high-value signals but they’re **unstructured**, and many issues are handled via redirection to support channels—good for triage, but bad for trend visibility. - Some critical problems (e.g., “lost 4k on migration”) risk getting buried without consistent intake structure. ### Improvements (structured + actionable) 1) **Standardized intake forms** - For: migration issues, Babylon onboarding bugs, OAuth provider setup problems. - Auto-generate GitHub issues (or internal tickets) with required fields (error text, screenshots, txid, provider name). 2) **In-app feedback widgets for Eliza Cloud/Babylon** - Capture: “what were you trying to do,” “where did you get stuck,” session logs. 3) **Weekly “top friction metrics” dashboard** - Track: skill invocation rate, OAuth setup completion time, Babylon signup funnel drop-offs, migration ticket categories. ### Underrepresented segments - **Non-crypto SaaS builders** (interested in Slack/Linear/Notion workflows but not active in token channels) - **Windows/Linux developers** (tooling limitations surfaced; likely more friction but little direct feedback) - **Creator/brand users** (visual consistency emerged once; likely more demand than currently visible) --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Make skill invocation reliable by default** - Upstream the “tool selection gate” pattern (based on R0am’s proven hook) + add tracing. 2) **Ship a “Migration Hub” + structured support intake** - One canonical page + a form that captures txids/errors; reduce repeated Discord cycles and reputational damage. 3) **Fix Babylon.market onboarding blockers with instrumentation** - Replace infinite spinners with actionable errors; add preflight checks; collect funnel diagnostics. 4) **Launch 3 “golden path” starter templates** - OAuth workflow agent, autonomous cron/media agent, on-chain signals plugin agent—tight, runnable, and marketed as the default entry points. 5) **Reduce OAuth setup time via an Integration Wizard** - Provider-specific redirect URI generator + checklist; publish MCP timeline/status to align expectations.