## User Feedback Analysis — 2026-04-10 (based on 2026-04-07 to 2026-04-09 Discord + early-Apr GitHub issues/PR reviews) ### Data notes The qualitative sample is small and skewed toward Discord “general discussion” plus a handful of high-signal GitHub issues/PR review findings. Percentages below are therefore **directional** (computed from ~10–12 distinct feedback threads/questions surfaced in the provided data), but still useful for prioritization. --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1) Documentation — unclear project/product boundaries (high frequency, high severity) **Category:** Documentation **What users report** - Repeated confusion about **what elizabao_ai is and what a user can do today** (Discord; cryptovalutchik_ asked directly; baogerbao noted many are asking). This is the single most repeated “what is this?” topic in the sample. - Unclear **release status and availability** of “Eliza v3 (version 2.x)” (Discord: “where is code?”, “when release?”), and what “integrated into milady” practically means. - Confusion about **chain focus** (users asking if ElizaOS is “moving from Solana to ETH”; clarified as multichain). **Estimated prevalence:** ~30–40% of surfaced user questions center on “what is X / what can I do now / where is it?” --- ### 2) UX/UI + Onboarding — deploying and getting started has too many “paths” (medium frequency, high severity) **Category:** UX/UI + Documentation **What users report** - Strong pull toward **no-code / one-click deployment** via Hatcher.host (praised as smooth, live logs, Groq integration). This implies current “official” deployment/onboarding feels heavyweight for many users. - CLI onboarding failure mode is severe: `elizaos create` can fail and then **cleans up the directory leaving nothing** (GitHub issue #6704), which is a frustrating UX even when the underlying cause is dependency-related. **Estimated prevalence:** ~20–30% of items relate to “how do I start/run/deploy without pain?” --- ### 3) Technical Functionality — safety/authorization gaps for tool execution (medium frequency, very high severity) **Category:** Technical Functionality / Security **What users report** - Direct concern: **prevent agents from performing unsafe operations** (Discord; unresolved). - Multiple GitHub proposals point to the same need: - Capability token enforcement for tool calls (#6707). - Delegation/scoped authority concept (#6711, referenced in weekly contributor logs). - Token safety checks pre-trade (#6706). - Strategic direction in weekly summary reinforces this: AgentID, capability-based authorization, trust/identity. **Estimated prevalence:** While fewer threads mention it explicitly than docs/onboarding, severity is **highest** because it affects funds, posting, and irreversible actions. --- ### 4) Integration — plugin/connector compatibility + feature parity friction (medium frequency, medium severity) **Category:** Integration **What users report** - Anthropic plugin: Opus 4.x compatibility fixes required (parameter rename `maxTokens` → `maxOutputTokens`), plus event payload compatibility still WIP. - Discord connector/“toon” encapsulation: required params missing for certain actions unless schema asks for them (PR #6709). Also async task actions caused **continuation loop spam** until fixed. - Discord plugin “feature parity” requests are explicitly listed as WIP (typing indicators, reactions, streaming, slash commands). - Telegram plugin UI tweaks (“narrow chat display names”) indicates ongoing UI polish needs. **Estimated prevalence:** ~20% of surfaced feedback is “connector/plugin doesn’t behave like users expect.” --- ### 5) Performance/Robustness — latency defaults and runtime hardening side effects (lower frequency, medium severity) **Category:** Performance / Technical Functionality **What users report (via PR review findings)** - Provider timeouts and total timeout defaults changed (PR #6562 review notes potential P99 latency impact). - Observability/logging improvements are welcomed, but changes carry regression risk in response latency/persistence. **Estimated prevalence:** lower in Discord chatter, but shows up in code review as a real risk area. --- ### 6) Community — trust, moderation, and coordination gaps (medium frequency, medium severity) **Category:** Community **What users report** - Frustration about people “talking about plans but not following through.” - No ticket system for Discord promotional pushes (explicitly asked; answer: none). - Scammers being flagged repeatedly (Discord moderation load). - Token price discussion dominated conversation with negative sentiment (95% decline mentioned), drowning out product support. **Estimated prevalence:** ~20–30% of Discord narrative is community health/moderation/coordination rather than product usage. --- ### 7) Developer Experience — environment-specific install/workspace issues (lower frequency, high severity when hit) **Category:** Technical Functionality / DX **What users report** - macOS + bun: `elizaos create` fails due to bun postinstall/runtime dependency behavior (#6704). - Submodule/workspace workflow risks breaking fresh clones (PR #6702 review: workspace entries committed, bun.lock mismatch). **Estimated prevalence:** fewer users, but “hard stop” failures for affected segment. --- ## 2) Usage Pattern Analysis (actual vs intended) ### How users are actually using elizaOS 1) **“Deploy first, code later”**: The community is actively adopting **no-code serverless deployment** (Hatcher.host) to run agents quickly, with dashboards and live logs. This suggests a large segment wants an “agent hosting product” experience, not just a framework. 2) **Agents as crypto-economic actors**: Many ecosystem proposals and weekly strategy focus on wallets, swaps, escrow, token safety, marketplaces, and “agent economies” (wallet plugin, SafeAgent, MAXIA marketplace proposal, AIGEN incentives, MnemoPay “economic memory”). 3) **Chat connectors as primary UI**: Discord/Telegram connectors and reply behavior (group addressee routing, anti-loop prompts) are central to perceived product quality; “agent quality” is being judged through chat UX. ### Emerging / unexpected use cases - **Prediction market agents** planned around elizabao_ai + elizacloud integration (community interest rising even before functionality is clear). - **Agent reputation/economic memory** (plugin-mnemopay PR) indicates users want agents that learn from transactions over time. ### Feature requests aligned with observed usage - Safer tool execution: capability tokens, scoped authority, pre-trade checks. - Better connector parity (Discord) and reduced multi-party chat loops. - More “productized” deployment paths (one-click hosting, templates, dashboards). --- ## 3) Implementation Opportunities (solutions per major pain point) ### A) Documentation gap: “What is elizabao_ai / what can I do now?” **Opportunities (high impact, low–medium effort)** 1. **Ship a single “elizabao_ai status” page** (README or docs page) with: - What it is, current stage (“in development”), what’s usable today, roadmap, and how to get access (if any). - A “Try it now” section (even if the answer is “not yet”), plus links to related repos/branches. 2. **Add “Project Status Cards”** in docs for major initiatives (Eliza v3, AgentID, elizacloud, elizabao_ai) with: owner, maturity (alpha/beta), last update date. 3. **Set expectation banners in Discord** (pinned FAQ in relevant channels): “elizabao_ai is not user-ready yet; here’s what you *can* do today instead.” **Comparable approaches** - Kubernetes SIGs use “KEP status” and “graduation levels” to make maturity explicit. - LangChain/LlamaIndex maintain “integrations index” with maturity tags and minimal examples. --- ### B) Onboarding/deployment fragmentation (Hatcher.host vs CLI vs repo dev harness) **Opportunities (high impact, medium effort)** 1. **Define 3 official onboarding tracks** (and link them everywhere): - “Run locally in 5 minutes” (agent/ REPL harness). - “Deploy hosted/no-code” (Hatcher.host or official elizacloud when ready). - “Build a plugin/connector” (dev-focused). 2. **Make `elizaos create` non-destructive on failure**: - Keep the generated directory; print next steps + a `--verbose` flag output. 3. **Create a “deployment decision tree”** in docs: - “If you want Discord bot → use X connector + recommended host.” - “If you want economic agent → start from wallet plugin template + safety checklist.” **Comparable approaches** - Next.js offers “create-next-app” plus Vercel as a parallel official path; both are documented as first-class, not competing. --- ### C) Safety/authorization for tool calls (unsafe ops, trading, posting) **Opportunities (very high impact, medium–high effort)** 1. **Introduce a core “Capabilities / Approval Gate” interface**: - Pluggable policy engine (allow/deny/require human approval) per tool/action. - Default policies for irreversible actions (transfers, swaps, social posting). 2. **Provide a reference implementation as an official plugin**: - Start with something like the SINT proposal (#6707) as a community plugin track, but define a stable core hook so multiple policy plugins can exist. 3. **Add a “Safety Profiles” config preset**: - `safe_readonly`, `safe_social`, `safe_finance`, `unsafe_dev` with explicit warnings. **Comparable approaches** - GitHub Apps permissions model (scoped capabilities). - Home Assistant’s permission + approval patterns for risky operations. --- ### D) Connector/integration reliability (Discord parity, Anthropic payload changes, TOON params) **Opportunities (high impact, medium effort)** 1. **Establish connector conformance tests**: - A minimal suite verifying: typing indicator support, reactions, slash commands, streaming behavior, required action params, multi-party routing. 2. **Create a “Model/provider compatibility matrix”**: - E.g., Anthropic Opus 4.x parameter naming, event payload versions, known breaking changes. 3. **Versioned “encapsulation contracts”** (TOON/XML): - Document schemas and ensure connectors validate outputs; surface actionable errors when params are missing. **Comparable approaches** - OpenTelemetry maintains semantic conventions + conformance tests across SDKs. --- ### E) Community coordination + moderation load **Opportunities (medium impact, low effort)** 1. **Add a lightweight ticket/queue workflow for promotional pushes**: - Use GitHub Discussions, Linear-like board, or a Discord forum channel with templates (“goal / owner / timeline / success criteria”). 2. **Anti-scam operations**: - Publish a short “official links” / “how to verify staff” pinned message. - Add a “report scam” workflow and a public mod-log summary cadence. 3. **Separate price chat from dev/support** (if not already): - Channel hygiene so product support doesn’t get buried. **Comparable approaches** - Many OSS Discords use “Forums + tags” (Help / Feature request / Proposal) to reduce repeated questions. --- ## 4) Communication Gaps (expectations vs reality) 1. **elizabao_ai hype vs current usability** - Expectation: users can “use it now.” - Reality: “in development,” no clear user-facing entry point communicated. - Fix: explicit status messaging + “what you can do today.” 2. **Chain identity confusion** - Recurring misconception: “moving from Solana to ETH.” - Fix: a canonical “Multichain stance” doc snippet; add it to onboarding and FAQs. 3. **Safety expectations** - Users assume the framework prevents unsafe ops by default. - Reality: safety layer is emerging (AgentID/capabilities discussions) and not fully productized. - Fix: document “current safety guarantees” vs “recommended safety architecture” with templates. 4. **Release naming/versioning ambiguity** - “Eliza v3 (version 2.x)” is confusing framing. - Fix: publish a versioning policy (v3 branding vs semver). Recurring questions indicating onboarding gaps (from Discord): - “Where can I find v3 code?” → point to develop branch + exact path. - “When release?” → publish release criteria checklist + status. - “What is Hatcher.host?” → clarify whether it’s official/partner/community and what support level exists. --- ## 5) Community Engagement Insights ### Power users & what they need - **odilitime (core dev/community ops)**: driving major runtime/agent workspace changes; needs tighter feedback loops and issue triage structure to avoid Discord questions becoming invisible. - **jgonly1_89829**: actively deploying and promoting Hatcher.host; good candidate for creating an “official community tutorial” on hosted deployment. - **baogerbao / satsbased**: community amplification; could help with FAQs and expectation-setting posts. ### Newcomer friction signals - “What is this project / what can I do now?” (elizabao_ai specifically). - “Is it moving chains?” confusion. - “Is there a ticket system?” indicates newcomers don’t know where to operationalize ideas. ### Converting passive users into contributors - Create “good first docs issues”: elizabao_ai page, multichain FAQ, deployment decision tree. - Offer a “deployment walkthrough bounty” (non-monetary: roles, shoutouts) for Hatcher.host + local harness comparisons. - Add “Plugin proposal checklist” (security, persistence, tests, compatibility) to help plugin authors succeed (relevant given plugin-mnemopay review flags). --- ## 6) Feedback Collection Improvements ### Effectiveness of current channels - **Discord** captures early confusion and hype, but many questions go **unanswered or partially answered** (e.g., elizabao_ai on 4/9 initially had no direct technical answer in that thread). - **GitHub issues/PR reviews** contain the most actionable technical detail (e.g., #6704 root cause analysis is excellent), but may miss non-dev users. ### Improvements for more structured feedback 1. **Weekly “Top Questions” digest pinned to Discord + mirrored to GitHub Discussions**, with canonical answers and links. 2. **Add issue templates** for: - “Install/CLI failure” (capture OS, bun/node, package manager, logs). - “Connector bug” (platform, encapsulation mode, streaming on/off, reproduction). 3. **Partner/community hosting feedback form** (Hatcher.host, elizacloud): collect deployment success rate, time-to-first-agent, most common blockers. ### Underrepresented segments - **Non-crypto builders**: current visible feedback is heavily crypto/economic-agent oriented; we have little data from users building non-financial agents. - **Telegram users**: only minor UI refinement noted; missing broader usability feedback. - **Windows users** appear mostly via repo maintenance (openrouter artifacts); need more direct onboarding telemetry/feedback from Windows newcomers. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Publish “elizabao_ai: What it is / What you can do today”** (single page + pinned Discord FAQ) to stop repeated confusion and align hype with reality. 2) **Harden onboarding failure UX**: make `elizaos create` non-destructive on failure + add a troubleshooting section for bun/macOS (#6704) and workspace/submodule pitfalls. 3) **Define and ship a minimal “tool-call authorization gate” interface** (even as experimental), plus a “safe defaults” preset for finance/social actions—addressing the highest-severity safety concern. 4) **Create connector conformance tests + a Discord parity checklist** to reduce repeated integration regressions (params in TOON, async loop spam, typing/reactions/streaming). 5) **Introduce a lightweight coordination system for initiatives/promos** (Discord forum templates or GitHub Discussions board) to reduce “talk without follow-through” sentiment and capture actionable owner/next steps.