## User Feedback Analysis — 2026-01-03 (based on data through 2026-01-02)

### 1) Pain Point Categorization (top recurring 5–7)

#### A. UX/UI
**Most frequent + highest leverage issues (5/5 of the “top issues” opened in `elizaos/eliza` on 2026-01-02 were UX/UI-oriented):**
- **Public agent experience conflates distinct user intents** (Issue #6313): unauthenticated visitors see controls that imply ownership (e.g., Private/Public toggle, Edit).
- **Weak/unclear chat summaries** (Issue #6311): summaries “don’t make much sense,” reducing scan-ability of chat history.
- **Public agent cards lack social proof / usage context** (Issue #6314): request to show “chat number” (total messages) on cards.
- **Need for a soft gate for unauthenticated users** (Issue #6312): limit to ~2–3 messages before prompting signup.
- **Free-credit expectations vs product economics** (Issue #6315): proposal to reduce free credits ($5 → $1), implying current model may attract “tourists” with high support cost.

**Who it affects:** New visitors arriving via shared public-agent links, and builders trying to evaluate public agents quickly.

---

#### B. Documentation
**Repeated confusion signals:**
- **Token migration instructions unclear/incomplete** (Discord `💬-discussion`): 3 of 5 FAQ questions (60%) were unanswered and all were about migration (“bought after snapshot?”, “deadline?”, “why migrated?”).
- **Wallet requirements & compatibility not obvious** (Discord): Tangem + Phantom/MetaMask confusion; requests for WalletConnect/Tangem support.
- **Plugin usage model unclear** (Discord `💬-coders`): “Can I use plugins that were not added to the cloud from the docs?” (unanswered).
- **Cloud/token integration explanation requested** (2026-01-01 action item: “documentation explaining token integration with cloud services”).

**Who it affects:** Newcomers + token holders; developers trying to extend via plugins.

---

#### C. Technical Functionality
**Concrete breakpoints users hit:**
- **Migration transfer reliability issues**: users report tokens not showing after transfer to Phantom; Phantom wallet connect issues on desktop were mentioned as an action item (2025-12-31 list, echoed by ongoing migration chatter).
- **Jeju OAuth3 testnet demo login doesn’t work** (2025-12-31 Q&A): “It doesn't work, but otherwise looks good” → undermines confidence in onboarding/auth flows.
- **Agent execution edge cases**: need for `singleShot` to support parameters to avoid “action problems” (core-devs); multi-step workflows need retry logic + parameter extraction (2026-01-02 community update).

**Who it affects:** Anyone attempting auth/demo flows; builders composing workflows/tools.

---

#### D. Integration
**High-interest integration requests (often unanswered):**
- **“Import an entire GitHub codebase as an agent”** (Discord `💬-coders`, unanswered) → suggests demand for repo-to-agent scaffolding.
- **Git tooling**: updates to `plugin-github` + creation of `plugin-git` underway, indicating real usage pressure.
- **Discord plugin compatibility questions** (2026-01-01 Q&A): points users to a commands channel rather than a stable compatibility matrix.
- **External/novel integrations**: device plugin demo mentioned; Farcaster post management/scheduling request; Ruby agent integration references.

**Who it affects:** Power users building agents for real systems (repos, social, devices).

---

#### E. Community / Support Experience
**Support load concentrated in a few themes:**
- Migration questions dominate general chat; many go unanswered or get redirected to channels/DMs.
- “Where is the FAQ channel?” type navigation questions persist (2025-12-31), indicating information architecture friction in Discord.

**Who it affects:** New users; moderators/support volunteers.

---

#### F. Performance / Reliability (meta)
- Daily Discord summary generation failed on 2026-01-02 due to an upstream API error (“Premature close” from OpenRouter fetch). While not end-user product UX, it degrades the project’s internal feedback/insight loop and community transparency.

---

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

#### How users are actually using elizaOS
- **Public-agent link sharing as top-of-funnel**: GitHub issues (#6312, #6313, #6314) strongly imply users arrive from Twitter/social links, expect a clean “try the agent” experience, and then decide whether to sign up/fork.
- **Agents as “software actors” inside games/worlds**: recurring interest in RuneScape/Zelda-like experiences with agents populating towns and generating quests (2026-01-01). This is beyond typical “chatbot” framing—closer to autonomous NPC systems + content pipelines.
- **Agents for financial autonomy narratives**: DegenAI discussion emphasizes autonomous trading; users compare project narratives and token utility frequently.
- **Agents as DevOps/infra copilots**: partners channel proposes “cost reduction and migration agent” for AWS offboarding (with a concrete repo reference).

#### Emerging / unexpected use cases
- **Repo ingestion → agent creation** (“import entire codebase as an agent”) suggests demand for an “agent that understands and operates a codebase,” not just chats about it.
- **Physical device plugins** (as referenced in Discord) point toward IoT/hardware control integrations, increasing safety/security needs.

#### Feature requests that align with real usage
- **Distinct public-agent states + soft gating** (Issues #6312, #6313): matches the social-link funnel reality.
- **Agent analytics/social proof** (Issue #6314 chat count): users want signals of credibility/activity before investing time.
- **Workflow robustness** (retry logic, parameter extraction, `singleShot` params): matches real-world tool use where actions fail without correct args.

---

### 3) Implementation Opportunities (2–3 per major pain point, prioritized)

#### Pain Point 1: Public agent UX conflates visitor vs owner vs authenticated user (UX/UI)
**High impact / medium effort**
1) **Implement explicit “Public Agent View States”** exactly as proposed in Issue #6313:
   - State 1 (Unauth): minimal profile + chat, hide owner controls, show share link, enforce message cap.
   - State 2 (Authed non-owner): show Chat + Fork, show creator attribution, no toggles/edit.
   - State 3 (Owner): full management UI with clear tabs.
2) **Add a dedicated “Try this agent” landing mode for shared links** (lightweight route or query param) to ensure consistent minimal UI for social traffic.

**Medium impact / low effort**
3) **Add UI affordances that clarify ownership** (“You’re chatting with a public agent you don’t own”) when authed non-owner.

**Comparable approaches**
- Hugging Face Spaces uses “view vs duplicate” patterns to separate usage from ownership.
- GitHub “view file” vs “edit” permission gating clarifies capability by role.

---

#### Pain Point 2: Unauthenticated usage needs a clear soft gate + economics alignment (UX/UI + Product)
**High impact / low–medium effort**
1) **Enforce 2–3 message limit for unauthenticated visitors** (Issue #6312) with a “continue by signing up” overlay that preserves chat context on signup.
2) **Instrument conversion + drop-off metrics**: track “messages before signup,” “signup after 1st response,” etc., to tune the cap.

**Medium impact / medium effort**
3) **Tiered free credits tied to verified actions** (email/phone/github) rather than blanket free credits (Issue #6315), reducing abuse while keeping onboarding friendly.

**Comparable approaches**
- Many developer tools (e.g., Vercel/Render) combine a generous initial try with a clear gate and saved state to reduce frustration.

---

#### Pain Point 3: Chat summaries are low quality and reduce navigability (UX/UI + Technical)
**High impact / medium effort**
1) **Switch from “single generated summary” to structured metadata**:
   - Title + 2–3 bullet “topics” + last active timestamp.
   - Generate title from first user intent + resolved outcome.
2) **Regenerate summaries on meaningful milestones** (e.g., every N turns or when conversation ends) instead of ad hoc snapshots.

**Medium impact / medium–high effort**
3) **User-editable chat titles + feedback control** (“Improve summary” button) to capture corrections and train heuristics.

**Comparable approaches**
- Notion AI and Slack-style thread summaries favor short topic bullets + recent context over verbose paragraphs.

---

#### Pain Point 4: Token migration confusion + wallet interoperability issues (Documentation + Technical Functionality)
**High impact / low effort**
1) **Publish a single “Migration FAQ” pinned in Discord + docs** addressing the recurring questions explicitly:
   - “Tokens bought after snapshot: what happens?”
   - “Migration deadline”
   - “Supported wallets (Phantom/MetaMask/Tangem), recommended path”
   - “Why migration happened (one-paragraph rationale)”
