# User Feedback Analysis — 2026-04-15 (elizaOS)

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

> **Data note:** Daily feedback files for 2026-04-12 to 2026-04-15 were not found in the provided dataset; insights below are derived from available GitHub issues/PR discussions and weekly/monthly summaries (≈10–12 high-signal items). Percentages are approximate shares of these items.

### A. Technical Functionality (highest severity)
1) **`elizaos create` can fail on macOS due to transitive `bun` runtime dependency & postinstall behavior**  
   - Example: Issue **#6704** (“Bun's postinstall script was not run”) shows a hard failure during scaffolding; CLI cleans up the project dir, leaving users with **nothing to debug**.
   - Impact: Blocks first-run success; high churn risk.

2) **Core memory pipeline correctness issues (persistence and embedding failure handling)**
   - Example: PR **#6562** review flags:
     - **IGNORE memory silently dropped** when `ALLOW_MEMORY_SOURCE_IDS` is set (logic bug in ignore path).
     - **Zero-vector fallback on embedding failure** persists unretrievable memories (silent data corruption).
   - Impact: Trust erosion in “memory” features; hard-to-diagnose behavior.

3) **Group routing/addressee logic can break due to entity/alias ambiguity**
   - Example: PR **#6712** review flags a P1: `aliasEntity()` causes token ambiguity when `entityId !== agentId`, making addressee resolution fail (the feature’s primary goal).
   - Impact: Agents respond incorrectly (or not at all) in group rooms—high UX pain for Discord-style usage.

**Estimated prevalence:** ~35–45% of feedback items reference “things break / behave incorrectly” in core runtime, memory, or routing paths.

---

### B. Integration (high frequency, medium-high severity)
1) **Connector + encapsulation mismatches cause actions to fail or spam**
   - Example: PR **#6709**: TOON schema lacked `params`, so connectors using TOON (Discord/milady) couldn’t pass required action params (e.g., `RUN_IN_TERMINAL.command`). Also continuation loops spammed filler while async tasks ran.
   - Impact: Integrations appear “flaky” even when core actions exist.

2) **Cross-chain/financial integrations are rapidly expanding, but safety/authorization layers lag**
   - Examples:
     - Issue **#6706** SafeAgent: pre-trade safety checks across 6 EVM chains.
     - Issue **#6707** SINT capability enforcement: cryptographic authorization + human approval tiers.
     - Weekly summary: wallet plugin enabling swaps/bridging EVM↔Solana.
   - Impact: Users are building **high-stakes agents**; missing guardrails becomes a platform risk.

**Estimated prevalence:** ~30–40% of items focus on plugins/integrations (wallets, safety, marketplaces, capability gating).

---

### C. Documentation (medium frequency, medium severity)
1) **Onboarding docs don’t match real-world install paths and edge cases**
   - Example: Issue **#6704** suggests bun as system runtime but breaks via npm-style `bun` package behavior; users need explicit guidance (“don’t depend on bun package at runtime”, pnpm `ignore-scripts` caveats, what to do when scaffold fails).
2) **Roadmap expectation drift: messaging deprioritized; identity/economic layer prioritized**
   - Weekly summary notes formal deprioritization of standalone messaging protocols (e.g., XMTP closure in registry) in favor of AgentID/trust/economic primitives; this shift likely generates recurring “is X supported?” questions.

**Estimated prevalence:** ~15–25% indicate doc/expectation mismatch rather than pure bugs.

---

### D. Performance (lower frequency, potentially high severity in production)
1) **Timeout defaults and provider latency shifts can surprise deployers**
   - Example: PR **#6562** review flags `PROVIDERS_TOTAL_TIMEOUT_MS` default raising (1s→5s). Even if justified, it can raise P99 latency unexpectedly.
   - Impact: Production agents feel slower; harder SLO management.

---

### E. Community / Contribution Process (medium frequency, medium severity)
1) **Plugin contributions vary widely in quality/readiness; unclear acceptance bar**
   - Example: PR **#6701** (plugin-mnemopay) review flags “not safe to merge” due to lack of persistence, tests, null-safety, unbounded growth, and config NaN corruption.
   - Impact: Maintainer review load increases; contributors get stalled without a clear checklist.

---

### F. UX/UI (low direct signal in provided data; manifests as conversational UX)
1) **Group-room chatter and loopiness**
   - Examples: PR **#6709** continuation-loop spam; PR **#6712** anti-loop prompt guidance efforts.
   - Impact: End users perceive agents as noisy/annoying in chatrooms.

---

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

### How users are actually using elizaOS
1) **Financial/autonomous economic agents are the dominant emerging use case**
   - Signals: wallet plugin launch; SafeAgent (token safety); MAXIA marketplace proposal (swap + GPU rental + escrow); AIGEN incentive protocol; MnemoPay “economic memory”.
   - Reality: Users treat elizaOS as an **agent commerce runtime**, not just a chat agent framework.

