## User Feedback Analysis — 2026-03-11 (based on Discord highlights 2026-03-08 to 2026-03-10 + latest GitHub weekly summary)

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

> **Sample basis:** ~12 distinct feedback threads/questions extracted from the provided Discord highlights (Mar 8–10). Percentages below refer to share of these threads, not all community activity.

| Rank | Pain point (what users experience) | Category | Evidence from feedback | Frequency / Severity |
|---:|---|---|---|---|
| 1 | **Unclear roadmap + inconsistent updates; trust erosion** | Community / Documentation | Repeated frustration about missed deadlines, unclear launches (Babylon/Jeju), last ElizaCloud update “in January,” weak X presence enabling FUD; Odilitime explicitly acknowledged “communication failures” and promised IR improvements and elizaOS.news daily updates | **~33% (4/12)**; **High severity** (drives churn, sentiment collapse) |
| 2 | **Token utility/process ambiguity (airdrops, buybacks, “holders system,” migration)** | Community / Integration | Questions on token use case clarity, airdrop/buyback timelines, restoring holders system; ai16z→elizaOS migration requires DM + snapshot proof; users explicitly compare market recovery vs token performance | **~25% (3/12)**; **High severity** (expectation mismatch + operational friction) |
| 3 | **Core framework instability / blocked development branch** | Technical Functionality | “develop branch is currently broken”; finishing next version is positioned as a blocker for other tasks (including improved social posting automation) | **~8% (1/12)**; **High severity** (blocks contributors and downstream work) |
| 4 | **Configuration complexity + permissions issues in Milady (Neon DB + system capabilities)** | Technical Functionality / Integration | Neon DB config location discovered only via self-investigation (“env in the json file”); system permissions/capabilities question went unanswered; PRs to improve Debian/Ubuntu install via APT repo | **~17% (2/12)**; **Medium–High severity** (onboarding friction, deployment failures) |
| 5 | **Model configuration inconsistency across agents; voice costs push users to alternatives** | Integration / Performance | Reports of model configuration issues; concern about ElevenLabs cost; explicit request for a working Google voice plugin | **~17% (2/12)**; **Medium severity** (cost + reliability blockers) |
| 6 | **Lack of clear “how-to” patterns for autonomous scheduling / timed multi-agent interactions** | Documentation / UX/UI | “How can agents talk to each other in Discord on a timer?” Answer points to examples repos; indicates discoverability gap (users don’t find the right reference without asking) | **~8% (1/12)**; **Medium severity** |
| 7 | **Performance/architecture scaling concerns (prompt batching, lazy loading, in-memory persistence)** | Performance / Technical Functionality | Active work on “prompt batching” after reviewing 50–60 plugins; exploration of lazy loading and in-memory persistence suggests current architecture has efficiency bottlenecks (or anticipated ones) | **~8% (1/12)**; **Medium severity** (forward-looking but important) |

**Category-specific highlights (what affects most users)**
- **Community/Documentation:** trust is being lost due to *unclear commitments* (roadmaps, launch readiness, token plans) and *infrequent progress reporting* (notably ElizaCloud).
- **Technical Functionality:** stability of core branches and operational permissioning are blocking real deployments.
- **Integration:** voice provider costs and missing “budget” alternatives (e.g., Google) shape adoption; on-chain protocols (AEP) and DB setups (Neon) increase integration surface area.
- **Documentation/UX:** users rely on tribal knowledge (Discord answers) to discover the “right repo/example.”

---

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

**Observed real-world usage (from feedback)**
1. **Agents as revenue-generating actors on-chain**  
   - AEP plugin: marketplace participation, payments, reputation, referral income, credit access on Base.
2. **Agents as operational automation in real businesses**  
   - YOYO B2B commerce agent: LangGraph orchestration, MCP integration, Supabase/pgvector, “computer-use” to read ERPs, multi-agent purchasing decisions.
3. **Agents as social/autonomous community participants**  
   - Timed agent-to-agent Discord conversations; Twitter posting intervals referenced as a mental model.
4. **Agents as crypto trading/risk tooling**  
   - ZARQ pre-trade risk scoring plugin covering 205 tokens.

**Mismatch vs “intended” (implied)**
- The platform message appears split between **open-source agent framework** and **token/community ecosystem**. Users are using it for serious B2B automation and on-chain economics, while simultaneously seeking investor-grade clarity and shipping signals.

**Emerging / unexpected use cases**
- **On-chain reputation as a core primitive for agents** (AEP) rather than a “nice-to-have” plugin.
- **ERP “computer-use” automation** as a key adoption path for SMB workflows (higher stakes than typical demo bots).

