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

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

> Data sources in this snapshot: Discord daily digests (2026-01-04, 2026-01-05) + recent GitHub activity context (core + plugin-sql + CI workflows). Quantification is provided as “instances observed” within the provided feedback window (not global userbase telemetry).

### A. Integration (High frequency, High severity)
**1) Anthropic + MCP server requires OpenAI embeddings (and plugin order)**
- **Observed:** 1 prominent troubleshooting thread (2026-01-05), multiple replies, resolved via workaround.
- **User-impact:** Hard blocker; users believe “Anthropic-only” should work but hit `No handler found for delegate type: TEXT_EMBEDDING`.
- **Concrete symptoms**
  - `TEXT_EMBEDDING` delegate missing when using Anthropic with MCP server.
  - Requires OpenAI plugin to be present *and* placed after Anthropic; OpenAI key “doesn’t need to be valid, just non-empty” (unexpected).

**2) Ecosystem access fragmentation (Hyperscape/dev Discord access via DM)**
- **Observed:** 1 Q/A (2026-01-04).
- **User-impact:** New contributors don’t know where to go; perceived gatekeeping; slows onboarding and collaboration.

### B. Documentation (High frequency, Medium-to-high severity)
**3) “How does Eliza work?” and “how do I build X?” repeats**
- **Observed:** 1 explicit “How does Eliza work?” question (2026-01-04) plus recurring “seeking feedback / how-to” builder messages across both days.
- **User-impact:** Indicates missing “first 30 minutes” onboarding path and “recipes” for common builds (trading agents, Polymarket, MCP, social plugins).

**4) Missing explainer docs for internal concepts**
- **Observed:** Action item to document “temporal analysis for tracking council priorities” (2026-01-05).
- **User-impact:** Power users build sophisticated pipelines, but knowledge is trapped in individuals; limits replication and contribution.

### C. Performance (Medium frequency, High severity when hit)
**5) Turbo build tool extreme memory usage**
- **Observed:** 1 report (2026-01-04) citing **21GB+** memory usage.
- **User-impact:** Blocks contributors on typical developer machines/CI runners; increases friction to contribute.

### D. Technical Functionality (Medium frequency, High severity)
**6) Reliability issues in automation/code-review tooling**
- **Observed:** “Claude code review functionality experiencing issues” (2026-01-05) and follow-up action item to inspect CI logs.
- **User-impact:** Reduces trust in CI automation; slows PR throughput and raises maintainer workload.

**7) Data/DB isolation and adapter stability concerns (plugin-sql)**
- **Observed:** In GitHub context (same timeframe), multiple critical fixes merged (pool error handling, timeouts, PGLite shutdown safety, `SET LOCAL` parameterization fix).
- **User-impact:** When broken, this is a runtime/production blocker; indicates ongoing fragility for users running Postgres/PGLite with stricter settings.

### E. Community (Medium frequency, Medium severity)
**8) Token/branding confusion + scam surface area**
- **Observed:** Token confusion thread (2026-01-05) + scam warning/ban event (2026-01-05) + token price chatter (2026-01-04).
- **User-impact:** Misdirected support load; reputational risk; new users may assume token affiliation that is explicitly “not related to this project.”

---

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

### What users are actually building/doing
1) **Crypto/trading-first agent use cases dominate conversation**
- Solana trading requirements discussion (GRPC ingesters, millisecond precision, preshot systems, bundlers, Twitter feeds) suggests users are pushing elizaOS toward **high-frequency, latency-sensitive automation**, beyond “typical agent chat.”
- Token creation monitoring and on-chain competition/betting (“AI arena/colosseum”) emerged as concrete build ideas.

2) **Agents as product surfaces, not just frameworks**
- Requests imply “agent experiences” (prediction games, competitions, influencer partnerships) where elizaOS is expected to provide not only runtime, but **distribution + monetization rails** (token pairing discussion).

3) **MCP + multi-model orchestration is real-world usage**
- The Anthropic/MCP incident shows users mixing providers and expecting seamless delegation (text + embeddings) without thinking about the model taxonomy.

### Emerging/unexpected use cases
- **AI combat/competition with betting mechanics** (Babylon prediction game, “arena/colosseum”).
- **Slide/content generation variants (“Nano banana” variations)** suggesting demand for “batch creative generation” workflows.
- **Knowledge/data pipelines for governance/council priority tracking** (temporal analysis) suggesting demand for “agent analytics” and reproducible research pipelines.

