## User Feedback Analysis — 2026-01-10 (covering community activity through 2026-01-09)

### Data sources referenced
- Discord: `#💬-discussion`, `#💬-coders`, `#core-devs` (2026-01-07 to 2026-01-09)
- GitHub summaries (week Jan 4–10, month Jan 2026): issues/PR notes referenced in aggregated summaries

---

## 1) Pain Point Categorization (top recurring friction areas)

> Quantification note: Discord data this interval includes a small number of explicit user questions/issues. Percentages below are computed from *distinct end-user problem reports/questions captured in the digest* (n≈10), not total messages.

### A. Technical Functionality (highest severity)
1) **Discord plugin/core compatibility regressions (v1.7.0 + plugin-discord 1.3.3)**
- Symptoms: `"No server ID found 10"`; bot can’t recognize server IDs despite admin perms; migration `serverId -> messageServerId` causing breakage.
- Evidence: DigitalDiva’s Discord bot failure; Odilitime’s diagnosis; PR #6333 and follow-up branch testing discussions.
- Frequency: ~20% (2/10 distinct issues/questions), severity high (blocks core “Discord bot” use case).

2) **ElizaCloud “App Creator” intermittent “operation failed”**
- Symptoms: one user consistently sees failures while others report it works, described as “early-stage.”
- Evidence: ElizaBAO report + cjft response.
- Frequency: ~10% (1/10), severity medium-high (blocks hosted onboarding).

3) **Cloud/API integration “Model not found” due to model naming format**
- Symptoms: users integrating agents into websites hit “Model not found” until using provider-prefixed model IDs (e.g., `openai/gpt-4o-mini`).
- Evidence: ElizaBAO question answered by cjft (Jan 7).
- Frequency: ~10% (1/10), severity medium (integration blocked; easy fix once known).

---

### B. Documentation (high frequency, medium severity)
4) **Missing “how-to” docs for common integrations**
- Unanswered questions indicating doc gaps:
  - Discord agent timer/interval settings (DigitalDiva; unanswered).
  - Whether Twitter/X API is required + cost constraints (Psyxh and earlier Discostu; unanswered/recurring).
  - Token migration edge cases (“max amount reached”, exchange auto-migration) and eligibility (“0 eligible tokens”).
- Evidence: multiple unanswered questions across Jan 8–9; explicit doc action items in digests.
- Frequency: ~40% (4/10), severity medium (creates churn + repeated support load).

5) **Docs availability/discoverability issues**
- Example: `elizacloud.ai/docs` reported down (Amir, Jan 8); users relying on scattered links (HackMD book shared in core-devs).
- Frequency: ~10% (1/10), severity medium.

---

### C. Community / Expectation Management (high severity in crypto-facing flows)
6) **Token migration + exchange delisting confusion and trust risk**
- Issues:
  - Eligibility verification failing (LP tokens: “max amount reached”; pre-Nov holders seeing 0 eligible).
  - Conflicting peer answers about exchange auto-migration (Bithumb/Coinone).
  - Confirmed Korean exchange delisting with DAXA citing “lack of transparency.”
- Evidence: Jan 8 thread; multiple users; scammer attempts noted (GUIDE BASE, guidebt).
- Frequency: ~30% (3/10), severity very high (financial impact + reputation).

7) **Token utility roadmap unclear**
- Users explicitly challenge why token exists if not used for payments/gas; no definitive team answer in-thread.
- Evidence: stoikol’s question (Jan 8) left unresolved.
- Frequency: ~10% (1/10), severity high (strategic narrative gap).

---

### D. UX/UI (emerging from GitHub issues; medium severity)
8) **Dashboard usability gaps (status visibility, login redirect, trait inputs)**
- Evidence: new UI/UX issues noted in daily GitHub summary (refine personality trait inputs; show agent statuses; clickable signup prompts; redirect to previous chats after login).
- Frequency: not quantifiable from Discord, but flagged in repo activity; severity medium (retention/onboarding).

---

## 2) Usage Pattern Analysis (actual vs intended usage)

### How users are actually using elizaOS
- **“Agent as an integration surface,” not just a local framework**
  - Website embedding via agent IDs + API endpoints (ElizaBAO) → indicates strong demand for turnkey web integration patterns.
- **Discord as a primary runtime target**
  - Multiple troubleshooting threads and release urgency show Discord is a “front door” for adoption.
- **Hosted-first onboarding expectations**
  - App Creator failures are treated as blocker-level; users expect SaaS reliability even if labeled early.
- **Workflow orchestration with multi-step “skills”**
  - Agent Joshua’s pipeline (intake → PDF fill → filesystem store/summarize → PDF display) shows real demand for deterministic, chainable tool/skill execution.

### Emerging / unexpected use cases
- **“Phone app” + passive sensing for mental health monitoring**
  - DorianD proposing Dopa One integration (dopamine/ADHD/depression/anxiety similarity scoring via phone + wearables) signals interest in health-adjacent agents and data collection.
- **Computer vision classification agents**
  - DeepFace suggested as starting point; interest in image-based classification inside agent workflows.