**Feature requests that align with observed usage**
- **First-class scheduling/trigger system docs + APIs** (timers, intervals, cron-like triggers) across Discord/X and internal agent-to-agent interactions.
- **Cheaper, pluggable voice stack** (Google voice plugin; provider abstraction; cost controls).
- **Deployment-grade defaults** (permissions/capabilities, DB config validation, packaged installs like APT).

---

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

#### Pain Point A — Roadmap/updates/trust gap (Community/Documentation)
**Solutions (prioritized by impact vs difficulty)**
1. **Ship a “Weekly Ship Log” + “Now / Next / Later” roadmap with explicit confidence levels** (High impact, Low–Medium difficulty)  
   - Include: what shipped, what slipped, why, and what’s blocked (e.g., “develop branch broken”).  
   - *Comparable approach:* Kubernetes community release notes + issue burndown; Rust “Inside Rust” weekly updates.
2. **Turn elizaOS.news into a canonical changelog hub with links to PRs/issues** (High impact, Medium difficulty)  
   - Daily video is good, but users want verifiable artifacts (PRs merged, versions released, migration steps).
3. **Add a “Status” page for Babylon / Jeju / ElizaCloud** (Medium impact, Low difficulty)  
   - Even a simple Markdown page: stage, last update, current testers, next milestone.

#### Pain Point B — Token utility/process ambiguity (Community/Integration)
**Solutions**
1. **Publish one authoritative “Token Operations FAQ” with dates, definitions, and “unknowns” explicitly stated** (High impact, Low difficulty)  
   - Cover: holders system status, airdrops/buybacks (even if TBD), utility claims, and where decisions will be announced.
2. **Replace DM-based migration with a lightweight intake form + verification checklist** (High impact, Medium difficulty)  
   - Users currently must DM wallet + snapshot proof. A form reduces errors, makes progress trackable.
3. **Create a public migration tracker with anonymized counts** (Medium impact, Medium difficulty)  
   - e.g., “X submissions received, Y verified, Z completed,” to reduce repetitive questions and suspicion.

#### Pain Point C — Core branch instability blocking work (Technical Functionality)
**Solutions**
1. **Adopt a release-train model: protected `main`, gated `develop`, and a “known-good” tag for plugin authors** (High impact, Medium difficulty)  
   - *Comparable approach:* Home Assistant’s stable/beta/dev channels.
2. **CI “branch health” badge + automated rollback/lock when broken** (Medium impact, Medium difficulty)  
   - Prevents contributors from wasting time on a broken base.
3. **Document “current recommended commit/tag” for builders** (Medium impact, Low difficulty)  
   - Simple but immediately reduces friction.

#### Pain Point D — Milady config + permissions/capabilities confusion (Technical Functionality/Integration)
**Solutions**
1. **Config schema validation with actionable errors** (High impact, Medium difficulty)  
   - If Neon config must be under `env` in JSON, validate and error with “expected path: …”
   - *Comparable approach:* Next.js runtime config validation; many CLIs use Zod-based schema checks.
2. **One-page “Permissions & Capabilities” guide + troubleshooting matrix** (Medium impact, Low difficulty)  
   - Address the exact unanswered question: “How do I turn on system permissions/capabilities?”
3. **Ship a “known-good” deployment preset** (Medium impact, Medium difficulty)  
   - Docker compose + minimal JSON + example Neon env.

#### Pain Point E — Voice/model config issues and cost sensitivity (Integration/Performance)
**Solutions**
1. **Provider abstraction for TTS with cost-aware defaults** (High impact, Medium difficulty)  
   - A config switch: ElevenLabs vs Google vs local; show estimated cost per hour.
2. **Publish a working Google voice plugin (MVP) or community bounty** (Medium impact, Medium difficulty)  
   - Users asked directly for this due to ElevenLabs cost.
3. **Add “model config precedence” documentation + linting** (Medium impact, Low–Medium difficulty)  
   - Explain how per-agent vs global model config resolves; add warnings for ambiguous settings.

#### Pain Point F — Scheduling/timers discoverability (Documentation/UX)
**Solutions**
1. **Create a “Scheduling & Triggers” cookbook page** (High impact, Low difficulty)  
   - Include the exact asked pattern: Discord agent-to-agent intervals like TWITTER_POST_INTERVAL.
2. **Add templates/snippets in `examples/` with a single canonical entrypoint** (Medium impact, Medium difficulty)  
   - Users were pointed to multiple repos; consolidate.
3. **Add in-product scaffolding command** (Medium impact, Medium difficulty)  
   - e.g., CLI: `eliza create trigger --interval 30m --channel discord`.

#### Pain Point G — Performance scaling (Performance)
**Solutions**
1. **Make “prompt batching” configurable with sensible presets (local vs frontier)** (High impact, Medium difficulty)  
   - Expose scheduler options; document recommended settings.
