## User Feedback Analysis — 2026-04-09 (based on 2026-04-07 to 2026-04-08 community + early-Apr GitHub signals) ### Data Notes (for quantification) - **Discord (Apr 7–8):** 6 distinct user questions/requests captured in summaries (multichain confusion, elizabao_ai status, ticket system, agent safety, v3 stack, “looking for dev”). - **GitHub (Apr 1–8 snapshot):** 5 prominent new issues/proposals in `elizaos/eliza` (incl. 1 critical install failure + 4 plugin/economy/security proposals) and 3 notable open PRs discussed in the snapshot (developer harness, toon/action param fix, mnemopay plugin) with automated review feedback. --- ## 1) Pain Point Categorization (Top recurring friction areas) ### 1) Technical Functionality — **Agent safety / authorization is unclear and likely insufficient** **Frequency / severity:** High severity; surfaced directly in Discord and repeatedly via GitHub proposals. - Discord: **“how do you currently prevent your agent from doing something unsafe?”** (4oko4ow) remained effectively unanswered (current approach described as “good feeling for it”). - GitHub: proposals explicitly target authorization gaps (e.g., **capability token enforcement** in issue #6707; broader “AgentID / trust” work noted in weekly summary). **Users impacted:** Builders deploying agents with tool access (wallets, swaps, posting, terminal actions). --- ### 2) Documentation — **Versioning/roadmap and technical stack details are confusing** **Frequency / severity:** High frequency; medium-to-high severity (blocks evaluation and adoption). - Discord confusion around **“Eliza v3 (version 2.x)”** and where it lives (**develop branch**) + missing details (stack question from scottnuttall_ went unanswered). - Documentation gap indicated by repeated “where is it / what is it / what can I do now?” style questions. **Quantified signal:** ~**33% (2 of 6)** Discord questions were directly about **v3 status/stack/code location**. --- ### 3) Integration / Product Clarity — **Multichain positioning is not landing; users assume chain exclusivity** **Frequency / severity:** Medium frequency; medium severity (trust + narrative + integration expectations). - Discord: confusion framed as “moving from Solana to ETH”; corrected by community (“multichain”). **Quantified signal:** ~**17% (1 of 6)** Discord questions were chain-positioning confusion, but it’s a *high-impact misconception* (affects partners, builders, token community). --- ### 4) UX/UI + Documentation — **Onboarding to projects (elizabao_ai / ElizaCloud) lacks “what works today”** **Frequency / severity:** Medium frequency; medium severity (creates dead-end evaluation). - Discord: “**What exactly is elizabao_ai… what can I do there at this moment?**” Answer: still in development, future integration with ElizaCloud + prediction market agents. - This indicates a missing public “current state” page and feature availability matrix. --- ### 5) Technical Functionality — **CLI installation / environment reliability (Bun/macOS) can hard-fail** **Frequency / severity:** Lower frequency in this day’s Discord, but **very high severity** on GitHub. - GitHub issue **#6704**: `elizaos create` fails on macOS with Bun dependency/postinstall behavior; CLI cleans up the project directory leaving nothing behind. **Why it matters:** This is first-run experience; failures here churn new developers immediately. --- ### 6) Community / Process — **No structured workflow for requests (promo “tickets”, partner outreach, support triage)** **Frequency / severity:** Medium frequency; medium severity (creates chaos + lost opportunities). - Discord: explicit ask for a **ticket system** for promo coordination; answer: none exists. - Partner outreach appeared in dev channels (e.g., exchange listing inquiry) without clear routing. **Quantified signal:** ~**17% (1 of 6)** Discord questions requested process tooling; plus indirect evidence via partner outreach. --- ### 7) Community — **Signal-to-noise issues (token price talk, scammer flags) dilute developer support** **Frequency / severity:** High frequency in discussion channel; medium severity (attention tax). - Apr 7 Discord: extended ELISA token price discussion; scammers flagged repeatedly. --- ## 2) Usage Pattern Analysis (actual vs intended usage) ### Observed “actual usage” 1. **Agents as crypto operators**: swapping across chains, token safety, prediction markets, and economic reputation/memory. - Evidence: MangoSwap cross-chain plugin PR in registry; SafeAgent token safety proposal (#6706); MAXIA marketplace plugin proposal (#6700); prediction market agent plans for elizabao_ai; mnemopay “economic memory” PR (#6701). 2. **Agents embedded in social/community connectors** (Discord connectors, Milady integration). - Evidence: v3 agents integrated into Milady; PR #6709 fixes TOON action params and async continuation spam specifically observed in Discord connector testing. 3. **One-click hosting/deployment is a key adoption path**. - Evidence: successful Hatcher.host one-click deployment with Groq integration and live logs; reported “smooth”. ### Gaps vs intended usage - Intended: open-source agent framework with plugins. - Actual: a large share of energy is concentrated on **financialized agent operations** (wallets, swaps, marketplaces, trust/identity), which raises the bar for **safety guarantees**, **auditability**, and **clear risk communication** beyond typical “agent app” frameworks. ### Emerging / unexpected use cases - **“Trust bootstrapping” between independent agents** (cold-start trust problem) with attestations and credentials (WTRMRK, on-chain creds, append-only attestation sequences). - **Economic memory/reputation** as a first-class capability (mnemopay PR). ### Feature requests aligned with usage - Capability-based authorization and human approval tiers (issue #6707) strongly matches the “agents doing irreversible actions” reality. - Multi-chain token safety checks (issue #6706) matches increased trading/swapping usage. - Marketplace plugin (issue #6700) matches “agents as economic actors” direction. --- ## 3) Implementation Opportunities (concrete solutions per major pain point) ### Pain Point A: Agent safety / authorization (Technical Functionality) **Opportunity 1 (High impact / Medium difficulty): Ship a “Safety Baseline” policy layer in core** - Add a default **capability/permission manifest** per agent (allowlist tools + scopes + rate limits). - Require explicit opt-in for high-risk actions (wallet send/swap, terminal exec, social posting). - Similar approaches: - **LangChain** tool allowlisting + structured tool calling contracts - **OpenAI Agents/Tooling** patterns: strict tool schemas + explicit tool enablement - **Kubernetes RBAC** as conceptual model for scoped permissions **Opportunity 2 (High impact / Medium-to-high difficulty): Human-in-the-loop approvals for irreversible actions** - Implement approval hooks: “T0 observe / T1 reason / T2 act / T3 commit” (mirrors the tiering proposed in #6707). - Provide a reference UI flow (CLI prompt approval + webhook approvals for hosted deployments). **Opportunity 3 (Medium impact / Low-to-medium difficulty): Document and enforce “unsafe action” guardrails** - Publish an “Unsafe operations” checklist: shell, file writes, signing tx, posting. - Add a `GuardrailsService` cookbook + sample policies (deny by default, approve by regex/scope). --- ### Pain Point B: Versioning/stack ambiguity for v3 (Documentation) **Opportunity 1 (High impact / Low difficulty): Create a single canonical “Version Map” page** - Clarify: v3 naming vs “2.x”, branch locations, release criteria, upgrade notes. - Include: “what’s stable”, “what’s in develop”, and compatibility matrix (connectors, Milady integration). **Opportunity 2 (Medium impact / Low difficulty): Publish a “v3 agent stack” reference** - Answer: runtime composition, model providers, connectors, memory/db, plugin expectations. - Ensure scottnuttall_-style “what’s the stack?” questions have a linkable answer. **Opportunity 3 (Medium impact / Medium difficulty): Add a “release candidate” tag + changelog automation** - Adopt RC tagging on `develop` snapshots; publish short “what changed” notes weekly. - Similar approach: **Rust nightly/beta/stable channels** conceptually; or Next.js canary releases. --- ### Pain Point C: Multichain confusion (Integration / Product clarity) **Opportunity 1 (High impact / Low difficulty): Update README + Discord pinned FAQ** - Add a pinned “Multichain: what’s supported today?” section (Solana, EVM, Base L2, etc.). - Include plugin examples: wallet plugin + cross-chain swaps plugin work. **Opportunity 2 (Medium impact / Medium difficulty): Provide “chain adapters” documentation** - A page explaining how plugins interact with chains, signing, RPC, safety, and testing. --- ### Pain Point D: “What can I do today?” for elizabao_ai / ElizaCloud (UX/Docs) **Opportunity 1 (High impact / Low difficulty): Add “Project Status Cards”** - For each subproject (elizabao_ai, ElizaCloud, Milady integration): - Current functionality (today) - What’s in progress - What’s blocked - Where to test / join waitlist **Opportunity 2 (Medium impact / Medium difficulty): Public staging/demo environments** - Even a limited “read-only demo” reduces repetitive questions and increases contributor pull. --- ### Pain Point E: CLI install failures & environment drift (Technical Functionality) **Opportunity 1 (High impact / Medium difficulty): Fix Bun dependency model in CLI** - Align with #6704: remove `bun` runtime dependency; use `@types/bun` devDependency only. - Add preflight checks: detect Bun + macOS arch + known failure modes; print actionable steps. **Opportunity 2 (High impact / Medium difficulty): CI matrix for “create + build + run”** - Run smoke tests on macOS (Intel + Apple Silicon), Windows, Linux. - Similar approach: **create-next-app** CI smoke tests; **Vite** template verification. **Opportunity 3 (Medium impact / Low difficulty): Don’t delete generated project on failure** - Preserve directory and write a `FAILED_SETUP.md` with logs and next steps. --- ### Pain Point F: Lack of structured community workflow (Community/Process) **Opportunity 1 (High impact / Low difficulty): Introduce Discord “Forum” channels + tags** - Add forums: `#support`, `#plugin-reviews`, `#promo-coordination`, `#partner-requests`. - Require tags: bug / proposal / needs-triage / security. **Opportunity 2 (Medium impact / Medium difficulty): Lightweight ticketing via GitHub Discussions** - Route “promo pushes” and partner requests to Discussions templates, then link back to Discord. **Opportunity 3 (Medium impact / Medium difficulty): Auto-triage bot** - Use a bot to suggest: “this sounds like install issue → open GitHub issue with template”. --- ## 4) Communication Gaps (expectations vs reality) 1. **Safety expectations vs reality** - Expectation: “there is a defined mechanism preventing unsafe actions.” - Reality (as communicated): mostly implicit/manual judgment today. - Fix: publish explicit security model status (“what exists”, “what’s planned”, “what’s not guaranteed”). 2. **Chain exclusivity misconception** - Expectation: project “moved from Solana to ETH”. - Reality: multichain; the messaging isn’t consistently reaching users. - Fix: consistent multichain messaging in README, website, and Discord pins. 3. **Subproject readiness ambiguity (elizabao_ai)** - Expectation: users can “do something now”. - Reality: in development; plans stated but current capabilities unclear. - Fix: status cards + demo links. 4. **“v3” naming confusion** - Expectation: v3 means major stable release. - Reality: described as “v3 (2.x)” in testing on develop branch. - Fix: rename internally (or document clearly) and provide upgrade guidance. 5. **Recurring onboarding questions indicate missing quick links** - “Where is v3 code?” (develop branch) - “What’s the stack?” (no linkable answer) - “Do we have a ticket system?” (no, and no alternative suggested) --- ## 5) Community Engagement Insights ### Power users / core contributors (and likely needs) - **odilitime**: core dev + comms; needs scalable ways to answer repeated questions (docs, pinned answers) and reduce support load. - **baogerbao**: frequent helper; needs clearer official project status info to avoid repeating “still in development”. - **dankvr**: data pipeline improvements (fallback models, credit monitoring); needs shared observability patterns and budget/credit best practices docs. - **NubsCarson**: contributor fixing connector/runtime issues (TOON params, async continuation spam); needs connector test harnesses and clearer schema contracts. ### Newcomer friction patterns - Questions are primarily “orientation” not “deep usage”: multichain, what is elizabao_ai, where is v3, ticketing, stack. - A newcomer also asked generally: **“Is there anyone looking for a skilled developer?”** (kevin111s) — suggests unclear contributor entry points. ### Converting passive users to contributors - Maintain a curated **“Good first issues” + “Help wanted: plugins/docs”** board and link it in Discord onboarding. - Add a “Pick a lane” contributor guide: core, plugins, connectors, docs, security. - Offer a monthly “plugin review day” where maintainers provide fast feedback loops on proposals (MAXIA, SafeAgent, SINT, etc.). --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord:** fast, but unstructured; key questions go unanswered (agent safety, stack) or get answered once then lost. - **GitHub issues:** better structure, but proposals vary widely in quality/fit; no single intake funnel for “should this be a plugin vs core feature?” ### Improvements 1. **Standardize GitHub issue templates** (Bug / Proposal / Security / Docs) - Require: environment, repro, expected vs actual, impact. 2. **Add a “Weekly top questions” digest pinned in Discord** - Convert repeated Qs into docs updates (multichain, v3 status, safety model). 3. **Collect structured onboarding feedback** - Add a short “first-run survey” link in `elizaos create` output (“Did this work? OS? where stuck?”). ### Underrepresented segments (missing feedback) - **Non-crypto agent builders** (enterprise workflows, internal tools) — current discourse skew suggests their voice is not prominent. - **Windows + macOS onboarding**: we see macOS Bun failure (#6704) and Windows git friction in plugin-openrouter notes; need systematic collection across OSes. - **Hosted deployment users** beyond the single Hatcher.host success story: unclear how common that path is, and what fails there. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Define and ship a minimal “Agent Safety Baseline” (permissions + approval hooks)** - Start with allowlists + “commit requires approval” for wallet/terminal/social actions. 2. **Fix first-run developer onboarding reliability** - Address Bun/macOS CLI failure (#6704) + add CI smoke tests for `elizaos create → build → run`. 3. **Publish canonical docs for: (a) multichain positioning, (b) v3/v2.x version map, (c) v3 stack** - Turn recurring Discord questions into linkable answers; pin in Discord. 4. **Introduce lightweight community workflow (support + promo + partner routing)** - Discord forum channels + tags; route partner/promo requests to a single tracked place. 5. **Add “Project Status Cards” for elizabao_ai / ElizaCloud / Milady integration** - Reduce “what can I do today?” churn and increase targeted contributions.