## User Feedback Report — 2026-03-31 (elizaOS)

### Data sources included
- Discord summaries: 2026-03-28 to 2026-03-30 (general + coders)
- GitHub (March activity snapshot): top issues/PRs referenced in provided data (e.g., #6695, #6636, #6622, PR for CLI scaffolding fix)

---

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

> Quantification note: volume is low for the 3-day Discord slice, so “%” figures below are relative to *distinct recurring topics observed in this dataset*, not the entire community.

### 1) **Community — Fragmentation & “What’s official?” confusion** (High frequency, high impact)
**Observed in ~2/3 Discord days (Mar 29–30).**
- Users report confusion because projects built on ElizaOS (e.g., Milady, SHAW) appear independent, and investors/users can’t find a single place to understand “the ecosystem.”
- Discord channel fragmentation splits audiences (“traders/investors” vs “builders/thinkers”), causing information to be duplicated or missed.

**Examples**
- Mar 29: explicit discussion about Milady being built on Eliza but many not knowing; proposal for a centralized website hub; bridged rooms suggested by mods.

**Category:** Community / UX-Information Architecture

---

### 2) **Documentation — Onboarding ambiguity for builders (endpoints, costs, “how do I start?”)** (Medium frequency, high impact)
**Observed in Mar 29 Discord Q&A + implied in migration request (Mar 28).**
- New builders ask whether they must pay for OpenRouter/OpenAI and what endpoints are required—indicates unclear “minimum viable setup” documentation.
- Migration question (“AI16Z to ElizaOS”) appears without a clear, documented path or support playbook.

**Examples**
- Mar 29: “Do developers need to pay for OpenRouter or OpenAI models…?” not fully clarified.
- Mar 28: user requested AI16Z → ElizaOS migration help, no resolution recorded.

**Category:** Documentation

---

### 3) **Technical Functionality / Security — Autonomous spend governance gap (x402)** (High severity)
**Observed in GitHub discussions; central architectural concern.**
- Community contributors flag that agents can spend autonomously via x402 without a standardized “policy layer” to enforce budgets, whitelists/blacklists, and operator visibility before execution.
- Open question: whether current x402 plugin surfaces pre-fetch spend events to the operator (critical for governance).

**Examples**
- Issue/Proposal: Dreamline x402 Policy Facilitator (#6695): intercept payments pre-execution; blacklist + per-agent policy checks.
- Discussion mentions alternatives: MAXIA AIP Protocol, on-chain escrow logic; two-layer authorization approach (authorization + receipt objects).

**Category:** Technical Functionality (Security)

---

### 4) **Integration — Ecosystem is shifting toward “Agent Commerce,” but integration patterns aren’t standardized** (Medium frequency, medium-high impact)
**Observed in Mar 28–29 announcements + GitHub integration issues list.**
- Multiple new marketplaces/services (TaskBounty, Orbis, Pyrimid) target Eliza agents for autonomous paid work and paid API calls.
- Pain: lots of parallel integration surfaces (REST OpenAPI, MCP servers, HTTP 402 flows) without a canonical guide/pattern library for plugin authors.

**Examples**
- TaskBounty (Mar 28): OpenAPI 3.1 spec + “agent-to-agent economy” delegation.
- Orbis (Mar 29): HTTP 402 pay-per-call in USDC on Base; discovery endpoint.
- Pyrimid integration proposal (#6668): MCP catalog + x402 commerce.

**Category:** Integration / Documentation

---

### 5) **Technical Functionality — CLI install & environment setup failures (esp. Mac/bun PATH)** (Medium frequency, high impact for new devs)
**Observed in GitHub issue #6636 (open).**
- User installed `@elizaos/cli` globally via bun, added bun path, but `elizaos` still not found—suggests PATH documentation mismatch, shell profile issues, or bun global bin path confusion.

**Example**
- Issue #6636: “Unable to use elizaos command after installation on MacOS”

**Category:** Technical Functionality / Documentation (DX)

---

### 6) **Community / Moderation — Spam/scams and low signal in dev channels** (Medium frequency, medium impact)
**Observed across Mar 29–30.**
- Scam warnings issued in coders channel; solicitation-style posts appear (“quick money”).
- #coders channel content is described as “minimal technical activity,” dominated by introductions/self-promotion, reducing help throughput.

**Examples**
- Mar 29: scam warnings about fraudulent messages (pluginweb3).
- Mar 30: vague solicitation message; coders channel lacking problem-solving sessions.

**Category:** Community (Trust & moderation)

---

### 7) **Communication gap — Token economics & “project abandoned/scam?” anxiety** (High severity, but audience-specific)
**Observed strongly on Mar 30.**
- Users conflate token market cap movement with project legitimacy; confusion about supply change magnitude (40x vs 10x).
- Even when corrected (10x), broader “what’s the roadmap / are builders still here?” uncertainty remains.

**Examples**
- Mar 30: Concern raised about AI16z market cap drop; Odilitime clarifies supply increased 10x, not 40x, and that the team remains active.

**Category:** Community / Communication

---

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

### What users are actually doing
1) **Using ElizaOS as an “agent commerce runtime”** (emerging dominant theme)
- Agents: earning money (TaskBounty), paying for APIs (Orbis), transacting via x402, discovering paid tools via MCP catalogs (Pyrimid).
- This goes beyond “chatbot framework” into **autonomous economic agents**.

2) **Using Discord for two different products at once**
- Main Discord: investor/trader sentiment and token discussions.
- Side/partner discords: builder-centric workshopping.
- Users expect these to be unified or at least navigable; current split creates “ecosystem blindness.”

3) **Developers using the community as a hiring/networking board**
- Multiple detailed professional intros (trace.g, true217). This suggests builders want a marketplace for talent and projects—but it competes with technical support visibility.