2. **Lazy-load services by default + measure cold-start** (Medium impact, Medium difficulty)  
   - Add instrumentation to prove improvement.
3. **In-memory persistence option for dev loops** (Medium impact, Medium difficulty)  
   - Speeds iteration; reduces “rebuild state” friction.

---

### 4) Communication Gaps (expectations vs reality)

**Where expectations don’t match reality**
- **“Active projects” vs visible progress:** Users ask if Babylon/Jeju are active, indicating that “still rolling out” is not translating into observable milestones.
- **Token commitments vs timelines:** Airdrops/buybacks and holders-system restoration are referenced without firm timelines, increasing suspicion.
- **“Use of token was clear” claim vs recurring questions:** A direct question (“When were you clear about the use of the token?”) shows that prior comms didn’t land or aren’t discoverable.

**Recurring questions signaling onboarding/doc gaps**
- “Where do I configure Neon DB in Milady?” (answered only after self-discovery)
- “How do I enable system permissions/capabilities?” (unanswered)
- “How do I schedule Discord agent interactions on a timer?” (requires pointing to separate example repos)
- “Can ai16z still be converted to elizaos?” (process not finalized; DM-based)

**Specific improvements**
- Maintain **one canonical “Start Here” index** that routes to: deployments, triggers, integrations, token ops, and current stable versions.
- Use **artifact-linked updates** (PR links, release tags, migration checklist) rather than narrative-only updates.

---

### 5) Community Engagement Insights

**Power users / key contributors surfaced**
- **Odilitime** — core development + comms response; driving v2.0.0 architecture (prompt batching, serverless concepts).
- **BinaryCookies** — hands-on integrator; surfaces real deployment pain (Neon DB, permissions, model config).
- **TraderTomson** — ecosystem builder; ships AEP plugin with clear API actions and incentives.
- **s** — community support; points users to correct examples for triggers/scheduling.
- **Meme Broker** — contributes via PRs (issue #71 in milady-ai/milady).
- **jin** — built automated daily video briefing workflow for elizaOS.news.

**Newcomer friction signals**
- **AurelRheno** asked for developer opportunities and got no recorded response → indicates missed onboarding-to-contribution pathway.
- Multiple users ask basic operational questions that should be answered by docs (migration, configs, scheduling).

**Ways to convert passive users into active contributors**
- Add a **“Contributor Onramp”**: curated “good first issue” list + “help wanted (docs)” + weekly office hours.
- **Recognize community support** (like `s`) with a lightweight role and give them a maintained FAQ to point to.
- For plugin authors (AEP/ZARQ), provide **official plugin spotlights** and integration guides to encourage more third-party shipping.

---

### 6) Feedback Collection Improvements

**Current channel effectiveness**
- **Discord** is capturing high-signal pain quickly, but outcomes are inconsistent: some questions get answered with repo links; others (permissions/capabilities) remain unresolved.
- **GitHub** appears more “shipping-oriented” (PRs, repo distribution work), but user pain is not consistently converted into issues with reproducible steps.

**Improvements for more structured, actionable feedback**
1. **Standardized Discord-to-GitHub escalation** (lightweight)  
   - A bot or mod workflow: tag a message → auto-create a GitHub issue with context, logs requested, and reproduction checklist.
2. **Issue templates for top friction themes**  
   - “Install/Permissions,” “Model Config,” “Voice/TTS,” “Scheduling/Triggers,” “Token Ops/Migration” (even if token ops lives outside GitHub, track it somewhere public).
3. **Monthly “Integrator survey”** (5 questions)  
   - Capture what DBs, clouds, chains, model providers, and pain points are most common.

**Underrepresented segments**
- **Non-crypto enterprise builders** beyond the single YOYO example (likely more exist but aren’t being systematically captured).
- **New developers seeking work/mentorship** (e.g., unanswered employment inquiry).
- **Operators/DevOps** (some offered services, but no structured channel to collect deployment failure modes and metrics).

---

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

1. **Publish a canonical “Now / Next / Later” roadmap + weekly ship log with blockers and links** (trust + clarity; lowest effort for highest sentiment impact).  
2. **Replace DM-based token migration with a structured intake + public tracker + single Token Ops FAQ** (reduces repetitive questions and suspicion; improves operational throughput).  
3. **Stabilize developer experience: define a known-good release tag + CI branch health gating** (unblocks contributors; reduces “develop is broken” fallout).  
4. **Ship two high-friction docs fast: (a) Permissions/Capabilities in Milady, (b) Scheduling/Triggers cookbook** (directly answers the most common “how do I…?” patterns).  
5. **Voice + model config initiative: provider abstraction plan + Google TTS MVP path + config precedence docs** (aligns with cost sensitivity and real deployment needs).