2) **Add a step-by-step troubleshooting flowchart** (tokens not showing, wrong network, pending indexing, etc.).

**High impact / medium effort**
3) **Improve wallet connectivity options**: WalletConnect support and/or explicit Tangem guidance (requested in Discord action items). If WalletConnect isn’t feasible immediately, provide a supported workaround with screenshots and warnings.

**Comparable approaches**
- Major bridges/migrations (e.g., L2 bridges) typically provide a canonical checklist + status page; they reduce support load dramatically by centralizing “known issues.”

---

#### Pain Point 5: Plugin and integration expectations mismatch (Integration + Documentation)
**High impact / medium effort**
1) **Create a “Plugin lifecycle & compatibility matrix”**:
   - “Cloud-supported” vs “self-host only”
   - Version compatibility with core
   - Minimal example configs
2) **Add a “Repo → Agent” starter path** (even if partial):
   - MVP: ingest README + file tree + selected folders; generate an agent profile and tool suggestions.
   - Clarify what is and isn’t possible today (since the Discord question was unanswered).

**Medium impact / medium effort**
3) **Ship reference integrations as templates** (Discord bot, GitHub bot, Farcaster scheduler) to match how users are trying to deploy agents.

**Comparable approaches**
- Backstage and Home Assistant succeed by pairing plugin ecosystems with a clear registry + compatibility labeling and starter templates.