### Feature requests aligned with these patterns
- Better **provider fallback** for embeddings (Anthropic + OpenAI hybrid should be “automatic”).
- **Low-latency ingestion plugin patterns** (GRPC ingester, event streaming).
- “Public agent ecosystem” direction (discovery/forking/sharing) aligns with many users wanting to share builds and get feedback.

---

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

### Pain Point 1: Anthropic + MCP requires OpenAI embeddings + plugin ordering
**High impact / Low–Medium effort**
1) **Auto-resolve embedding provider**
   - If `TEXT_EMBEDDING` handler missing, auto-select first available embedding-capable provider (e.g., OpenAI) without requiring manual plugin ordering.
   - Add a config field: `embeddingProvider: "auto" | "openai" | "anthropic" | ...`.

2) **Preflight validation + actionable error**
   - On startup (or agent init), validate required delegates (`TEXT_EMBEDDING`, etc.).
   - Replace: `No handler found...` with:  
     - “Embeddings required for MCP. Enable an embeddings provider (OpenAI, etc.) or disable embedding features.”  
     - Include exact fix snippet and plugin order guidance.

3) **Ship a documented “MCP + Anthropic” recipe**
   - A single page with: required env vars, minimal plugin list, recommended order, and troubleshooting matrix.

**Comparable approaches**
- **LangChain / LlamaIndex**: explicit “embedding model” configuration separated from “chat model,” with runtime checks and clear error messages when embeddings are missing.

---

### Pain Point 2: Turbo build memory spikes (21GB+)
**High impact / Medium effort**
1) **Provide a “low-memory dev mode”**
   - Document and/or enforce sane defaults: reduced concurrency, scoped builds, disable heavy caches for local runs.
   - Add scripts like `bun run dev:lite` or `turbo run build --concurrency=1`.

2) **CI + local profiling guidance**
   - Add a build troubleshooting doc: how to capture heap snapshots, identify large dependency graphs, and common fixes (workspace pruning, incremental builds).

3) **Repo-level optimizations**
   - Split especially heavy packages/tests; ensure build pipelines don’t duplicate work.
   - Consider standardized tooling configs (e.g., turborepo remote caching guidance; avoid generating huge artifacts in watch mode).

**Comparable approaches**
- **Vercel/Turborepo** ecosystems commonly mitigate via concurrency caps, pipeline pruning, and remote caching; many monorepos ship “lite” scripts for contributors.

---

### Pain Point 3: Claude code review / CI automation reliability
**Medium impact / Low–Medium effort**
1) **Expose CI health + failure reasons**
   - Add a dashboard-like doc section: common failure modes, where to find logs, and what triggers the workflow.

2) **Fail gracefully**
   - If Claude review fails, ensure PR status messaging is explicit (“non-blocking reviewer failed”) rather than ambiguous.

3) **Add a lightweight fallback reviewer**
   - Run a simpler lint/static check job when the AI reviewer fails, so contributors still get quick feedback.

**Comparable approaches**
- Many projects treat AI review as **advisory** and separate it from merge-blocking checks to prevent contributor friction.

---

### Pain Point 4: Token confusion + scams
**High impact (trust) / Low effort**
1) **Pinned “Official Links + Token Clarification” message**
   - Explicitly state: elizaOS token relationship status and “not affiliated with X token” disclaimers.
   - List verified domains, GitHub org, and official accounts.

2) **Auto-moderation + reporting path**
   - Add a `/report-scam` instruction and a short safety checklist pinned in newcomer channels.

3) **Expectation management in docs**
   - A short page: “Branding, tokens, and what elizaOS is/is not,” linked from README and Discord welcome.

---

### Pain Point 5: Onboarding + community navigation (dev Discord, Hyperscape access)
**Medium impact / Low effort**
1) **One public “Start Here (Builders)” hub**
   - Clear paths: (a) build a plugin, (b) run an agent locally, (c) deploy, (d) advanced/trading.

2) **Replace DM-gated access with an application form or role reaction**
   - At minimum: explain *why* it’s gated and how to get in (time expectations, requirements).

3) **Contributor ladder**
   - Curate “good first issue” + “help wanted” tags and a monthly “new contributor batch” thread.

