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

### Data coverage note
For 2026-04-17, no daily Discord/MD feedback artifact was found in the provided dataset. This analysis is based on the available GitHub issues/PR threads and automated review comments included in the aggregated data (5 issues + 6 PR discussion/review threads = **11** distinct feedback artifacts).

---

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

### 1) Documentation / Onboarding — **Install + first-run failures and “nothing left behind” outcomes** (High frequency, high severity)
**Observed in 3/11 artifacts (~27%)**
- **`elizaos create` fails on macOS (Apple Silicon) with Bun postinstall not run** and then the CLI **cleans up the directory**, leaving users without a project to inspect or fix (#6704).
- **Fresh-clone/dev workflow instability** due to workspace/submodule references committed inconsistently (PR #6702 review notes root `package.json` + `bun.lock` mismatch; missing submodule dirs break install).
- **Windows setup friction**: explicit mention of Windows git checkout blocks in `plugin-openrouter` weekly summary; indicates cross-platform dev remains a recurring theme.

**Who it affects most**
- Newcomers attempting “hello world” creation.
- Contributors on macOS/Windows (non-Linux) who rely on turnkey scripts.

---

### 2) Technical Functionality — **Memory persistence controls and correctness regressions** (Medium frequency, very high severity)
**Observed in 2/11 artifacts (~18%)**
- PR #6562 introduced valuable memory controls (`DISABLE_MEMORY_CREATION`, `ALLOW_MEMORY_SOURCE_IDS`) but review highlights **logic bugs**:
  - **IGNORE memories silently dropped** when allowlisting is enabled (hard-coded `"agent_response"` source mismatch).
  - **Zero-vector embedding fallback** can create “stored but unretrievable” semantic memories (silent data loss pattern).
- These issues are correctness/data-integrity problems; they can invalidate agents’ learning, retrieval, and auditability.

**Who it affects most**
- Production operators relying on memory for long-running agents.
- Anyone using allowlists for privacy/compliance.

---

### 3) Technical Functionality / UX — **Action execution reliability in connectors (TOON params, async loops)** (Medium frequency, high severity when it hits)
**Observed in 1/11 artifacts (~9%)**
- PR #6709 addresses real-world connector behavior:
  - **TOON schema didn’t request `params`**, so required action parameters (e.g., terminal command) were missing on non-streaming connectors → actions fail or no-op.
  - **Continuation loop spam** during async task actions (PTY sessions) created noisy filler responses (bad UX and cost).

**Who it affects most**
- Discord/community deployments using TOON encapsulation.
- Users running orchestrator/coding tasks asynchronously.

---

### 4) Integration — **Marketplace/wallet/safety integrations outpacing core guardrails** (Medium frequency, high impact domain risk)
**Observed in 4/11 artifacts (~36%)** as “integration demand signals”
- Plugin proposals focus heavily on **agent commerce**:
  - **MAXIA marketplace plugin** for swaps, GPU rental, cross-chain endpoints (#6700).
  - **SafeAgent pre-trade token safety checks** across 6 EVM chains (#6706).
  - **AgentWallet cross-chain operations** landed in-core per weekly summary (wallet plugin).
  - **MnemoPay “economic memory”** plugin PR (#6701) shows demand for financial reputation and settlement learning.

**Core friction**
- Integrations are moving into high-stakes domains (funds, escrow, trading), while the ecosystem is still standardizing:
  - authorization/approval flows,
  - audit trails,
  - safety checks,
  - persistence guarantees.

---

### 5) Community / Governance — **Plugin quality variability (persistence, tests, validation conflicts)** (Medium frequency, medium-high severity)
**Observed in 1–2/11 artifacts (~9–18%)**
- PR #6701 (`plugin-mnemopay`) review flags common ecosystem risks:
  - **No persistence** (in-memory only) contradicts “memory” promise.
  - **Config footguns** (NaN reputation corruption).
  - **Unsafe null casts** (potential runtime crashes).
  - **Ambiguous action validation** (two actions triggered by “remember”).
  - **No tests** included.

This is less about one plugin and more about the registry/core needing **stronger plugin acceptance checks**.

---

### 6) UX/UI (runtime behavior) — **Group chat routing/addressee disambiguation is brittle** (Lower frequency, high UX impact in multi-agent rooms)
**Observed in 1/11 artifacts (~9%)**
- PR #6712 introduces deterministic group addressee routing and anti-loop prompt guidance, but review finds a **P1 aliasing bug** that can break name resolution when `agentId ≠ entityId`, undermining the feature’s purpose.

---

### 7) Communication — **Expectation mismatch: “messaging protocols” deprioritized vs what users assume** (Lower frequency in artifacts, high strategic impact)
- Weekly summary indicates XMTP/messaging deprioritized in favor of **AgentID cryptographic identity**. Users building “agents that chat” may expect messaging/connectors to be first-class; the project is pivoting toward **economic trust + authorization**.

---

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

### How users are actually using elizaOS (from issues/PRs)
1. **Economic agents first, chat agents second**
   - Heavy demand for: wallets, swaps, escrow, token safety, marketplaces, GPU rental (#6700, #6706, wallet plugin summary).
2. **Discord/group-room deployments**
   - Multiple fixes and features are driven by Discord connector realities (TOON params, async action spam, group addressee routing: PRs #6709, #6712).
3. **“Agents that act” (transactions/posts/terminal) rather than only “agents that answer”**
   - Need for approval tiers, capability enforcement, audit trails (#6707 SINT capability tokens).

### Emerging / unexpected use cases
- **Agent-to-agent commerce** (marketplaces + escrow + reputation memory).
- **Compute procurement by agents** (GPU rental via Akash through marketplace proposal).
- **Safety automation** as a precondition for autonomy (pre-trade blocking, honeypot simulation).

### Feature requests aligned with observed usage
- **Capability-based authorization / human-in-the-loop tiers** (#6707) aligns with on-chain actions and “irreversible operations.”
- **Standardized token safety + risk scoring** (#6706) aligns with wallet plugin enabling trading.
- **Persistent economic memory** (PR #6701) aligns with reputation/trust focus, but must be implemented with real persistence.

---

## 3) Implementation Opportunities (2–3 concrete solutions per major pain point)

### A) Onboarding/install failures (macOS Bun + submodules/workspaces) — Priority: P0
**Solutions**
1. **Make `elizaos create` non-destructive on failure**
   - Keep the generated directory and print a “next steps” remediation block instead of cleanup (#6704).
   - Add `--no-cleanup` defaulting to true (or invert: `--cleanup` opt-in).
2. **Remove Bun runtime package from runtime deps; prefer system Bun + type-only dev deps**
   - Implement the proposed fix in #6704: move `bun` to devDependencies (keep `@types/bun`).
   - Add CI that runs `elizaos create` on macOS + Apple Silicon runner (or cross-compile simulation) to prevent regression.
3. **Stabilize submodule/dev workflow by making submodules optional**
   - Ensure root `package.json` never commits submodule workspace paths unless gated behind a script that runs in CI.
   - Add a “no-submodules” path in `scripts/dev.mjs` and document it.

**How similar projects handle this**
- **Next.js / Create React App**: scaffolds remain on disk after failure, with actionable logs.
- **Homebrew/Node toolchains**: avoid shipping large platform binaries as transitive runtime deps when the tool is expected to be installed separately.

---

### B) Memory correctness + persistence guarantees — Priority: P0
**Solutions**
1. **Fix allowlist logic for IGNORE persistence (consistency with normal path)**
   - Remove the hard-coded `"agent_response"` check or align it with actual `sourceId` values used in memory writes (PR #6562 review).
2. **Never persist “poisoned” embeddings (zero-vectors)**
   - On embedding failure: store memory without embedding + enqueue retry, or mark as `embeddingStatus=FAILED` and exclude from semantic search until repaired.
3. **Add a “memory integrity” test suite**
   - Tests that assert: allowlisted + IGNORE paths persist as intended; embedding failures don’t create unretrievable records; retrieval behaves consistently across restarts.

**How similar projects handle this**
- **LangChain / LlamaIndex** patterns: explicit vector-store write success, retry queues, and metadata flags for failed embeddings rather than silent zero vectors.
- **Databases/migrations**: “write-ahead” markers and status fields rather than corrupt placeholders.

---

### C) Action execution reliability in connectors (TOON params, async continuation loops) — Priority: P1
**Solutions**
1. **Schema-driven action parameter contract tests per encapsulation**
   - For each encapsulation format (TOON/XML/JSON): test that required params are requested and extracted.
2. **Standardize “terminal/async actions” interface**
   - Add an action metadata flag like `isAsyncTerminal: true` so message service doesn’t need hardcoded action name sets (reduces future regressions).
3. **Connector conformance checklist**
   - A short doc/test harness for connector authors: streaming vs non-streaming behavior, param passing, attachment support.

**How similar projects handle this**
- **OpenAI function calling ecosystems**: schema validation tests and tool-call extraction tests are standard for reliability.

---

### D) Plugin ecosystem quality (persistence, tests, ambiguous triggers) — Priority: P1
**Solutions**
1. **Introduce a plugin acceptance CI gate (registry or core)**
   - Require: persistence story (if claiming “memory”), minimal test coverage, null-safety checks, and action trigger conflict tests.
2. **Action validation linting**
   - Detect overlapping keywords/regex triggers across actions in a plugin (e.g., both matching “remember” in MnemoPay actions).
3. **Reference persistence adapters**
   - Provide a lightweight persistence interface + examples (SQLite/PGlite/JSONL) so plugin authors don’t default to in-memory state for “memory” plugins.

**How similar projects handle this**
- **VS Code Marketplace**: strong publishing validation and automated checks.
- **Home Assistant integrations**: documented quality tiers + required tests for core acceptance.

---

### E) Authorization/guardrails for irreversible actions — Priority: P1 (high leverage as economic features grow)
**Solutions**
1. **First-class “capability token” / policy hook in core runtime**
   - Define a stable interception point before tool execution (pre-call policy).
2. **Built-in approval tiers**
   - Provide a standard human-approval workflow for “commit” tier actions (on-chain tx, posting, file delete).
3. **Audit/evidence ledger interface**
   - Minimal interface for hash-chained action logs; plugin implementations can vary.

**How similar projects handle this**
- **Kubernetes RBAC / AWS IAM**: capability-driven authorization with explicit scopes and audit logs.
- **Browser automation frameworks**: permission prompts and “dangerous action” confirmations.

---

## 4) Communication Gaps (Expectations vs reality)

### Recurring expectation mismatches
- **“elizaos create should always work”** vs reality: dependency/toolchain edge cases (Bun postinstall, workspace/submodules) can hard-fail (#6704, PR #6702 review).
- **“memory is reliable”** vs reality: allowlist/IGNORE behavior and embedding failure handling can silently break retrieval (PR #6562 review).
- **“messaging/connectors are the roadmap”** vs reality: explicit strategic pivot toward AgentID and cryptographic trust (weekly summary).

### Questions implied by the feedback (docs/onboarding gaps)
- “What package manager is supported for CLI/project creation, and why?”
- “How do I recover debug artifacts when scaffolding fails?”
- “What are the persistence guarantees of memory-like plugins/features?”
- “What is the official stance on agent commerce safety (token safety, approval flows)?”

### Documentation improvements to align expectations
- Add a **“Known installation pitfalls”** page: Bun + macOS, pnpm `--ignore-scripts`, workspace/submodule dev mode, Windows path constraints.
- Add a **“Memory semantics”** doc: what gets persisted, how allowlists work, how failures are handled, and how to validate memory integrity.
- Publish a **“Messaging vs AgentID”** positioning note: what’s deprioritized, what’s supported, and what the replacement path is.

---

## 5) Community Engagement Insights

### Power users / key contributors and their needs
- **odilitime** (multiple core PRs): pushing runtime observability, routing, and dev harness improvements—needs faster feedback loops, clear merge criteria for medium-risk changes.
- **NubsCarson** (PR #6709): connector-driven correctness fixes—needs connector conformance tests and a stable action/param contract.
- Plugin proposers (MAXIA, SafeAgent, SINT, MnemoPay): need **clear plugin acceptance standards**, security guidance, and stable extension points.

### Newcomer friction signals
- **dirtybits** (#6704): ran into a hard fail during `elizaos create` and lost the directory—classic “new user churn” trigger.

### Converting passive users into contributors
- Add “**Good first issue: onboarding**” labels around CLI error handling, docs, and cross-platform setup.
- Provide a **plugin starter checklist** (persistence, tests, action validation, security notes) and lightweight CI templates for plugin repos.
- Run periodic “**Connector reliability**” community testing sessions (Discord bots are a major real deployment path).

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels (based on provided data)
- GitHub issues/PRs contain high-signal technical feedback, but the dataset lacks direct Discord qualitative feedback for the day.
- Many “user feedback” signals are currently embedded as **review bot findings** (Greptile/Cursor/CodeRabbit) rather than user narratives—useful, but not a substitute for user experience reporting.

### Improvements for more structured, actionable feedback
1. Add a **post-scaffold survey prompt** (opt-in) after `elizaos create`: environment, success/failure, error snippet.
2. Create a **GitHub issue form** specifically for “Install/Onboarding” with required fields (OS, arch, bun/npm versions, package manager flags).
3. Establish a **“Plugin proposal” RFC template** requiring: persistence plan, threat model (if financial), test plan, and maintenance intent.

### Underrepresented segments whose feedback is missing
- **Non-dev operators** running agents as services (deployment, monitoring, costs).
- **Windows users** beyond isolated setup fixes.
- **End users interacting with deployed agents** (UX quality in group chats, hallucination handling, safety expectations).

---

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

1. **P0: Fix `elizaos create` failure mode to never delete the project directory + ship Bun dependency correction** (addresses #6704 churn directly).
2. **P0: Patch memory correctness regressions (IGNORE allowlist logic + embedding failure handling) and add memory integrity tests** (prevents silent data loss).
3. **P1: Add connector/action contract tests (TOON params + async terminal action metadata) to prevent recurring “actions don’t execute” regressions**.
4. **P1: Introduce plugin quality gates for registry/core acceptance (persistence requirements for “memory” plugins, action trigger conflict checks, minimal tests)**.
5. **P1: Publish a short “AgentID + economic agents” roadmap note clarifying deprioritized messaging vs supported connector paths, and where authorization/approval fits** (reduces expectation mismatch as commerce features expand).