# User Feedback Analysis — 2026-03-30 (elizaOS)

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

**Dataset note (quantification basis):** Across the provided Discord summaries (2026-03-27 to 2026-03-29) + referenced GitHub issues/discussions, we observed ~10 distinct “feedback signals” (questions, complaints, proposals, incidents). Percentages below use this small sample and should be treated as directional.

### A. Documentation — Ecosystem clarity & “what belongs to elizaOS”
- **Frequency/Severity:** High frequency, high severity (~3/10 signals, plus repeated thread emphasis).
- **User problems (examples):**
  - Users/investors can’t tell **which projects are built on elizaOS** (e.g., “most people don’t know Milady was built on Eliza”; confusion around **SHAW**, and whether new tokens/projects are independent).
  - Confusion about **organizational relationships** (e.g., “Hyperscape is incubated / joint venture / Shaw’s project—not an official Eliza Labs launch” needed repeated clarification).
  - Resulting friction: reduced investor confidence and newcomer comprehension; community feels they “can only do so much” without official consolidation.

### B. Community — Discord fragmentation & discoverability
- **Frequency/Severity:** High frequency, medium-high severity (~2/10 signals, with broad agreement).
- **User problems (examples):**
  - Split communities (“Shaw’s cozy dev Discord” vs main server serving “traders/investors”) creates **information scattering**.
  - Users want Milady integrated into main Eliza Discord or at least **bridged rooms** to reduce confusion and missed updates.

### C. Documentation / Onboarding — Cost & endpoint expectations for building/agent-challenge
- **Frequency/Severity:** Medium frequency, high severity for conversion (~1–2/10 signals).
- **User problems (examples):**
  - New builder asked: “For agent-challenge, will I be provided an endpoint so I don’t need to pay for OpenRouter/OpenAI?” (question remained effectively unanswered beyond “framework is open source”).
  - Users conflate “open source” with “free inference endpoints,” creating churn risk at first-run.

### D. Integration / Governance — Autonomous payments (x402) need operator-visible controls
- **Frequency/Severity:** Medium frequency, very high severity (~1–2/10 signals, but high risk).
- **User problems (examples):**
  - Cross-repo discussion: uncertainty whether the current x402 plugin emits **an operator-visible event before a paid fetch executes**, or if the first signal is “wallet balance change.”
  - Proposals (Dreamline “Policy Facilitator,” pre-authorization contract spec) indicate real demand for **spend governance** patterns.

### E. Technical Functionality / DX — Plugin distribution and registry workflow unclear
- **Frequency/Severity:** Medium frequency, medium-high severity (~1/10 signals).
- **User problems (examples):**
  - Plugin developer asked: how long to include plugin in main repo/registry and what distribution support exists; response required “send registry PR/plugin name,” suggesting the process isn’t discoverable upfront.

### F. Technical Functionality — Installation & environment pitfalls (CLI on macOS)
- **Frequency/Severity:** Low frequency in this slice, high severity for affected users (~1/10 signals).
- **User problems (examples):**
  - GitHub issue: `bun i -g @elizaos/cli` installs binary but `elizaos` not found despite PATH edits (macOS zsh). This is a hard blocker to adoption.

### G. Performance / Reliability (Ops) — CI/job runner billing failure
- **Frequency/Severity:** Low frequency, medium severity (~1/10 signals).
- **User problems (examples):**
  - “Job not started due to failed account payments / spending limit” suggests operational friction for contributors/teams relying on CI runners.

---

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

### Observed real-world usage patterns
1. **Ecosystem-first discovery:** Many users approach elizaOS as an **ecosystem of projects/tokens/apps** (Milady, SHAW, Hyperscape), not just a framework. They seek a “map” and official attribution.
2. **Agent Commerce is becoming the default mental model:** Multiple threads focus on:
   - **Pay-per-call APIs for agents** (Orbis with HTTP 402 + USDC on Base),
   - **Autonomous task completion + payouts** (TaskBounty with agent wallets; agent-to-agent delegation),
   - **Spend governance** (Dreamline facilitator, pre-auth layer discussions).
3. **Trading automation is a prominent use case:** A “trading flow plugin” (plug-and-play trading) and Polymarket agent import efforts reinforce a strong community pull toward financial/trading agents.

### Emerging / unexpected applications
- **Agent-to-agent labor markets:** TaskBounty’s “agents delegate subtasks to other agents” indicates users are building **multi-agent economic workflows**, not just single assistants.
- **Machine-discoverable API catalogs:** Orbis “agent discovery endpoint” shows demand for **standardized catalogs** agents can parse automatically.