**Comparable approaches**
- Kubernetes/CNCF-style projects convert newcomers via clear role/permissions and issue labeling conventions, plus regular newcomer office hours.

---

## 4) Communication Gaps (Expectation vs reality)

1) **“Anthropic-only” expectation vs “OpenAI key required (even invalid)” reality**
- The workaround (“OpenAI key can be any value”) is counterintuitive and undermines trust.
- Fix by: making embeddings dependency explicit, or truly removing the need for dummy keys.

2) **Token association assumptions**
- Users arrive with assumptions about “Eliza token” migration/affiliation; support had to clarify “not related.”
- Fix by: proactively clarifying naming, official assets, and affiliations.

3) **Latency expectations for trading agents**
- Users discuss millisecond infra (GRPC ingesters, preshot) implying they expect elizaOS to be suitable for HFT-like contexts.
- Fix by: publish guidance: what elizaOS can do well today (strategy, monitoring, automation) vs what requires specialized infra.

4) **Where to build and who to ask**
- “How does Eliza work?” indicates that even the core mental model (agents + plugins + models + data) needs a canonical intro.

---

## 5) Community Engagement Insights

### Power users (and what they need)
- **Stan ⚡, sayonara**: hands-on support for tricky integration (MCP + Anthropic).  
  **Need:** make their solutions reusable (docs/FAQ), reduce repeated troubleshooting.
- **Omid Sa**: onboarding explainer voice (“How does Eliza work?”).  
  **Need:** turn ad-hoc explanations into an official quickstart narrative.
- **Jin**: building knowledge pipelines + requested documentation/presentation.  
  **Need:** a “research/pipelines” area (templates, publication path, show-and-tell).
- **Odilitime / Chucknorris**: performance + trading infrastructure discussions.  
  **Need:** clear boundaries, plugin patterns for ingestion, and performance benchmarking tools.

### Common newcomer questions indicating friction
- “How does Eliza work?”
- “Is there a Hyperscape channel/Discord?”
- “Why do I need OpenAI if I’m using Anthropic?”
- “Is this token related to X?”

### Converting passive users into contributors
1) **Capture Discord fixes into GitHub Discussions/Docs**
   - Each “resolved thread” becomes a short doc PR template (“Problem / Symptoms / Fix / Why”).

2) **Plugin bounty board**
   - Trading ingestion (GRPC), Polymarket updates, slidegen variants are concrete starter contributions if scoped.

3) **Monthly builder demo + structured feedback**
   - A recurring “Show & Tell” where maintainers assign next-step issues immediately (“good first issue” conversion moment).

---

## 6) Feedback Collection Improvements

### Channel effectiveness (current)
- **Discord:** great for rapid help, but outcomes are ephemeral; repeated Q/A indicates low retention of solutions.
- **GitHub issues/PRs:** strong for actionable engineering work (e.g., plugin-sql fixes), but many user pains never become issues.

### Improvements to gather structured, actionable feedback
1) **Discord → Issue capture bot/workflow**
   - A command like `/make-issue` that posts a prefilled GitHub issue template (error text, config, versions).

2) **Weekly “Top 5 Support Threads” digest**
   - Summarize recurring questions, link to canonical docs, and open missing doc issues automatically.

3) **Short onboarding survey**
   - 5 questions after first successful run: provider used, blocker encountered, docs page missing, intended use case.

### Underrepresented segments whose feedback is missing
- **Non-crypto builders** (enterprise automation, internal tooling) are not visible in this window.
- **Non-developer end users** (people using public agents) — feedback is mostly from builders/devs.
- **Deployment operators** (observability, scaling, security hardening) — hinted via DB/CI, but not directly represented.

---

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

1) **Implement embeddings preflight + auto-fallback** for MCP/model delegation (eliminate “dummy OpenAI key” behavior where possible; otherwise document clearly).
2) **Publish a single “Start Here” onboarding path** (how Eliza works + MCP recipe + plugin ordering + common errors).
3) **Add a pinned “Official links, token clarification, and safety” post** in Discord + README link to reduce confusion/scams.
4) **Address Turbo memory spike with a documented low-memory dev mode** (scripts + concurrency caps + troubleshooting).
5) **Operationalize Discord support into durable artifacts** (support-thread-to-doc PR workflow + weekly digest).