2) **Discord/group chat connectors are a primary runtime environment**
   - Signals: PR #6709 explicitly tested via Discord/milady connector; PR #6712 focuses on group-room addressee routing.
   - Reality: “Chat UX correctness” (when to respond, to whom, with what structure) is core product value.

3) **Developers run local harnesses and multi-workspace setups**
   - Signals: PR #6702 adds `agent/` REPL harness + plugin-submodule workflows; friction arises when workspaces/submodules aren’t initialized.

### Emerging/unexpected applications
- **Authorization for physical/irreversible actions** (robots/drones/IoT) appears in SINT proposal (#6707), indicating elizaOS is being considered beyond software-only actions.

### Feature requests aligned with actual usage
- Capability-based authorization + audit trails (#6707) aligns strongly with financial and physical action use cases.
- Token safety and pre-trade checks (#6706) aligns with wallet plugin and “agents trading” reality.
- Marketplace aggregation (#6700) aligns with demand for unified economic primitives.

---

## 3) Implementation Opportunities (solutions, prioritized)

### Pain Point 1: `elizaos create` / Bun install failures (macOS + package manager edge cases)
**Proposed solutions**
1) **Remove `bun` from runtime dependencies** in `@elizaos/cli` and bootstrap templates; keep only `@types/bun` as dev dependency (as suggested in **#6704**).  
   - Impact: Very high; Difficulty: Low.
2) **Change scaffold failure behavior:** do not auto-delete the project directory on failure; add `--no-cleanup` and print a “next steps” checklist.  
   - Impact: High; Difficulty: Low.
3) **Add install-time environment validation** (bun version, detected package manager, `ignore-scripts` warning) before running build.  
   - Impact: Medium; Difficulty: Medium.

**Comparable approaches**
- Next.js / Create React App keep generated files on failure and provide “How to fix” output.
- Many CLIs implement `preflight` checks (Node version, git, package manager) before scaffolding.

---

### Pain Point 2: Memory correctness & silent data loss (IGNORE persistence, zero-vector embeddings)
**Proposed solutions**
1) **Fix IGNORE persistence logic to match normal response path** (remove hardcoded `"agent_response"` allowlist requirement; add regression tests around `ALLOW_MEMORY_SOURCE_IDS`).  
   - Impact: High; Difficulty: Low.
2) **Replace “persist zero-vector” with explicit failure handling:** mark embedding as failed + retry queue; do not include in vector search until embedded.  
   - Impact: High; Difficulty: Medium.
3) **Add a “memory integrity diagnostics” command** (counts of unembedded memories, embedding failures, allowlist drops) surfaced in logs/metrics.  
   - Impact: Medium; Difficulty: Medium.

**Comparable approaches**
- Vector DB pipelines (e.g., ingestion in LlamaIndex/LangChain) commonly store a “pending embedding” status and retry rather than writing invalid vectors.

---

### Pain Point 3: Group-room addressee routing breaks under entity/alias ambiguity
**Proposed solutions**
1) **Fix `aliasEntity`/token registry semantics** so aliases don’t create multi-entity token ambiguity; add tests specifically for `entityId !== agentId` scenarios (gap noted in **#6712** review).  
   - Impact: High; Difficulty: Medium.
2) **Publish a connector metadata spec** (`replyToEntityId`, `inReplyTo`, thread author hints) with examples for Discord/Telegram; validate metadata at adapter boundary.  
   - Impact: Medium; Difficulty: Medium.
3) **Add a “group-room simulation test harness”** (fixture transcripts) to prevent regressions in shouldRespond/addressee logic.  
   - Impact: Medium; Difficulty: Medium.

**Comparable approaches**
- Matrix/Slack bots often rely on deterministic reply-thread metadata to avoid mention ambiguity; projects typically formalize adapter contracts early.

---

### Pain Point 4: Plugin quality variance (persistence, tests, null-safety, bounded growth)
**Proposed solutions**
1) **Introduce a “Plugin Acceptance Checklist” + CI gate** for registry/core merges: required tests, persistence story (if claiming memory), null-safety, config validation, bounded resource growth.  
   - Impact: High; Difficulty: Medium.
2) **Provide an official plugin template with guardrails** (typed config schema + runtime checks; storage adapter interface; action keyword disambiguation patterns).  
   - Impact: High; Difficulty: Medium.
3) **Add “Verified Plugin” tier** (security + reliability review) for high-stakes financial tools (wallets, trading, approvals).  
   - Impact: High; Difficulty: Medium.

**Comparable approaches**
- Home Assistant’s integration review guidelines and “HACS” community store.
- VS Code Marketplace uses verification/publisher trust + automated checks.

---