### Mismatch vs intended usage (inferred)
- Intended: open-source agent framework + plugin ecosystem.
- Actual: ecosystem now behaves like a **network of agent businesses/marketplaces**, which increases the need for:
  - governance primitives (spend policies, audit trails),
  - official integration standards,
  - clear “what’s official / supported” signaling.

### Feature requests aligning with real usage
- Spend governance / policy facilitator plugin (#6695) aligns directly with agent commerce reality.
- Centralized project/agent/app hub (Discord Mar 29) aligns with “ecosystem discovery” needs.
- Bridged Discord rooms aligns with split audiences who still need shared announcements/roadmap.

---

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

### A) Fragmentation & “what’s official?” confusion
**High impact / Medium effort**
1) **Launch an “Ecosystem Directory” on the website** (agents, apps, dApps, community projects)
- Include “Built on ElizaOS” verification badge + maintainers + links (repo, docs, Discord).
- Similar pattern: ecosystems like Home Assistant / Kubernetes use curated “Awesome / Marketplace / Certified” directories to reduce fragmentation.

2) **Discord “bridged rooms” + pinned canonical navigation**
- Implement the proposed bridged room between builder Discord(s) and main Discord.
- Add a single pinned “Start here” message in each high-traffic channel with:
  - official links,
  - where to ask dev questions,
  - where token/econ discussion belongs,
  - project map.

3) **Official relationship statements for key projects**
- Short “How Milady/SHAW relate to ElizaOS” explainer pages; link them from Discord pins and the ecosystem directory.

---

### B) Onboarding ambiguity (endpoints, costs, migration)
**High impact / Low–Medium effort**
1) **“First Agent in 10 Minutes” path with explicit cost matrix**
- Table: local models (Ollama), OpenRouter, OpenAI, Anthropic; what’s free vs paid; recommended defaults.
- Include “minimum required env vars” + troubleshooting checklist.

2) **Migration guide: AI16Z → ElizaOS**
- “Concept mapping” (runtime, plugins, configs), plus a “common pitfalls” section.
- Add a Discord support thread template for migration questions to improve resolution rate.

3) **Add a CONTRIBUTING + Support escalation flow (and keep it small)**
- The community already proposed a comprehensive CONTRIBUTING.md (PR #6647). Ensure it includes:
  - where to ask (Discord vs GitHub),
  - what logs to include,
  - how to tag issues (install, plugin, x402, integrations).

---

### C) Autonomous spend governance gap (x402)
**Very high impact / Medium–High effort**
1) **Standard “Spend Policy” interface in core + reference plugin**
- A first-party interface: `beforePayment(request) -> allow/deny + reason + receipt`.
- Ship a reference plugin implementing:
  - per-agent budgets,
  - allowlist/denylist,
  - per-tx limits,
  - operator approval modes (auto/ask/deny).

2) **Operator visibility: event hooks + dry-run mode**
- Ensure x402 payment attempts emit a pre-execution event to operator UI/logs (“this agent is about to pay X to Y for endpoint Z”).
- Add “dry-run” simulation for integration testing.

3) **Receipts & audit trail standardization**
- Adopt the “authorization + receipt objects” pattern discussed by contributors.
- Similar pattern: payment systems commonly separate “authorization” from “capture” and maintain immutable receipts; web3 projects often use escrow/multisig for high-trust flows.

---

### D) Integration standardization for Agent Commerce (TaskBounty / Orbis / MCP)
**High impact / Medium effort**
1) **Create official “Agent Commerce Integration Cookbook”**
- Patterns:
  - HTTP 402 flow (request → 402 → settle → retry),
  - OpenAPI tool ingestion,
  - MCP tool discovery & invocation,
  - wallet + identity requirements (AgentID/SAID considerations).
- Provide a canonical example plugin for each pattern.

2) **Add “certified integration” tiers**
- Community integrations can be labeled:
  - Experimental (no guarantees),
  - Verified (basic tests),
  - Certified (security + policy hooks + audit logging).

3) **Testing harness for paid APIs**
- Mock 402 servers + deterministic payment receipts to let plugin authors test without real funds.

---

