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

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

> **Data basis:** Discord highlights from **2026-01-03** and **2026-01-04**, plus GitHub product/UX issues opened **2026-01-02 → 2026-01-04** (notably #6311–#6315, #6312, #6313, #6314) and plugin/core technical threads referenced in the same window. Because 2026-01-05/06 daily files are missing, percentages below are computed over the *captured* feedback items in this dataset.

### A. Documentation (High frequency, high severity)
**What users struggle with**
- **“How does Eliza work / why use it?”** repeated in Q&A on 01-03 and 01-04 (at least **3 separate “what is Eliza” questions** across two days).
- Confusion about **how to configure**: multi-model use, adding knowledge sections to JSON, and using `useModel` with custom code.
- Upcoming work (knowledge data pipelines) noted as “documentation soon,” implying current gaps.

**Affected users**
- Primarily newcomers evaluating the project value proposition; also intermediate builders trying to configure agents beyond the starter template.

### B. UX/UI (High severity for growth; medium frequency)
**What users struggle with**
- **Public agent UX states are mixed/confusing** (GitHub #6313): unauthenticated visitors see owner-like controls (private/public toggle, edit, etc.), creating mismatched intent and trust issues.
- **Chat summaries “don’t make much sense”** (GitHub #6311), likely reducing navigability and perceived quality.
- Growth gating uncertainty: **limit messages for non-signed-in users** (GitHub #6312) and **credit amount changes** (GitHub #6315) indicate friction around first-run experience and conversion.

**Affected users**
- Public/guest users coming from shared links (e.g., Twitter), and creators trying to showcase agents.

### C. Technical Functionality (High severity, medium frequency)
**What users struggle with**
- **Plugin publishing/versioning reliability:** Discord plugin version jump (v1.3.3 → v1.3.5) and failed publish of v1.3.4 (mentioned 01-03).
- **API / model routing errors:** “Model not found” when using agent ID and API endpoints (action item from 01-03).
- **Memory/knowledge configuration uncertainty:** users asking how to add knowledge/lore sections to JSON (01-03), suggesting agent memory features are not discoverable.

**Affected users**
- Builders integrating Discord/API and those attempting more advanced agent configuration.

### D. Performance (High severity for devs; low-medium frequency)
**What users struggle with**
- **Turbo build memory usage (21GB+)** (01-04). This blocks contributors on typical machines and increases CI cost.
- Latency requirements surfaced indirectly: Solana trading discussions highlight that “standard reaction-time agents” are too slow, implying performance constraints for certain real-time use cases.

**Affected users**
- Contributors/builders running local builds; users attempting high-frequency/low-latency automation.

### E. Integration (Medium-high severity, medium frequency)
**What users struggle with / request**
- **Low-latency Solana trading integration** needs: GRPC ingesters (ms precision), “full payload preshoting,” Twitter live feeds, bundlers (01-04). Existing approaches (Jupiter/SDK) cited as ~4s delay—unusable for that segment.
- **Twitter/X capabilities**: request to create Twitter polls (01-03), and OAuth changes underway in plugin-twitter (weekly summary) suggest integration complexity and churn.
- **Multi-model routing**: users want Anthropic + OpenAI in one agent; workaround is OpenRouter + env config (01-03).

**Affected users**
- Power users building market/trading agents, and creators building distribution loops via X/Discord.

### F. Community (Medium severity, medium frequency)
**What users struggle with**
- **Access friction:** Hyperscape developer Discord exists but is gated (“DM for access”) (01-04), which may reduce contributions and support throughput.
- Ongoing “is it more than a wrapper?” skepticism (01-03) indicates messaging/community narrative misalignment.

**Affected users**
- Potential contributors and evaluators; newcomers deciding whether to invest time.

---

## 2) Usage Pattern Analysis (Actual vs. intended usage)

### Observed usage patterns
1. **Agent framework as “integration hub” more than a chat app**
   - Users talk about plugins (X, Discord, Telegram, Solana, Polymarket) and multi-model routing, treating elizaOS as orchestration middleware.

2. **Speculative/market automation is a major emergent use case**
   - Significant detail around Solana DEX transaction ingestion and token launch monitoring (01-04).
   - Polymarket plugin “Phase 2” updates signal prediction-market agents as an ongoing track.

3. **Multi-model agents are expected as a first-class workflow**
   - Users want task-based routing (“Anthropic for calculations, OpenAI for reasoning”) rather than one-model-per-agent simplicity.

### Mismatch vs intended usage (inferred)
- Intended: general-purpose agent OS with plugins and knowledge.
- Actual: many users are pushing toward **real-time, adversarial, high-velocity environments** (trading, launch sniping), where latency + reliability become the product.

### Feature requests aligned with actual usage
- **OpenRouter / provider routing** elevated from “tip” to productized feature (UI + docs + examples).
- **Twitter/X actions** beyond posting (poll creation request; token monitoring via Twitter feeds).
- **Public agent sharing UX** (separate states, message gating, analytics like chat count on cards #6314) aligns with “agents as shareable products.”

---

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

### 1) “What is Eliza / how do I start?” documentation gap
**Opportunities**
- **(High impact, low effort)** Add a “Choose your path” landing doc:
  - *I want a public shareable agent*
  - *I want Discord/Twitter automation*
  - *I want multi-model routing*
  - *I want a custom plugin*
- **(High impact, medium effort)** Provide 3 minimal “golden” reference agents:
  - “Public agent demo” (share link → guest chat → sign-up gate)
  - “Discord support agent” (Discord plugin + deployment container)
  - “Multi-model router agent” (OpenRouter + explicit per-task routing)
- **(Medium impact, low effort)** Promote “How Eliza works” answer (from Omid Sa) into official docs with a diagram of: Agent → Models → Plugins → Tools/Devices.

**Comparable patterns**
- **LangChain** and **LlamaIndex** both improved onboarding via “cookbooks” and task-based entry points rather than framework-first explanations.

---

### 2) Public agent UX confusion (owner controls shown to visitors; unclear states)
**Opportunities**
- **(High impact, medium effort)** Implement the three-state UI model proposed in GitHub #6313:
  - Unauthenticated Visitor: clean chat + agent info, no edit/toggles, 2–3 messages then overlay gate.
  - Authenticated Non-owner: chat + fork CTA, creator attribution.
  - Owner: chat/edit tabs + toggles + future analytics.
- **(High impact, low effort)** Make share link behavior deterministic:
  - Always open in “visitor” mode unless authenticated as owner.
- **(Medium impact, medium effort)** Add “agent card metrics” (chat count #6314) as social proof and discovery ranking input.

**Comparable patterns**
- **Notion templates** and **Figma community files** separate “view” vs “edit/fork,” with explicit CTAs; this reduces accidental misclicks and clarifies ownership.

---

### 3) Plugin reliability + versioning (Discord plugin publishing gaps)
**Opportunities**
- **(High impact, medium effort)** Add a release pipeline check that prevents version gaps:
  - CI validates semantic version continuity and ensures tag+package publish success before announcing.
- **(Medium impact, low effort)** Add an automated “latest known good” badge + troubleshooting doc (“If you’re on Edge, update via Chrome store…”) generalized across plugins.
- **(Medium impact, medium effort)** Provide plugin “compatibility matrix” (core version ↔ plugin version) to reduce integration breakage.

**Comparable patterns**
- **Homebrew** and **VS Code extensions** ecosystems reduce breakage via automated publishing checks + compatibility constraints.

---

### 4) Build performance/memory (Turbo 21GB+)
**Opportunities**
- **(High impact, medium effort)** Add a “low-memory dev mode”:
  - docs + default flags to reduce parallelism, disable heavy tasks, and cap workers.
- **(High impact, high effort)** Profile and fix memory hotspots:
  - identify largest package graphs; reduce TS project references fan-out; cache strategy adjustments.
- **(Medium impact, low effort)** CI-side guardrails:
  - track peak RSS in CI; fail builds exceeding a threshold to catch regressions early.

**Comparable patterns**
- **Next.js/Turborepo** community commonly uses worker caps + targeted caching to avoid runaway memory usage; many repos track memory regressions in CI.

---

### 5) Configuration clarity: multi-model routing, `useModel`, knowledge/lore JSON
**Opportunities**
- **(High impact, low effort)** One “Configuration cookbook” page with copy/paste snippets:
  - OpenRouter env examples
  - per-task provider selection pattern
  - where knowledge/lore lives in JSON + minimal example
  - `useModel({ provider: ... })` custom code example (from 01-04)
- **(Medium impact, medium effort)** Add schema validation + editor hints:
  - JSON schema for agent configs, with descriptive errors (“unknown key: lore”, “knowledge missing embedding config”, etc.).
- **(Medium impact, medium effort)** Add a CLI command:
  - `eliza validate-config path/to/agent.json` with actionable output.

**Comparable patterns**
- **Terraform** and **Kubernetes** reduce config confusion through strict validation + clear error messages + “validate” commands.

---

### 6) Integration expectations for “trading-grade” latency
**Opportunities**
- **(High impact, low effort)** Publish an explicit “Latency tiers” doc:
  - what elizaOS can/can’t do for HFT-style trading, with realistic numbers and architecture notes.
- **(Medium impact, high effort)** Provide a reference “real-time ingestion” plugin skeleton:
  - GRPC ingestion template + backpressure + message queue integration points.
- **(Medium impact, medium effort)** Create a community “Solana trading agents” channel with pinned architecture guidance to prevent repeated debates and mismatched expectations.

**Comparable patterns**
- **CCXT** and trading bot frameworks clearly separate “research/backtest,” “execution,” and “low-latency” modes to prevent capability confusion.

---

## 4) Communication Gaps (Expectation vs reality)

### Recurring expectation mismatches
- **“Operating system” label vs practical onboarding**
  - Users repeatedly ask what Eliza is and why it’s not “just a wrapper” (01-03). The concept is ambitious, but the first-run experience doesn’t quickly demonstrate differentiated value (multi-model, plugins, deployment, observability).
- **Latency assumptions**
  - Some users expect trading-grade performance; community responses indicate typical agent reaction-time is insufficient (01-04). This needs explicit positioning.
- **Access and contribution pathways**
  - Hyperscape dev Discord being gated by DM creates uncertainty about where to contribute (01-04).

### Documentation/onboarding questions to address explicitly (seen repeatedly)
- “How does Eliza work?”
- “How do I use multiple models in one agent?”
- “Where do I put knowledge/lore in the agent JSON?”
- “How do I deploy an agent with custom plugins?”
- “Why do I get ‘Model not found’ using the API?”

### Specific improvements
- Add a “Start here (10 minutes)” doc that ends with:
  1) a working agent,
  2) a plugin enabled,
  3) a clear deployment option,
  4) a short section: “What elizaOS is *not* (yet).”

---

## 5) Community Engagement Insights

### Power users (and their needs)
- **Stan ⚡**: providing authoritative guidance (multi-model via OpenRouter; container deployment; logging improvements PR #6263). Needs: amplify solutions into docs; reduce repeated Q&A burden.
- **Omid Sa**: onboarding help and practical troubleshooting (browser plugin version, conceptual explanation). Needs: convert frequent answers into canonical docs/FAQ.
- **Chucknorris (Discord)**: advanced Solana trading requirements (GRPC, preshot, bundlers). Needs: a place to collaborate without overwhelming general channels; clear statement of supported patterns.
- **Jin**: knowledge data pipelines with upcoming docs/presentation—high leverage for reducing confusion around “knowledge.”

### Newcomer friction signals
- Multiple basic conceptual questions in a short window suggest the current entry points don’t answer:
  - “What do I get out of this today?”
  - “What is the minimal working path to a deployed agent?”

### Converting passive users into contributors
- Create “good first issue” bundles tied to the most asked questions:
  - config schema docs, validate command, public agent UI state separation, plugin release pipeline checks.
- Offer “office hours” threads where maintainers answer, then capture answers into docs immediately (lightweight documentation sprints).

---

## 6) Feedback Collection Improvements

### Current channel effectiveness (based on dataset)
- **Discord** is effective for rapid Q&A but produces repeating questions and ephemeral answers.
- **GitHub issues** capture actionable UX proposals well (e.g., #6313 is detailed and implementable), but technical runtime errors (“Model not found”) need structured repro templates.

### Improvements to gather more structured feedback
- Add a **weekly “Top 5 friction points” form** linked in Discord (with fields: goal, environment, steps, expected/actual, logs).
- Introduce GitHub issue templates for:
  - “Public agent UX”
  - “Plugin publish/versioning”
  - “Build performance (memory/CPU)”
  - “API/model routing errors”
- Add lightweight telemetry/opt-in diagnostics for dev builds:
  - build peak memory reporting, plugin version info, and config validation errors (shared as a single pasteable report).

### Underrepresented segments (missing feedback)
- **Non-technical public agent consumers** (visitors clicking shared links): we mainly see creator/developer feedback, not end-user confusion metrics.
- **Enterprise / team deployments**: little feedback about multi-user governance, auditing, and permissions (despite “OS” positioning).

---

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

1) **Implement public agent 3-state UI + guest message gating** (GitHub #6313 + #6312) to reduce confusion and improve conversion from shared links.  
2) **Publish a task-based onboarding + configuration cookbook** (multi-model routing, knowledge/lore JSON, `useModel`, deployment) to eliminate repeated “how does this work” questions.  
3) **Fix/standardize plugin release reliability** (Discord plugin version gap) with CI checks + compatibility guidance to reduce breakage for integrators.  
4) **Address Turbo build memory blowups** with documented low-memory mode + profiling plan; add CI memory regression tracking.  
5) **Set expectation boundaries for low-latency trading** via a “latency tiers” doc and (optionally) a reference GRPC ingestion skeleton for advanced builders.