# User Feedback Analysis — 2026-01-05 (elizaOS)

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

**Sample size note:** The analysis below is based on **19 distinct feedback items** surfaced across Discord (action items + recurring questions) and GitHub (top issues/PR notes) in the provided data snapshot.

### A. UX/UI (highest frequency + highest funnel impact)
**What users are struggling with**
- **Public agent experience is confusing across user states** (unauthenticated visitor vs authenticated non-owner vs owner). Users report seeing controls that don’t match their intent (e.g., private/public toggles, edit/fork confusion). (GitHub #6313)
- **No clear “try before signup” interaction model** for public agents; request to **limit non-signed-in messages to ~2–3** and then soft-gate signup. (GitHub #6312)
- **Chat summaries are low-quality / not representative**, reducing scan-ability and trust in the chat list. (GitHub #6311)
- **Public agent cards missing basic social proof**, e.g., request to show total chat/message count. (GitHub #6314)

**Frequency (proxy):** **4/19 items (~21%)** directly target public-agent UX and chat-list comprehension.

---

### B. Documentation (recurring questions indicate onboarding friction)
**What users are struggling with**
- **“How does eliza work?” / “Is it an operating system?”** indicates conceptual onboarding gaps and inconsistent mental models. (Discord 2026-01-03 Q&A)
- Lack of **concrete examples for multi-model agents** (Anthropic + OpenAI) and how to do provider routing correctly. (Discord 2026-01-03 + requested doc action items)
- Missing/unclear docs for **deploying agents with custom plugins** in cloud containers. (Discord 2026-01-03 action items)
- Docs need to reflect **new logging standards + linter usage** (introduced via PR #6263 and related work). (Discord 2026-01-03 action items)

**Frequency (proxy):** **3/19 items (~16%)** are explicitly doc action items, plus multiple Discord questions that are “doc-shaped.”

---

### C. Technical Functionality (correctness bugs + core capabilities)
**What users are struggling with**
- **Data isolation can break all DB operations** when `ENABLE_DATA_ISOLATION=true` due to PostgreSQL `SET LOCAL` parameterization behavior. (PR #6316 description)
- Agents **unable to recall information from bio**, suggesting memory ingestion/retrieval issues or unclear memory configuration expectations. (Discord 2026-01-03 action items)
- Requests for agents to support **calculation/forecasting** as a more reliable capability (often a sign that tool use / deterministic computation is desired). (Discord 2026-01-03 action items)

**Frequency (proxy):** **3/19 items (~16%)**, but severity is high (DB isolation bug is potentially platform-blocking).

---

### D. Performance (speed + responsiveness)
**What users are struggling with**
- Multi-provider execution previously incurred unnecessary latency; PR **#6263 parallelizes provider handling** in MultiStep (performance improvement). Users discussing multi-model setups reinforces this need. (PR #6263 + Discord multi-model discussion)

**Frequency (proxy):** **1–2/19 items (~5–11%)**; impact is broad because it affects every multi-step/multi-provider agent.

---

### E. Integration (providers, plugins, website embedding)
**What users are struggling with**
- **“Model not found”** when integrating agents into websites via API keys—likely misconfigured provider/model IDs, OpenRouter/provider mismatch, or environment variable confusion. (Discord 2026-01-03 action items)
- **Plugin versioning inconsistencies** (example: Discord plugin version mismatch v1.3.3 vs v1.3.5; browser plugin store differences between Edge/Chrome). (Discord 2026-01-03)
- Confusion around **how to run/deploy agents with custom plugins** and whether to use cloud vs self-hosted containers. (Discord 2026-01-03)

**Frequency (proxy):** **3/19 items (~16%)**.

---

### F. Community / Product Policy (expectations around credits + roadmap)
**What users are struggling with**
- **Free credits policy change request** ($5 → $1) suggests unclear cost expectations and/or abuse prevention vs onboarding conversion tension. (GitHub #6315)
- “Any updates?” style pings about ecosystem projects (e.g., DegenAI), reflecting desire for clearer roadmap/status signals. (Discord 2026-01-03)

**Frequency (proxy):** **2/19 items (~11%)**.

---

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

### How users are actually using elizaOS
- **Multi-model orchestration**: Users want one agent to route tasks across providers (e.g., Anthropic for calculations/forecasting + OpenAI for reasoning). This is beyond “single-provider chat” and aligns with elizaOS being treated as an **agent runtime/orchestrator** rather than a thin chat wrapper. (Discord 2026-01-03)
- **Agents embedded on websites** via API keys for interactive experiences and lead-gen flows. (Discord 2026-01-03)
- **Operationalization mindset**: increased emphasis on logging standards, linting logs, and database reliability suggests users are moving from prototyping → production. (PR #6263 + logging linter mention; PR #6316 DB isolation fix)
- **Web3/crypto use cases**: interest in earning crypto (Hyperscape), DeFi/social plugins, and community project updates indicates a meaningful segment using agents for on-chain or incentive-driven workflows. (Discord + monthly/weekly summaries)

### Emerging / unexpected applications
- **“Explicit agency boundaries + accountability layers”** (roseOS) indicates an advanced architecture segment treating elizaOS as a base layer for governance, safety constraints, and auditability—more like an “agent OS kernel.” (Discord 2026-01-03)

### Feature requests aligned with real usage
- **Public agent funnel UX** (try → signup → fork/manage) is aligned with sharing agents on social and embedding them externally. (GitHub #6312, #6313, #6314)
- **Better summaries + analytics (chat count, future views/chats/forks)** aligns with “agents as products.” (GitHub #6311, #6314, #6313)
- **Twitter poll creation** aligns with social automation and community engagement agents. (Discord 2026-01-03)

---

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

### 1) Confusing public-agent UX states (Unauth / Auth non-owner / Owner)
**High impact, medium difficulty**
1. **Implement explicit UI state machine for public agents** (as proposed in #6313) with three dedicated views and permission-scoped controls.
   - Unauth: chat-only + agent profile + share link + soft gate after 2–3 messages.
   - Auth non-owner: chat + attribution + fork CTA (no edit/toggles).
   - Owner: manage UI (chat/edit tabs, visibility toggle, share, analytics stub).
2. **Add progressive disclosure for “Fork”**: hide fork until signup/login, then show a clear “Fork this agent” path with a short explanation.
3. **Instrument and A/B test** the soft gate (2 vs 3 free messages) and measure conversion + retention.

**Comparable patterns**
- **Hugging Face Spaces / GitHub templates**: “view/run first, then duplicate/fork when authenticated.”
- **Notion shared pages**: read/try first, then prompt signup for continued interaction.

---

### 2) Chat summaries are low-signal / misleading
**High impact, medium difficulty**
1. **Replace current summaries with “topic + last user intent + last agent outcome”** (short structured summary) rather than a generic abstractive snippet.
2. **Fallback logic**: if summarization confidence is low, show **“Last message preview”** instead of a summary.
3. **User-controlled rename + pin key chats** (rename exists; extend with optional pinning) to reduce reliance on summaries.

**Comparable patterns**
- **Slack/Discord** rely on last-message previews and user naming; **Linear** uses short, structured labels rather than full abstractive summaries.

---

### 3) Provider/model configuration confusion (“Model not found”, multi-model routing)
**High impact, low–medium difficulty**
1. **Add a “Provider Diagnostics” CLI command** (`eliza doctor`) that validates:
   - provider selection (Cloud/OpenRouter/OpenAI/Anthropic),
   - model IDs,
   - required env vars,
   - API key presence and permissions.
2. **Ship a multi-model reference template** (copy-paste) showing task routing (e.g., “math/forecasting” toolchain vs “general reasoning”).
3. **Improve error messaging**: map “Model not found” into actionable hints (“model id typo”, “provider mismatch”, “OpenRouter model naming”, “missing OPENROUTER_API_KEY”).

**Comparable patterns**
- **Vercel/Netlify build diagnostics**: preflight checks + actionable remediation steps.
- **LangChain templates**: canonical example projects that become de facto docs.

---

### 4) Plugin versioning and deployment with custom plugins (cloud containers)
**High impact, medium difficulty**
1. **Introduce a plugin compatibility matrix** (core version ↔ plugin versions) published in docs and surfaced in CLI during install.
2. **Standardize plugin release tags + changelog snippets** and link them from the registry (reduces store/version confusion).
3. **Provide “cloud container deploy cookbook”**:
   - minimal Dockerfile + example `eliza` CLI commands,
   - how to bundle private/custom plugins,
   - how to verify plugin load at startup.

**Comparable patterns**
- **Home Assistant** add-on store and compatibility badges.
- **Kubernetes Helm charts** with version constraints.

---

### 5) Memory/recall issues (agent can’t recall bio)
**Medium–high impact, medium difficulty**
1. **Make “bio memory” ingestion explicit**: on agent creation, show a toggle “Index bio into memory” and display where it’s stored (profile-only vs memory store).
2. **Add a “Memory inspector”** for owners: view what facts are stored, last updated timestamps, and retrieval traces for a given answer.
3. **Provide a recommended memory policy preset** (e.g., “Assistant persona facts always pinned”) to reduce misconfiguration.

**Comparable patterns**
- **Rasa** and other conversational platforms: debug tools showing NLU/memory traces.
- **OpenAI assistants tooling**: inspectable resources/files and retrieval behavior.

---

### 6) Data isolation breaking DB operations (ENABLE_DATA_ISOLATION)
**Critical impact, low difficulty (already addressed in PR #6316)**
1. **Fast-track merge + release notes** highlighting the fix and affected configs.
2. **Add a startup check**: if isolation enabled, run a quick `SET LOCAL` sanity test and fail with a clear error if DB/driver behavior is incompatible.
3. **Document isolation mode**: what it is, when to enable, common pitfalls.

**Comparable patterns**
- Frameworks that gate advanced flags behind “experimental” warnings + preflight checks (e.g., Next.js experimental flags).

---

### 7) Credits policy confusion ($5 → $1 request) + public-agent gating
**High impact, medium difficulty (policy + UX + abuse)**
1. **Align credits and public-agent gating**: instead of reducing credits globally, enforce **unauthenticated message limits** and rate limits per IP/session.
2. **Expose a simple “usage meter”** in UI: remaining free messages/credits and what triggers signup.
3. **Publish a short pricing/credits rationale** (“protect from abuse, keep demo accessible”) to reduce surprise and speculation.

**Comparable patterns**
- Many SaaS products use **soft gates** + **transparent meters** (e.g., API dashboards).

---

## 4) Communication Gaps (expectations vs reality)

### Where expectations don’t match reality
- Users compare elizaOS to **“Linux for agents”**, but newcomers still ask basic identity questions (“How does eliza work?”, “Is it an OS?”). This suggests branding is strong, but **the first 5 minutes experience doesn’t translate the metaphor into concrete steps**. (Discord 2026-01-03)
- Multi-model orchestration is desired, but current guidance is mostly “use OpenRouter + env vars,” which feels under-specified for production users. (Discord 2026-01-03)
- Public agents shared via Twitter create an expectation of **frictionless try-first UX**, but current UI exposes owner-centric controls. (GitHub #6313)

### Recurring questions that indicate doc/onboarding gaps
- “How do I implement two models in one agent?”
- “Should I deploy custom plugins in cloud containers?”
- “Why do I get ‘Model not found’ when embedding on my website?”
- “Why can’t the agent recall what’s in the bio?”

### Specific improvements to align expectations
- Add an **“ElizaOS in 10 minutes”** path: (1) run agent, (2) add one plugin, (3) deploy, (4) share public link.
- Add a **Public Agent Sharing Guide**: what viewers see unauthenticated, message limits, and how to fork after signup.
- Add a **Troubleshooting index** keyed by error strings (“Model not found”, plugin version mismatch).

---

## 5) Community Engagement Insights

### Power users and their needs
- **Stan (standujar)**: driving performance/logging rigor (PR #6263; logging linter initiative). Needs: clear standards adoption path across plugins/projects.
- **borisudovicic**: highly active on UX funnel issues (issues #6311–#6315). Needs: quick iteration loop, UX metrics, and clear ownership of product UX workstreams.
- **roseOS**: advanced architecture experimentation (agency boundaries/accountability). Needs: extension points, governance hooks, and clearer “kernel vs distro” boundaries in architecture docs.
- **Omid Sa**: hands-on troubleshooting and guidance (plugin versions, multi-model). Needs: better diagnostic tooling to reduce manual support load.

### Newcomer questions indicating onboarding friction
- Basic “what is elizaOS” understanding (Discord newcomer pattern).
- Provider/model setup confusion (“Model not found”).
- Deployment uncertainty (cloud containers vs self-hosting).

### Converting passive users into contributors
- Create **“Good First Issue” bundles** tied to onboarding/docs: multi-model example, deploy cookbook, troubleshooting pages.
- Add a **plugin-maintainer program** with lightweight expectations (versioning, changelog, compatibility badge).
- Publish short **architecture RFC templates** so advanced users (like roseOS) can propose extensions in a consistent format.

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord**: fast Q&A and peer support, but feedback is **unstructured** and hard to trend over time.
- **GitHub issues**: high-quality problem statements (notably UX), but the snapshot shows multiple issues with **0 comments**, suggesting potential triage bandwidth gaps or unclear routing.

### Improvements for more structured, actionable feedback
1. **Introduce a weekly “Top Frictions” intake form** (3 questions + optional screenshot) that auto-files labeled GitHub issues.
2. **Add GitHub issue templates** specifically for:
   - Provider/model errors (collect env/provider/model ID),
   - Plugin issues (plugin name/version/core version),
   - Public agent UX feedback (state: unauth/auth/owner).
3. **Add lightweight product analytics events** (opt-in for OSS):
   - public agent link opens,
   - unauth message count before gate,
   - fork button clicks,
   - “Model not found” occurrences by provider.

### Underrepresented segments (missing feedback)
- **Non-Discord users** embedding agents into websites (integration bugs are showing up, but likely underreported).
- **Enterprise/self-host operators** (data isolation suggests production usage, but we lack systematic operational feedback).
- **Plugin maintainers** (versioning issues hint at maintainer tooling gaps).

---

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

1. **Ship the “Public Agent States” UX refactor** (unauth/auth non-owner/owner) + **2–3 message soft gate** for unauth users. (Highest conversion + least ambiguity; aligns with #6312/#6313)
2. **Add “Provider Diagnostics” (`eliza doctor`) + upgrade “Model not found” errors** into actionable guidance. (Reduces support load; improves website embedding success)
3. **Publish two concrete docs deliverables**: (a) multi-model agent example template, (b) cloud container deployment cookbook for custom plugins. (Addresses repeated Discord questions)
4. **Finalize and publicize reliability improvements**: merge/release **data isolation fix** (PR #6316) and add a startup sanity check for isolation mode. (Prevents production-blocking failures)
5. **Improve chat list comprehension**: replace low-quality chat summaries with structured summaries or last-message preview fallback; add chat count on public cards. (Addresses #6311/#6314 and supports “agents as products” usage)