---

#### Pain Point 6: Workflow robustness (multi-step retries, parameter extraction, `singleShot` params) (Technical Functionality)
**High impact / medium effort**
1) **Standardize tool invocation contracts**: strict parameter schemas + validation errors surfaced in UI.
2) **Built-in retry policy for multi-step workflows** with:
   - retryable vs non-retryable error classification
   - backoff strategy
3) **Add parameter support to `singleShot`** (explicit dev request) and include regression tests for “action problems.”

**Comparable approaches**
- Temporal / Airflow patterns: retries are first-class; errors are categorized; parameters are validated early.

---

### 4) Communication Gaps (expectations vs reality)

- **Public link expectations**: Users clicking a shared agent expect a simple “try it” interface, but current UI exposes controls that imply editing/ownership (Issue #6313). This creates confusion and reduces trust.
- **Migration expectations**: Repeated unanswered questions in general discussion indicate users expect migration to be “self-explanatory,” but current guidance is fragmented across channels/DMs.
- **Plugin availability expectations**: The question “Can I use plugins not added to the cloud?” signals unclear boundaries between “cloud product” and “open-source self-hosted” capabilities.

**Documentation/onboarding improvements**
- Add an explicit “Cloud vs Self-host” page with:
  - what cloud includes today
  - what requires self-hosting
  - how to decide
- Create a “Start Here” pathway for three personas:
  1) Visitor trying a public agent
  2) Builder forking an agent
  3) Developer integrating plugins/tools

---

### 5) Community Engagement Insights

#### Power users (and their needs)
- **borisudovicic** (GitHub): opened multiple UX issues (#6311–#6315), providing detailed state breakdowns and UI expectations → needs a tight feedback loop with maintainers, and likely can help validate UX changes quickly.
- **Core devs (e.g., Stan ⚡, Odilitime, Shaw)**: focusing on workflow reliability, plugin development (`plugin-github`, `plugin-git`), and larger product initiatives (Jeju backend). They need:
  - clearer bug reports (repro steps, environment)
  - prioritization support (which UX changes move activation metrics most)

#### Newcomer questions indicating onboarding friction
- “Where is the FAQ channel?”
- “Which is the main codebase to contribute to?”
- “Is there a Discord plugin that works with current version?”
- Migration basics (deadline, eligibility, wallets)

#### Converting passive users into contributors
- Create “Good First Issue” bundles around:
  - migration docs improvements
  - public agent UI state implementation
  - plugin compatibility docs
- Add a weekly “Contributor office hours” thread in Discord where unanswered questions are triaged into:
  - docs PR
  - GitHub issue
  - support FAQ entry

---

### 6) Feedback Collection Improvements

#### Current channel effectiveness
- **Discord**: high volume, low structure; many questions go unanswered or get redirected to DMs, which prevents reusable solutions.
- **GitHub issues**: high quality for product UX feedback (clear proposals, screenshots), but currently concentrated among a small number of reporters (top issues all from one user).

#### Improvements to gather structured, actionable feedback
1) **Add GitHub issue templates** for:
   - Public agent UX
   - Migration/wallet issues (include wallet, chain, tx hash, expected vs actual)
   - Plugin compatibility
2) **Add a Discord “Support Intake” bot/form** that converts common issues into a structured post (or GitHub issue) with required fields.
3) **Create a public “Known Issues / Status” page** (especially for migration + auth demo), reducing repeated questions.

#### Underrepresented segments
- **Non-crypto builders**: lots of token talk, but limited structured feedback from teams building non-Web3 agents (except the infra migration idea).
- **Cloud-first users**: confusion suggests there are users trying cloud features but not providing systematic feedback (likely because they drop off early).

---

## Prioritized High-Impact Actions (next 1–2 weeks)
1) **Ship the 3-state Public Agent UI (unauth / authed non-owner / owner)** + **2–3 message soft gate** (Issues #6312, #6313).  
2) **Publish and pin a canonical Token Migration FAQ + troubleshooting guide**, answering the recurring unanswered questions (deadline, post-snapshot purchases, supported wallets, “tokens not showing”).  
3) **Revamp chat summaries into structured titles/topics** (Issue #6311) to improve chat navigation and perceived product quality.  
4) **Create a Plugin compatibility matrix (“Cloud-supported vs self-host”)** and answer “plugins not added to the cloud” with a definitive doc page.  
5) **Harden workflows** by adding `singleShot` parameter support + baseline retry/parameter validation patterns for multi-step tool calls (core-dev request).