### E) CLI install failures (MacOS/bun PATH)
**High impact / Low effort**
1) **Update CLI install docs with bun global bin path verification**
- Add `which elizaos`, `bun pm bin -g` (or bun equivalent), and shell profile notes (zsh vs bash).
- Include a one-liner “fix PATH now” snippet and a “restart terminal” note.

2) **CLI post-install self-check**
- After `bun i -g @elizaos/cli`, provide `elizaos doctor`:
  - validates PATH,
  - checks bun version,
  - prints detected global bin dir,
  - suggests exact export line.

3) **Package manager parity**
- Ensure docs cover: bun, npm, pnpm; recommend one “golden path” for each OS.

---

### F) Spam/scams + low-signal dev channels
**Medium impact / Low–Medium effort**
1) **Stronger channel norms + routing**
- Require questions in #coders to follow a template (problem, logs, repo link).
- Move intros/hiring to a dedicated channel; auto-delete “quick money” solicitations.

2) **Scam reporting + auto-moderation**
- Add a visible “Report scam” workflow; enable link-scanning and keyword triggers in high-risk channels.
- Keep a public scam-warnings thread so users see patterns.

3) **Weekly office hours / help desk**
- A scheduled time where core contributors answer queued questions; reduces repeated low-quality pings and improves resolution tracking.

---

## 4) Communication Gaps (expectations vs reality)

### Gap 1: Token price movement interpreted as project abandonment
- Recurring question: “Is this abandoned / scam?” appears alongside market-cap discussion.
- Fix: publish a short, regularly updated “Project Status” page (shipping, repos active, roadmap checkpoints) that moderators can link instantly.

### Gap 2: “Open source” misunderstood as “free to run”
- Builders asked whether they must pay for model endpoints; implies confusion about runtime vs model provider costs.
- Fix: explicit “Open-source ≠ free inference” section in onboarding; include options for local models.

### Gap 3: Unclear ecosystem boundaries (ElizaOS vs projects built on it)
- Users didn’t know Milady was built on Eliza; similar confusion around SHAW.
- Fix: official ecosystem directory + “built with ElizaOS” attribution guidelines.

### Gap 4: Governance/security posture for autonomous spending
- Contributors highlight missing spend policy layer; users may assume this exists by default because x402 exists.
- Fix: document current state (“x402 enables payments; governance plugin recommended”) and provide a default-safe configuration.

---

## 5) Community Engagement Insights

### Power users / key contributors and needs (from provided data)
- **odilitime (Core Dev/Community Ops):** repeatedly clarifies misinformation and proposes bridging rooms; needs better “one link to answer common concerns” (status page, token/supply FAQ).
- **HaruHunab1320:** focuses on core reliability fixes; benefits from higher-quality bug reports and reproducible test cases.
- **majorelalexis-stack / hermesnousagent (discussion leaders):** pushing spend governance architecture; need a structured RFC process and a reference implementation target.

### Newcomer questions indicating onboarding friction
- “Do I need to pay for OpenRouter/OpenAI?” (cost + setup ambiguity)
- “How do I participate in agent-challenge / what endpoints do I need?”
- “How do I migrate from AI16Z to ElizaOS?”

### Converting passive users into contributors
1) **Turn integration announcements (TaskBounty/Orbis) into “good first plugin” issues**
- Provide starter templates + test harness links.
2) **Recognize and route professional-intro energy**
- A “Looking for collaborators” board with lightweight rules; keep #coders technical.
3) **Contributor pathways**
- Encourage docs fixes (install + onboarding) as first PRs; link directly from Discord pinned messages.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness (based on this dataset)
- **Discord:** high volume but low structure; technical help is often not resolved or even captured (e.g., migration question).
- **GitHub:** high-quality technical feedback (detailed reproduction steps, architecture proposals) but may miss investor/onboarding pain until it becomes acute.

### Improvements for more actionable feedback
1) **Discord → GitHub “handoff” workflow**
- A bot command like `/new-issue` that asks for logs + environment and creates a prefilled GitHub issue.
2) **Add structured issue templates**
- Installation (CLI), Payments/x402 governance, Integrations (OpenAPI/MCP), Migration.
3) **Monthly “State of DevEx” survey**
- Track install success rate by OS/package manager, time-to-first-agent, and top blockers.

### Underrepresented segments (missing feedback signals)
- **Non-crypto users** who want agents without token context (likely churn silently).
- **MacOS/bun newcomers** beyond the single issue—need broader install telemetry.
- **Teams/enterprises** evaluating governance/compliance for spend and audit (only partially represented via governance proposals).

---

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

1) **Ship a default spend-governance layer for x402** (reference plugin + core hooks + operator visibility)  
2) **Create a centralized Ecosystem Directory + “What’s official?” map** (website hub + Discord pins + verification badge)  
3) **Fix onboarding clarity: cost matrix + first-agent guide + AI16Z→ElizaOS migration guide**  
4) **Add `elizaos doctor` + update Mac/bun install docs to resolve CLI PATH failures**  
5) **Reduce Discord noise: split intros/hiring away from #coders + strengthen scam/spam controls + add a help thread template**