- **Interoperability with other agent tools**
  - Jin + R0am pushing “plugin → skill” conversion for cross-tool compatibility suggests users see elizaOS as part of a broader agent ecosystem, not a closed platform.

### Feature requests aligned with actual usage
- **Standardized “skills” format + implicit tool invocation**
  - R0am’s “hooks” to get Claude to use skills implicitly maps directly to workflow pain.
- **Better orchestration primitives**
  - Users want robust chaining, call-backs, and subagent linking patterns (referencing ClaudeCode subreddit implementation).
- **Cloud onboarding stability + clearer billing/credits UX**
  - Billing top-up page surfaced; users are actively managing credits, implying need for clearer quotas, limits, and error handling.

---

## 3) Implementation Opportunities (solutions per major pain point)

### Pain Point 1: Discord plugin/core regressions (`serverId -> messageServerId`)
**Impact:** Very high | **Difficulty:** Medium  
1) **Introduce a compatibility shim + runtime warning**
   - Maintain both fields in emitted context for ≥2 minor versions; log a single deprecation warning with a link to migration docs.
2) **Add a “Discord Integration Health Check” command**
   - `/eliza diagnose` returns: detected versions, intents/permissions checklist, resolved server/messageServerId, and a recommended fix path (downgrade/upgrade).
3) **Pin-and-test matrix releases**
   - Publish a tested matrix (core x plugin-discord) and enforce via CI (similar to how Kubernetes/Helm charts publish compatibility tables; also common in Terraform provider version constraints).

**Comparable approaches:**  
- Home Assistant + integrations: compatibility notes and built-in diagnostics.  
- Discord.js ecosystem: explicit intents/permission checklists + version pin guidance.

---

### Pain Point 2: Cloud App Creator “operation failed” with unclear cause
**Impact:** High | **Difficulty:** Medium  
1) **Return structured error codes + user-actionable messages**
   - Replace generic “operation failed” with codes like `BILLING_NO_CREDITS`, `TEMPLATE_BUILD_TIMEOUT`, `REGISTRY_FETCH_FAILED`, and include “Try again” vs “Contact support” guidance.
2) **Add per-user “App Creator logs” panel**
   - Expose last 50 events (template pull, build, deploy, runtime init) and a “Copy diagnostic bundle” button.
3) **Status page + incident breadcrumbs**
   - Even for early features, show component status (creator, billing, deploy) and recent incidents (Stripe-style status comms pattern).

**Comparable approaches:**  
- Vercel/Netlify build logs as first-class UX; Stripe status + incident timeline.

---

### Pain Point 3: “Model not found” due to provider-prefixed model ID requirement
**Impact:** Medium | **Difficulty:** Low  
1) **Accept unprefixed model names with server-side mapping**
   - If `gpt-4o-mini` is supplied, infer provider from agent config or default provider; warn if ambiguous.
2) **Improve API error response**
   - On “Model not found,” return: valid examples + detected provider list + link to “Model naming” doc.
3) **Add a model-picker UI in Cloud / dashboard**
   - Prevent invalid strings; store canonical `provider/model` form.

**Comparable approaches:**  
- OpenAI/Anthropic SDKs provide validation + clear examples; many platforms implement dropdown-based model selection to avoid string errors.

---

### Pain Point 4: Missing docs for Discord timers, Twitter/X API requirements, and common setup questions
**Impact:** High (support load + churn) | **Difficulty:** Low–Medium  
1) **Create “Integration Quickstarts” with copy-paste configs**
   - Discord: timers/interval settings, intents, permissions, common pitfalls.  
   - Twitter/X: what’s possible without paid API, what requires paid tiers, OAuth flows (note plugin-twitter now has OAuth2 PKCE work).
2) **Convert top unanswered Discord questions into a “FAQ triage” pipeline**
   - Weekly: top 10 unanswered Qs → GitHub docs issues → assign “docs bounty.”
3) **Add “Last updated / version” badges**
   - Each doc page indicates tested core/plugin versions (reduces outdated guidance).

**Comparable approaches:**  
- LangChain/LlamaIndex: “cookbooks” + versioned docs; Supabase: opinionated quickstarts per integration.

---

### Pain Point 5: Token migration/exchange delisting confusion + scam risk
**Impact:** Very high | **Difficulty:** Medium–High (cross-functional)  
1) **Single canonical “Token Migration Portal” + signed announcements**
   - One URL, one process, signed by official keys; include eligibility checker explanations and edge-case handling (LP tokens, “max amount reached”).
2) **Exchange-holder policy statement (Bithumb/Coinone/Korbit)**
   - A definitive “What happens if you held on exchange at snapshot?” page; remove conflicting peer answers.
3) **Anti-scam hardening**
   - Automated Discord bot that detects common scam phrases/DM patterns, posts warnings, and auto-links to the canonical portal.

**Comparable approaches:**  
- ENS claim + Arbitrum airdrop: canonical claim site + extensive FAQ + scam warnings; many projects pin signed messages and rotate them across official accounts.

---

