## User Feedback Analysis — 2026-02-22 (covering feedback observed through 2026-02-19 to 2026-02-21) ### Data snapshot (what this report is based on) - **Discord (Feb 19–21):** recurring questions on versioning (v2.0.0), database setup (pglite vs Neon), token migration/contract confusion, ElizaCloud UI bugs, and unclear feature/pricing semantics. - **GitHub (month to date, Feb 1–Mar 1 window):** **41 new issues**, **35 PRs (18 merged)**, **34 contributors**. Notable open issues include: - **#6486** URL messages trigger **duplicate LLM calls** (cost + UX impact) - **#6490** need **custom OpenAI-compatible endpoint URL** - **Important context:** v2.0.0 is publicly recommended in Discord, but documentation is lagging behind that recommendation. --- ## 1) Pain Point Categorization (top recurring friction areas) > Frequency is inferred from repeated questions/topics across Discord days + the “top issues” surfaced in GitHub summaries. Severity is estimated by impact on ability to ship or cost/risk. ### 1. Documentation — **v2.0.0 is recommended, but “how to use it” is unclear** (High frequency, High severity) **Observed** - Users were told **“v2.0.0 branch is recommended”** while also being warned it has **less documentation** (BinaryCookies thread; reinforced by Odilitime). - This creates a classic “new default without a paved path.” **Who it affects most** - New builders trying to pick a stable base and follow guides. --- ### 2. Technical Functionality — **Database selection is environment-driven, but there’s no migration story** (Medium frequency, High severity) **Observed** - plugin-sql supports **pglite and Neon Postgres** via env vars, but **“won’t migrate data automatically”** (BinaryCookies Q&A). - Users want to combine local dev (pglite) with hosted (Neon) without losing state. **Who it affects most** - Builders moving from prototype → hosted deployments. --- ### 3. UX/UI — **ElizaCloud dashboard usability bugs (scroll + API explorer) + misleading test tool error** (Medium frequency, High severity) **Observed (from hands-on testing feedback by DorianD)** - Broken mousepad scrolling on API explorer and other pages; scrollbar hard to see. - “Send request” test returns **“api key is required”** even when a key appears present. - Questions about what **“use a different key”** does and whether it’s BYOK. **Who it affects most** - Users evaluating ElizaCloud and attempting first API calls. --- ### 4. Integration — **Provider/config flexibility gaps (custom OpenAI endpoint; BYOK semantics unclear)** (Medium frequency, Medium–High severity) **Observed** - GitHub **#6490** requests a configurable **OpenAI endpoint URL** to support OpenAI-compatible providers (e.g., SiliconFlow). - Discord questions about “use a different key” suggest users expect an **OpenRouter-like BYOK model routing** experience. **Who it affects most** - Teams standardizing on OpenAI-compatible APIs and wanting vendor optionality. --- ### 5. Technical Functionality / Reliability — **Unexpected language output / localization drift** (Low frequency, Medium severity) **Observed** - Report: an OpenClaw agent “unexpectedly started responding in Korean” (DorianD). Even if OpenClaw-specific, users will attribute this to the agent stack and configuration expectations. **Who it affects most** - Builders demoing agents publicly; risk of “it’s broken” perception. --- ### 6. Community / Communication — **Token migration + contract confusion + “what is deprecated” messaging** (High frequency, High severity) **Observed** - Repeated confusion between **$ai16z / $ai6z vs $elizaos**, contract addresses, migration deadlines, and “is token mintable?” concerns (Feb 19–21 threads). - Clear statement from Odilitime: **ai16z is effectively deprecated/dead coin**, migration **1:6** (and funding allocation **1:4** mentioned), liquidity split across chains—yet users keep asking, indicating discoverability gaps. **Who it affects most** - Newcomers entering via crypto/community angle rather than developer docs. --- ### 7. Community / Onboarding — **Fragmented support surfaces (public coders channel feels “quiet”; separate dev Discord is non-obvious)** (Medium frequency, Medium severity) **Observed** - NintyNine noted low activity; Bill Ding explained there’s a separate developer Discord. - This creates a “ghost town” effect in the most obvious help channel. **Who it affects most** - New developers seeking real-time help. --- ## 2) Usage Pattern Analysis (actual vs intended usage) ### What users are actually doing 1. **Building crypto-native agents first (trading/wallet/DeFi, multi-chain)** - “Spartan” positioned as **agentic wallet with trading capabilities**; DegenAI holders access open-source trader. - Plugin ecosystem proposals include **token swaps via x402 payments**, trust/discovery layers (MoltBridge), and multiple exchange/trading plugins (from monthly contributor summaries). 2. **Using ElizaOS as a plugin+connector platform** - Users evaluate ElizaOS vs OpenClaw by connectors/reliability (“not self-configuring,” “more connectors,” “better benchmarks”). 3. **Rapid experimentation / demo-driven adoption** - “Hanging plaza” is promoted as a live demo of agents in social spaces (learning via experience rather than docs). ### Mismatches vs intended/desired usage - Users are being directed to **v2.0.0** (future direction) while the **onboarding path remains optimized for older assumptions** (docs, examples, and operational guidance lag behind). - ElizaCloud is being evaluated as a “productized API platform,” but current UX bugs undermine first-run success. ### Emerging / unexpected use cases to watch - **“Trustless vs Trusted Agentic Intelligence (TAI)”** framing suggests a near-term need for: - sandboxing, policy boundaries, and verifiable execution/auditing - **Censorship-resistant gaming** mentioned as an opportunity: likely requires low-latency loops, deterministic-ish action execution, and robust planningMode controls. ### Feature requests that align with real usage - **BYOK + multi-provider endpoints** (OpenAI-compatible URL support; clear key-switching semantics) - **DB migration tooling** (pglite → Neon) - **ElizaCloud API explorer reliability + pricing transparency** (per-model prices visible) --- ## 3) Implementation Opportunities (solutions per major pain point) Below, each opportunity includes **2–3 implementable fixes**, prioritized by **impact vs difficulty**, plus examples from similar ecosystems. ### A) v2.0.0 “recommended but under-documented” **1) Ship a v2 “Golden Path” quickstart (High impact, Medium difficulty)** - Add one canonical path: *create agent → choose DB → run locally → deploy*. - Include exact env var sets for pglite vs Neon, and a minimal plugin example. - **Comparable approach:** Next.js “App Router” adoption—docs pivoted to a single recommended default with migration notes. **2) Versioned docs with a prominent selector + deprecation banner (High impact, Low–Medium difficulty)** - A docs toggle: **v1 (legacy)** / **v2 (recommended)** with clear warnings and links. - **Comparable approach:** Kubernetes versioned documentation and Terraform provider version pinning guidance. **3) Add “doctor” command in CLI for v2 projects (Medium impact, Medium difficulty)** - `elizaos doctor` checks runtime, plugin versions, env vars, DB connectivity, and suggests fixes. - **Comparable approach:** `flutter doctor`, `brew doctor`. --- ### B) Database choice without migration (pglite ↔ Neon) **1) Provide an official export/import utility (High impact, Medium difficulty)** - `elizaos db export` (pglite → SQL/JSON) and `elizaos db import` (to Neon/Postgres). - Include memory tables + indices guidance. - **Comparable approach:** Prisma migrate + `pg_dump`-style workflows wrapped in DX-friendly commands. **2) Add an opt-in “dual-write then cutover” mode (Medium impact, Higher difficulty)** - For a limited set of tables (messages/memory), write to both stores temporarily to validate. - **Comparable approach:** Stripe / large SaaS migration playbooks; LaunchDarkly-style progressive cutovers. **3) Document a “dev/prod DB pattern” explicitly (Medium impact, Low difficulty)** - A short guide: pglite for local, Neon for prod, with a checklist for switching safely. --- ### C) ElizaCloud dashboard UX bugs + API explorer failing **1) Fix scrolling + scrollbar visibility regressions (High impact, Low difficulty)** - Treat as P0 because it blocks basic navigation/testing. - Add automated UI smoke tests for scroll containers. **2) Make API explorer “Send request” validate auth state client-side (High impact, Medium difficulty)** - If API key is present but backend rejects, show: - which key is used - where it was sourced from (session/env/selected key) - exact missing header or field - **Comparable approach:** Postman / Swagger UI show request headers and auth injection clearly. **3) Add an in-product “Report a bug” capture bundle (Medium impact, Medium difficulty)** - One click exports: page URL, browser, console errors, request ID, auth mode (redacted), and last API call details. --- ### D) BYOK + OpenAI-compatible endpoint flexibility **1) Implement `baseURL` / custom endpoint for OpenAI provider (High impact, Low–Medium difficulty)** - Directly addresses GitHub **#6490**. - Support env var + config file, and ensure it works across TS/Python/Rust in v2. **2) Clarify and standardize “use a different key” semantics (High impact, Low difficulty)** - Rename in UI to “Bring your own key (BYOK)” if that’s the intent. - Show supported providers and limitations. **3) Add “provider routing” presets (Medium impact, Medium difficulty)** - Presets like “OpenRouter-style” or “OpenAI-compatible” with clear required fields. **Comparable approach:** LangChain’s provider abstraction + LiteLLM’s unified proxy model routing. --- ### E) Unexpected language output (localization drift) **1) Add explicit language constraints + diagnostics in agent settings (Medium impact, Low difficulty)** - A `preferred_language` (or locale) setting displayed in config + runtime logs. **2) Add a “why did you answer in X?” trace (Medium impact, Medium difficulty)** - Capture whether the trigger was: - system prompt - user message language - memory contamination - model auto-detect **Comparable approach:** Rasa and other conversational stacks log NLU language detection and policy decisions. --- ### F) Migration + token/contract confusion (community-facing but high impact) **1) Publish a single canonical “Token & Migration” page linked everywhere (High impact, Low difficulty)** - Include: contract addresses, “ai16z status: deprecated,” migration ratio, deadlines, FAQs (mintability, chain validity). - Pin it in Discord + link in bot auto-replies. **2) Add a Discord “migration helper” bot command (Medium impact, Medium difficulty)** - `/contract`, `/migration`, `/deadline`, `/chains`, `/faq mintable` - Reduces repeated manual responses. **3) Clarify chain validity questions (e.g., “BNB and Solana both valid?”) (Medium impact, Low difficulty)** - A simple table by asset → chain → contract → status. **Comparable approach:** Arbitrum/Optimism ecosystems maintain canonical contract registries and pinned FAQs. --- ### G) Fragmented support surfaces (dev Discord vs public) **1) Add an onboarding message that routes people to the right place (High impact, Low difficulty)** - In `#coders`, auto-message: “For active dev help join X” + link + how to get access. **2) Weekly “office hours” in the public server (Medium impact, Low difficulty)** - Reduces the “quiet channel” perception and captures beginner questions live. **3) Create a single “Start Here (Builders)” hub channel (Medium impact, Medium difficulty)** - Curate: version choice, quickstart, DB choice, plugin registry, cloud status. --- ## 4) Communication Gaps (expectations vs reality) ### Recurring expectation mismatches - **“Recommended version” vs “documented version”** - Users hear “use v2.0.0” but then can’t find matching docs/examples. - **ElizaCloud as a polished product vs current beta UX** - Broken scrolling + API explorer auth errors make the platform feel unreliable, even if backend is fine. - **BYOK expectations** - The UI phrase “use a different key” leads users to assume OpenRouter-like BYOK routing and per-model billing transparency. - **Migration clarity** - Even after clear Discord explanations, repeated questions show the information is not discoverable enough (needs canonical docs + pinned posts + bot answers). ### Documentation/onboarding gaps indicated by repeated questions - “Which version is most stable?” - “How do I use pglite and Neon together?” - “Is there still a live Eliza agent that answers questions about the latest codebase?” (unanswered) - “Can we deploy dApps to Solana seeker?” (unanswered) - “BNB and Solana—are both valid?” (asked twice) ### Specific improvements to align expectations - Add a **public status page** or pinned “What’s live today” for: Babylon access, ElizaCloud readiness, known issues. - Publish a **compatibility matrix**: - v1 vs v2 features - supported DBs - supported providers + BYOK behavior - deployment targets --- ## 5) Community Engagement Insights ### Power users and their needs (and how to leverage them) - **Odilitime (engineering lead, high-touch support in Discord):** - Needs: fewer repeated FAQs; scalable support mechanisms (docs, bot commands). - Opportunity: convert answers into canonical docs automatically (see feedback collection section). - **King Nebuluz (Erlang “unbreakable agents” proposal; Polymarket agent):** - Needs: clear integration pathway (contribution guidelines, plugin/runtime interfaces, evaluation criteria). - Opportunity: formalize a “Core integrations incubator” for experimental runtimes (Erlang, etc.). - **DorianD (hands-on product tester; reports UI bugs and odd agent behavior):** - Needs: bug reporting pipeline that captures repro + environment automatically. - Opportunity: recruit as “beta QA captain” with a checklist and direct issue filing. - **BinaryCookies (new builder asking correct setup questions):** - Needs: quickstart + DB/migration guidance. - Opportunity: ensure the first 60 minutes experience is smooth; these users become repeat contributors if unblocked. ### Common newcomer questions indicating onboarding friction - Version selection, database setup, how to contact leadership, where updates are posted, contract addresses/migration. ### Converting passive users into contributors - Add “**good first issue**” labels tied to the exact pain points: - docs: v2 quickstart, BYOK explanation - cloud: scroll fix verification, API explorer auth UX - Provide a “**plugin submission kit**” (template + CI checks) since plugin ecosystem growth is strong. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - **Discord** captures real-time confusion and early UX bugs, but information is ephemeral and repeated. - **GitHub issues** capture actionable technical items (e.g., #6486, #6490) but miss context from Discord threads unless manually copied. - Fragmentation: dev discussion split across servers creates “quiet channel” misconceptions and lost questions. ### Improvements for more structured, actionable feedback 1. **Discord → GitHub bridge for tagged bug reports (High impact, Medium difficulty)** - A bot workflow: react with 🐛 → prompts for repro steps → creates GitHub issue draft. 2. **Standardized ElizaCloud bug template (High impact, Low difficulty)** - Required: browser, OS, page URL, expected/actual, screenshot, request ID. 3. **Monthly “Top friction” pulse survey for builders (Medium impact, Low difficulty)** - 5 questions: version used, biggest blocker, DB choice, provider choice, cloud vs self-hosted. ### Underrepresented segments (missing feedback) - **Non-crypto developers** using WhatsApp/Gmail/N8N-style automations (not showing up in Discord discussions sampled here). - **Enterprise/self-host operators** (deployment, observability, governance concerns). - **Frontend builders** beyond the single tester report—need broader validation of ElizaCloud UX issues. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1. **Publish a v2.0.0 “Golden Path” quickstart + versioned docs selector** (unblocks the highest-leverage onboarding confusion). 2. **Fix ElizaCloud API explorer blockers (scroll + “api key required” false negative) and add visible request/auth introspection** (restores trust in first-run product experience). 3. **Implement OpenAI provider custom `baseURL` (GitHub #6490) + explicitly document BYOK semantics in Cloud** (aligns with real usage: multi-provider routing). 4. **Ship a minimal pglite ↔ Postgres (Neon) export/import migration utility** (enables dev→prod transitions without data loss). 5. **Create canonical “Token & Migration” FAQ page + Discord bot commands (/contract, /migration)** (reduces repeated high-noise questions and support load).