### Feature requests aligned with actual usage
- **Centralized project hub / directory** (agents, apps, dApps, community projects) aligns with ecosystem-first discovery.
- **Standardized x402 governance hooks** (pre-flight events, policy plugins) aligns with agent commerce.
- **Clear plugin submission/distribution docs** aligns with growing registry activity.

---

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

### 1) Ecosystem clarity (Docs) — “What is elizaOS building, and what’s official?”
**High impact / Medium difficulty**
- **Build an official “Ecosystem Hub” page** on elizaos.org:
  - List agents/apps/dApps/community projects with **“Built on elizaOS”** badge + repository links + status (beta/alpha) + “maintained by” (Eliza Labs vs incubated vs community).
  - Include **relationship labels** (e.g., “Incubated by Eliza,” “Community-built,” “Partner project”).
  - Similar pattern: **CNCF Landscape**-style ecosystem mapping (clear categories + ownership/maintainer fields).
- **Add a “Project Identity Card” template** (README block) required for listing:
  - fields: owner, maintainer contact, repo, discord/channel, token relation (if any), security notes.
- **Publish a short “Ecosystem Canon” doc**:
  - One-page explanation of Eliza Labs vs incubations vs community projects; explicitly address “why new tokens/projects appear.”

### 2) Discord fragmentation (Community) — discovery + bridging
**High impact / Low–Medium difficulty**
- **Create bridged rooms** (as proposed) connecting dev Discord ↔ main Discord:
  - Start with 1–2 channels: `#milady-updates`, `#builder-announcements`.
  - Document what belongs where (“builders vs investors”) and pin it.
  - Similar pattern: Matrix/Discord bridges used by open-source communities to avoid splitting audiences.
- **Add a Discord “Start Here” funnel**:
  - Single welcome message with links: “Build”, “Invest/learn”, “Security/scams”, “Ecosystem hub”.
- **Create a “Milady inside Eliza” presence** without forcing full merge:
  - A read-only mirrored channel in main Discord for major Milady updates to reduce “I didn’t know it’s built on Eliza.”

### 3) Onboarding clarity: model endpoints, agent-challenge costs (Docs/UX)
**High impact / Low difficulty**
- **Add an “Inference & Cost” page**:
  - Explicitly answer: “Open source ≠ free model inference.” Provide options: bring-your-own (OpenAI/OpenRouter), local (Ollama), sponsored endpoints (if any), estimated costs.
  - Include “agent-challenge specifics”: what endpoints are provided vs what users must supply.
- **CLI onboarding checks**:
  - `elizaos doctor` command to detect missing env vars / model providers / wallet config and print next steps.
- **Template “Getting started (10 minutes)”** that ends in a working local agent using a low-friction default (e.g., local model path if supported).

### 4) x402 spend governance and operator visibility (Integration/Technical)
**Very high impact / Medium–High difficulty**
- **Add a standardized “preflight payment event hook”** in the x402 flow:
  - Emit `PAYMENT_INTENT_CREATED` before any settlement; include endpoint, amount, policy tags, and allow sync/async approval.
  - This directly addresses the core open question: whether operators can see/approve before balance changes.
- **Ship a reference “Policy Facilitator” plugin interface**:
  - Define a minimal contract: `evaluatePaymentIntent(intent) -> allow/deny + reason`.
  - Make Dreamline-like facilitators plug-compatible rather than bespoke.
  - Similar pattern: Stripe-style payment intent objects + webhook-based approvals; Kubernetes admission controllers for policy checks.
- **Provide an “allowlist/budget” built-in policy** (starter governance):
  - Per-agent daily budget, per-tx cap, destination allowlist/denylist, and an audit log.

### 5) Plugin submission & distribution workflow (Docs/Community)
**Medium impact / Low difficulty**
- **Document the plugin lifecycle** (proposal → registry PR → review SLA → release/discovery):
  - Include required metadata, security expectations, compatibility matrix.
- **Add a registry PR template** that captures “what it does, permissions (wallet/network), tests, maintainer.”
- **Create “Plugin Office Hours” (weekly)** where maintainers review new submissions live; reduces repeated “how long?” questions.

### 6) macOS CLI “command not found” (Technical/DX)
**High impact for new users / Low–Medium difficulty**
- **Update install docs** to explicitly cover Bun global bin path for zsh + common pitfalls:
  - Print the detected global bin path post-install and verify with a command.
- **Add postinstall self-check** for the CLI package:
  - On install, print: “Run `echo $PATH | grep .bun/bin`” and “`which elizaos`”.
- **Provide a Homebrew formula / npm alternative** (if feasible) for users who struggle with Bun globals.
  - Similar pattern: many CLIs offer multiple install paths to reduce environment-specific blockers.