### Pain Point 5: Authorization/trust expectations (capabilities, human approval, auditability)
**Proposed solutions**
1) **Define a first-class “Capability/Approval” interface in core** (even if initial implementation is a plugin), aligning with AgentID direction and proposals like **#6707**.  
   - Impact: Very high (risk reduction); Difficulty: Medium.
2) **Add policy tiers for tool calls** (observe/act/commit) with default prompts + runtime enforcement hooks.  
   - Impact: High; Difficulty: Medium.
3) **Audit trail standardization** (hash-chained events for tool calls; optional signing) to support post-incident review.  
   - Impact: Medium; Difficulty: Medium-High.

**Comparable approaches**
- Kubernetes RBAC + admission controllers (policy enforcement before “commit” actions).
- OAuth-style scoped tokens; OPA policy engines for structured allow/deny.

---

## 4) Communication Gaps (expectations vs reality)

1) **“It’s an agent framework” vs “it’s safe for autonomous finance”**  
   - Users are building trading/wallet/escrow flows now; platform needs explicit messaging about what’s safe-by-default vs requires additional controls (e.g., SafeAgent, capability enforcement).

2) **Messaging protocols deprioritization is not universally understood**  
   - Weekly summary + registry issue closure indicate focus shift to AgentID; without prominent docs/FAQ, users will continue asking about XMTP/standalone messaging support.

3) **Memory semantics are complex and under-documented**  
   - New knobs like `DISABLE_MEMORY_CREATION` / `ALLOW_MEMORY_SOURCE_IDS` (PR #6562) plus subtle bugs make expectations diverge from outcomes. Users need a “Memory modes” page with examples and pitfalls.

**Suggested documentation improvements**
- “Known-good install paths” matrix (macOS/Linux/Windows; bun vs node; pnpm caveats).
- “Safety model” doc: what guardrails exist, recommended policies for on-chain actions.
- “Group chat behavior” doc: addressee routing, reply threads, anti-loop best practices for connectors.

---

## 5) Community Engagement Insights

### Power users (and what they need)
- **odilitime**: shipping core runtime and group-routing improvements (PRs **#6562**, **#6712**, **#6702**). Needs fast feedback cycles, strong regression testing, and clear behavioral specs (shouldRespond, memory modes).
- **NubsCarson**: connector/action execution correctness (PR **#6709**). Needs stable schemas/contracts between encapsulation formats (TOON/XML) and connectors.

### Newcomer questions indicating onboarding friction
- “Why does scaffolding fail and delete my folder?” (Issue **#6704**).
- “Why don’t my actions receive params in Discord connectors?” (fixed via **#6709**, but indicates hidden contract complexity).

### Converting passive users into contributors
- Create a **“Good first issue: onboarding/installer”** track (bun dependency fixes, scaffold UX).
- Stand up a **Plugin Review Squad** with a checklist so plugin authors (SafeAgent/MAXIA/MnemoPay/SINT) can iterate quickly with predictable standards.
- Add a **registry “request for comments” label** for plugin proposals to channel early design discussion before code arrives.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **GitHub issues/PR reviews are effective for high-signal technical feedback** (repro steps, concrete fixes, code pointers).
- Missing in this dataset: **Discord qualitative pain** (confusion, “why is it spamming”, onboarding questions). The “file not found” daily logs suggest either collection gaps or pipeline reliability issues.

### Improvements for more structured feedback
1) **Add a short “Onboarding Report” issue form** (OS, bun/node, package manager, exact command, logs; whether project directory was deleted).  
2) **Adopt labels + dashboards**: `onboarding-blocker`, `connector-contract`, `memory-integrity`, `security-guardrails`.  
3) **Monthly maintainer survey in Discord** with structured questions (top blockers, requested integrations, perceived safety gaps).

### Underrepresented segments (feedback missing)
- Non-crypto production users (SaaS automation, enterprise workflows).
- Python/Rust runtime users (prompts regenerated across languages, but little direct feedback).
- Windows developers beyond one-off fixes (openrouter checkout issue referenced; more systematic Windows CI and docs likely needed).

---

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

1) **Unblock onboarding:** fix `elizaos create` bun dependency issue (remove runtime `bun` dep) and stop deleting scaffolded projects on failure (**#6704**).  
2) **Stabilize memory integrity:** patch IGNORE persistence + embedding failure handling; add regression tests (from PR **#6562** review findings).  
3) **Ship reliable group-chat behavior:** fix aliasEntity ambiguity in addressee routing and add tests for `entityId !== agentId` (PR **#6712** P1).  
4) **Establish plugin quality gates:** checklist + CI validation (tests, persistence claims, null-safety, bounded growth), informed by PR **#6701** review.  
5) **Clarify safety/roadmap messaging:** publish “AgentID + capability authorization direction” and “financial safety expectations” docs to align with the ecosystem’s actual usage (wallets, trading, escrow, marketplaces).