### Pain Point 6: Token utility roadmap unclear
**Impact:** High | **Difficulty:** Medium  
1) **Publish a “Token Utility: Now / Next / Later” one-pager**
   - Explicitly state current utility (if any), near-term integrations (e.g., cloud credits, marketplace fees), and what is *not planned*.
2) **Tie utility to concrete product surfaces**
   - Example: Bazaar/agent marketplace fees, staking for reputation, discounts for Cloud credits—only if aligned with product goals.
3) **Host an AMA with written follow-up**
   - Capture Q&A into docs; reduces repeated debate and speculation.

**Comparable approaches:**  
- Gitcoin + Optimism: phased utility messaging tied to governance/product milestones.

---

## 4) Communication Gaps (expectations vs reality)

1) **ElizaCloud maturity**
- Expectation: “App Creator should just work.”
- Reality: early-stage; intermittent failures; limited diagnostics.
- Fix: label feature maturity in-product (Alpha/Beta), plus show logs/error codes.

2) **Twitter/X agent feasibility**
- Expectation: “Can I run a Twitter agent without paying $200/month?”
- Reality: depends on endpoints and tier; plugin changes (OAuth2 PKCE) suggest active dev, but users lack a definitive requirements matrix.
- Fix: publish a capability-by-tier table + alternatives (e.g., read-only via scraping is usually not acceptable—state this clearly).

3) **Skills/workflow orchestration**
- Expectation: LLM should “implicitly” use skills; chaining should be straightforward.
- Reality: requires conventions (determinism, hooks, orchestration patterns).
- Fix: publish “Skills spec v0” and recommended orchestration patterns (sequential, DAG, subagents).

4) **Breaking changes/migrations**
- Expectation: minor version upgrades won’t break integrations.
- Reality: `serverId -> messageServerId` created real breakage in Discord path.
- Fix: stronger migration notes, compatibility shims, and pinned version guidance.

---

## 5) Community Engagement Insights

### Power users & what they need
- **Odilitime**: needs fast release pipelines + compatibility testing infrastructure (they’re doing deep triage, branches, PRs).
- **cjft**: frontline support for Cloud + API integration questions; needs better docs to reduce repetitive explanations.
- **Jin / R0am**: pushing interoperability + skills standards; needs a formal spec process and a reference implementation repo.
- **Stan / Shaw**: cloud reliability + major architectural redesign; needs structured feedback from real integrators to validate Eliza 2.0 direction.
- **DorianD**: ideation-heavy on phone app, data, mental health; needs a clear “experimental proposals” channel to separate product-ready from exploratory.

### Newcomer questions indicating onboarding friction
- Discord: timers/interval settings; permissions; server ID recognition.
- Cloud: app creator failures; billing/credits; “where is the docs?”
- API: model naming format.
- Token: migration eligibility + exchange procedures.

### Converting passive users into contributors
1) **“Answer-an-unanswered-question” program**
   - Weekly list of unanswered Discord questions; reward via leaderboard/merit points; convert answers into docs PRs.
2) **Skill conversion hackathons**
   - Take 2 plugins (Discord + one blockchain) → convert to “skills” folders → publish as reference templates.
3) **Good-first-issue mapping to real pain**
   - Tag issues like “Discord diagnose command,” “improve error codes,” “doc quickstart: Twitter requirements.”

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord is high-signal for immediate breakages** (Discord plugin regressions surfaced quickly), but **low structure**: important questions go unanswered and are hard to track.
- **GitHub captures engineering work**, but user-facing pain (Cloud errors, token confusion, integration requirements) often stays in chat and never becomes actionable issues.

### Improvements for more structured, actionable feedback
1) **Discord → GitHub intake bot**
   - Any message with keywords (“error”, “operation failed”, “model not found”, “migration”) prompts: “Create issue?” with a prefilled template.
2) **Standard “bug report bundle”**
   - For Cloud + plugins: versions, config, logs, reproduction steps, environment.
3) **In-product micro-surveys**
   - In ElizaCloud: after app creation failure, ask 2 questions (what were you trying to build? did retry work?) + auto-attach error code.

### Underrepresented segments / missing feedback
- **Non-Discord users** (silent churn) — add lightweight Cloud telemetry + email follow-up for failed onboarding.
- **Non-English/Korean exchange users** — delisting/migration impacts suggest a need for localized official comms.
- **Teams embedding agents into products** — only a small glimpse (website integration); actively recruit 5–10 design partners.

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1) **Ship Discord compatibility hardening**
- Compatibility shim for `serverId/messageServerId`, publish tested version matrix, and add `/eliza diagnose` command.

2) **Make ElizaCloud App Creator debuggable**
- Structured error codes + user-facing logs panel + status page component indicators.

3) **Publish two missing “money pages” of documentation**
- (a) Twitter/X agent requirements & pricing realities (what works on which tier)  
- (b) Discord setup guide including timers/interval settings and common failure modes

4) **Token migration clarity package**
- Canonical portal + definitive exchange-holder policy + aggressive anti-scam comms automation.

5) **Formalize “Skills spec v0” + reference repo**
- Define folder format, determinism rules, and recommended orchestration patterns (sequential + subagents), with at least one end-to-end workflow example (intake → PDF → filesystem → output).