### 7) CI/job runner billing failures (Ops)
**Medium impact / Medium difficulty**
- **Surface clearer error routing**:
  - Auto-create an issue template “CI billing/spend limit” with required org/account details.
- **Add a fallback runner strategy** for critical workflows (where possible).
- **Document CI cost ownership** (who pays, how to raise limits) for affiliated orgs (e.g., Soulmate Lang mention).

---

## 4) Communication Gaps (Expectations vs reality)

1. **“Open source” interpreted as “free endpoints.”**
   - Recurring indicator: agent-challenge endpoint question; partial answer did not resolve cost expectation.
   - Fix: put the cost/endpoint answer in a single canonical page and link it everywhere (challenge announcement, README, Discord pins).

2. **Project relationship ambiguity (official vs incubated vs community).**
   - Hyperscape relationship required explicit clarification; Milady “built on Eliza” not widely known.
   - Fix: require every promoted project to include an “Ownership/Relationship” line in announcements and hub listings.

3. **Autonomous payments: users expect governance by default.**
   - x402 discussions show an expectation of **operator-visible approval** and auditability.
   - Fix: publish a “Payments Safety Model” doc (events, policies, defaults, recommended configs).

4. **Plugin inclusion timeline expectations.**
   - Plugin dev asked “how long” and what distribution support exists.
   - Fix: publish review SLAs (even if best-effort) and a checklist to reach “registry-ready.”

---

## 5) Community Engagement Insights

### Power users / key contributors observed (and likely needs)
- **odilitime (Community Ops/Core Dev):** repeatedly coordinating solutions (bridge room; plugin guidance). Needs scalable processes (templates, automation) to avoid being a human router.
- **satsbased (Contributor/Mini Mod):** proactive ecosystem clarity and scam vigilance. Needs official artifacts (hub pages, shareable diagrams) to amplify messaging.
- **theredwizarddev (Orbis):** building agent-native API marketplace. Needs integration standards (catalog schema, auth/payment hooks) and developer feedback loops.
- **meowww404 (plugin dev):** needs clear plugin submission/distribution path.
- **stan0473 (core dev):** surfaced CI billing failure—needs ops runbooks and ownership clarity.

### Newcomer questions indicating onboarding friction
- “Do I get endpoints for agent-challenge / do I have to pay OpenAI/OpenRouter?”
- “How do I migrate from AI16Z to elizaOS?” (asked, not resolved in provided snippet)
- “CLI installed but command not found on macOS.”

### Converting passive users into contributors
- Offer **“good first issue: docs—ecosystem hub entries”** (low-code contributions).
- Create a **Contributor Path**: “Add your project to the Ecosystem Hub” → “Submit plugin to registry” → “Join office hours” → “Maintainership.”
- Recognize and empower scam-watch volunteers with a lightweight **security reporting SOP** and pinned “known scams” checklist.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord:** good for rapid discussion, but feedback is unstructured; key questions go unanswered or get partial answers; decisions (like bridging) risk being lost in scrollback.
- **GitHub:** strong for technical issues (CLI install, x402 governance design), but ecosystem/marketing clarity feedback often stays in Discord and doesn’t become trackable work.

### Improvements to gather more structured, actionable feedback
- **Introduce a weekly “Feedback Digest” issue** in GitHub:
  - Community ops posts top Discord pain points + links + proposed actions; maintainers triage.
- **Add lightweight forms** for:
  - “Onboarding blockers” (install, model config, endpoints),
  - “Payments safety concerns,”
  - “Ecosystem listing requests.”
- **Standardize tags across channels**: `onboarding`, `payments`, `plugin-registry`, `ecosystem-map`, `security`.

### Underrepresented segments
- **Non-crypto builders**: Most visible feedback is commerce/trading oriented; need outreach to users building agents for productivity/enterprise workflows.
- **Less-technical newcomers**: Investors/traders are present, but their questions need structured FAQs and a clear “what is this?” landing page.

---

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

1. **Launch an official Ecosystem Hub + relationship labels** (Built on elizaOS, incubated, partner, community) and link it in Discord pins and website nav.  
2. **Publish a canonical “Inference & Costs / Agent-Challenge Endpoints” page** and ensure moderators can answer with one link.  
3. **Implement (or spec + roadmap) an x402 “Payment Intent” preflight event + reference policy plugin interface** to enable operator-visible governance.  
4. **Reduce community fragmentation with a first bridged room + a “Start Here” funnel** (builders vs investors) and mirrored Milady updates in the main server.  
5. **Fix first-run DX blockers:** macOS CLI PATH troubleshooting in docs + add `elizaos doctor` guidance to detect environment misconfigurations.