## User Feedback Analysis — 2026-03-13 (based on 2026-03-10 to 2026-03-12 community signals)

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

> Quant note: counts/percentages are approximations from the sampled Discord Q&A and repeated threads across 3/10–3/12 (not a full-corpus metric).

#### A. **Documentation** — Token mechanics, migration, and “what should I do?” guidance (high frequency, high severity)
- **Recurring problems**
  - Confusion about **token utility vs. buyback-only value accrual** (“Any token use case?” / “Will MILADY token have any function?”).
  - Lack of a single canonical page explaining **Milady cloud → elizaOS buybacks** and how/when that happens.
  - Repeated uncertainty about **migration status** (AI16Z → elizaOS), deadline, and whether reopening is possible.
- **Evidence/examples**
  - On 3/12, **~55% (5/9)** of explicit Q&A items were tokenomics/migration-related.
  - Users asked the same question in different forms: “use case,” “buybacks,” “which token benefits,” “migration window reopened?”
- **Category:** Documentation + Communication (cross-cutting)

#### B. **Technical Functionality** — Plugin initialization race conditions / hidden side effects (medium frequency, very high severity for developers)
- **Recurring problems**
  - **plugin-sql** registers the DB adapter as a **side-effect of `init()`** while plugins initialize in parallel, creating a **race** where other plugins (e.g., plugin-personality) can run before DB is ready.
  - Workarounds in downstream apps (e.g., milaidy pre-registering plugin-sql) are viewed as **symptom fixes**, not architectural resolution.
- **Evidence/examples**
  - 3/12 xfn-framework thread explicitly calls out side-effect registration + parallel init as root cause; request to make adapter a constructor requirement.
- **Category:** Technical Functionality

#### C. **UX/UI (Developer Experience)** — “God object” runtime complexity and unclear configuration surfaces (medium frequency, high severity)
- **Recurring problems**
  - AgentRuntime described as a **6,273-line** “god object,” making it hard to reason about initialization, infra registration, and extension points.
  - Configuration discovery issues in practice (e.g., finding where to set Neon DB in Milady; permissions/capabilities still unclear).
- **Evidence/examples**
  - Runtime refactor proposal exists specifically to reduce cognitive load and hidden coupling; devs request keeping API simple.
- **Category:** UX/UI (DX)

#### D. **Security** — Scams impersonating support + seed phrase phishing (lower frequency, critical severity)
- **Recurring problems**
  - Fake support bots linking to malicious sites asking for **seed phrases** (colabdesk).
  - Confusion about whether Discord requires **wallet linking** (explicitly denied by team).
- **Evidence/examples**
  - 3/11 and 3/12 both contain scam warnings; at least two separate scam narratives occurred in 48 hours.
- **Category:** Community + Security (operational)

#### E. **Communication** — Roadmap credibility, missed deadlines, and “are devs still here?” (medium frequency, high severity)
- **Recurring problems**
  - Frustration about **missed deadlines**, unclear roadmap, and perceived mismatch between “shipping” and token/community expectations.
  - Reassurance needed that products are active (Babylon launch, Eliza 2.0 alpha, Milady timeline).
- **Evidence/examples**
  - 3/10 had sustained tension around communication + token performance; repeated “team left?” type concerns noted on 3/11.
- **Category:** Community + Documentation

#### F. **Integration** — Discovery standards fragmentation (emerging, medium severity)
- **Recurring problems**
  - Multiple discovery mechanisms: custom registries (aiprox.dev), agentskills.io discovery via `skill.md`, plus future ecosystem registries/plugins.
  - Lack of a “standard” for agent capability schemas, rating, payment rails, and metadata.
- **Evidence/examples**
  - lightningprox registry integrates via REST + `skill.md`; the path exists but feels ad hoc rather than first-class.
- **Category:** Integration

#### G. **Repository / Release Management** — Repo structure and branch strategy confusion (lower frequency, medium severity)
- **Recurring problems**
  - Confusion about why **eliza-cloud-v2** lives inside **v2.0.0 branch** vs submodules / composable layout.
  - “Develop branch is broken” blocks downstream work (noted 3/10).
- **Category:** Technical Functionality + Community (contributor friction)


---

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

#### How users are actually using elizaOS right now
- **Ecosystem-first usage:** Users track elizaOS through product launches and token narratives (Babylon launch, Milady release target, buyback model), not just framework capabilities.
- **Agents as networked services:** Builders are treating agents as **marketplace-callable microservices** with:
  - REST endpoints,
  - price-per-call,
  - payment rails (Lightning/Solana/x402),
  - reputation/rating and auto-approval scoring.
- **Cloud + microservices direction:** Active discussion on **cloud REST endpoints for embeddings** (compute + storage decoupled), implying teams are moving toward **service decomposition** vs monolithic runtime.

#### Emerging / unexpected use cases
- **Autonomous agent discovery + self-registration**: an external agent discovered a registry and attempted self-registration without prompting—this is “agents operating on the open web” behavior, not a curated in-app flow.
- **On-chain agent economy plugins**: AEP proposes reputation + credit + referral economics as first-class agent behaviors (beyond typical “tool use”).

#### Feature requests aligned with observed usage
- A **standardized agent registry spec** (capabilities, pricing, auth, telemetry, rating) to unify ad hoc patterns (aiprox.dev + agentskills.io + future registries).
- A **first-class initialization/dependency model** so “agent-as-a-service” deployments don’t rely on fragile init ordering.
- A **security hardening kit** for wallet-enabled agents (building on “LLM isolated from keys” guidance) with deployable reference architecture.


---

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

#### 1) Tokenomics + migration confusion (Documentation/Communication)
**High impact / Low–Medium difficulty**
1. **Single canonical “Token & Migration” hub page** (docs + pinned Discord post) containing:
   - Migration status (closed date), proof requirements (if reopened), and “what support can/can’t do.”
   - Token relationships: Milady app, Milady cloud revenue, **elizaOS buybacks**, and “no direct MILADY token utility (currently).”
2. **Add a “Decision log / changelog for economic policy”** (monthly) to reduce repeated re-asking.
3. **Create an official support workflow**: “Never share seed phrase” banner + verified support bot policy.

*Comparable patterns:* Ethereum L2 projects often maintain a single “Bridge/Migration Status” page + status banners; major DeFi protocols pin anti-phishing guidance and maintain verified support-only channels.

#### 2) Plugin initialization race condition + side-effect registration (Technical Functionality)
**Very high impact / Medium difficulty**
1. **Explicit dependency injection (DI) / constructor requirements** for infra components (DB adapter, queues, caches) instead of plugin side effects.
2. **Deterministic plugin lifecycle**:
   - staged init (`register → validateDeps → start`),
   - enforce topological ordering when dependencies exist,
   - fail fast with actionable errors (“plugin-personality requires DB adapter; plugin-sql not provided”).
3. **Plugin manifest schema** declaring provided/required capabilities (e.g., `provides: ["dbAdapter"]`, `requires: ["dbAdapter"]`).

*Comparable patterns:* NestJS module DI, Fastify’s plugin encapsulation + explicit decoration, Kubernetes init containers for dependency readiness, OSGi-style service registration without races.

#### 3) Runtime complexity (“god object”) and breaking-change anxiety (DX)
**High impact / Medium–High difficulty**
1. **Modularize AgentRuntime into composable subsystems** (storage, model execution, tool registry, scheduler) with narrow interfaces.
2. **Public “minimal runtime” reference implementation** that demonstrates recommended wiring patterns (especially for cloud deployments).
3. **Migration scaffolding**:
   - deprecation warnings,
   - codemods or example PRs,
   - “v2 runtime refactor cookbook” showing before/after.

*Comparable patterns:* VS Code extension APIs evolved via stable interfaces + migration guides; React/Next major releases often ship codemods and “upgrade assistant” docs.

#### 4) Security: phishing/scam resilience (Community/Security)
**Critical impact / Low difficulty**
1. **Harden Discord posture**:
   - lock down ticket bots,
   - verified links channel,
   - auto-delete messages containing common seed-phrase bait patterns.
2. **Security banner + incident playbook**:
   - “No wallet linking required,”
   - “No one will ask for seed phrase,”
   - how to report scams.
3. **Signed announcements**: publish official announcements with consistent accounts + cross-post to GitHub Discussions to reduce spoofing.

*Comparable patterns:* Many crypto OSS communities maintain “official links only” channels, anti-phishing bots, and a public incident response checklist.

#### 5) Registry/discovery fragmentation (Integration)
**Medium–High impact / Medium difficulty**
1. **Adopt/define an “Agent Registry Spec v0”**:
   - capability schema,
   - auth,
   - pricing fields,
   - rating inputs,
   - health checks,
   - metadata (model class, latency, regions).
2. **Provide a reference registry + client SDK** (TypeScript) that supports:
   - self-registration,
   - discovery queries,
   - skill.md compatibility adapter.
3. **Interoperability tests**: a small conformance suite so third-party registries (like aiprox.dev) can claim compliance.

*Comparable patterns:* OpenAPI for services, MCP-like ecosystem specs, OCI image spec enabling multiple registries.

#### 6) Repo/release structure confusion (Technical/Community)
**Medium impact / Medium difficulty**
1. **Explain the branch/repo strategy** (why cloud-v2 is in v2.0.0 branch, future plan, contribution workflow).
2. **Add “Repo map” docs**: what lives where, which branch is stable, what’s experimental.
3. **Release channels**: stable vs alpha tags + “develop branch health” badge/status.

*Comparable patterns:* Rust nightly/beta/stable channels; Kubernetes enhancement proposals + staged repos.


---

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

- **Expectation:** “Token should have utility now.”  
  **Reality:** Team states **no direct token use case currently**, value accrues via **cloud-profit buybacks**.  
  **Fix:** Put this in a single canonical doc + repeat it consistently in product announcements.

- **Expectation:** “Migration can be handled like support ticket.”  
  **Reality:** Migration window closed; reopening is uncertain; users are asked to DM proof/wallet if special handling is possible.  
  **Fix:** Publish a strict policy: what evidence is needed, what timelines exist, and why exceptions are hard.

- **Expectation:** “Plugins initialize reliably.”  
  **Reality:** Parallel plugin init + side-effect infra registration creates nondeterminism.  
  **Fix:** Document lifecycle rules now (even before refactor) and add runtime error messages that explain ordering/dependency problems.

- **Recurring newcomer questions indicating onboarding gaps**
  - “Do I need to link my wallet to Discord?”
  - “Where do I configure database/env for Milady?”
  - “How does discovery work (registry vs skill.md)?”


---

### 5) Community Engagement Insights

#### Power users / key contributors observed
- **Odilitime**: roadmap, runtime refactor, security guidance, tokenomics clarification, tooling demos.
- **s**: architectural critique focusing on API simplicity and correct root-cause framing.
- **lightningprox**: agent registry/orchestration with payments and autonomous discovery.
- **jin**: automated video briefing system to summarize comms.
- **Stan ⚡**: documentation PR for cloud content (PR #243).
- **BinaryCookies**: Milady + Neon DB integration troubleshooting.
- **TraderTomson**: AEP plugin (on-chain payments/reputation).
- **Meme Broker**: PRs to address Milady repo issue(s).

**Power-user needs**
- Stable, explicit runtime/plugin contracts (DI, lifecycle).
- Clear integration standards (registry/discovery/payment rails).
- Faster path from prototype → documented reference pattern.

#### Newcomer friction signals
- Users arriving via token/news channels need a “Start here” that covers:
  - official links,
  - migration status,
  - basic security hygiene,
  - where to ask for help safely.

#### Converting passive users into contributors
- Create **“integration bounties”**: registry spec, skill.md tooling, conformance tests.
- Add **good-first-issue bundles** tied to the runtime refactor (docs, tests, codemods).
- Hold weekly **office hours** focused on one theme (runtime init, cloud embeddings service, security hardening).


---

### 6) Feedback Collection Improvements

#### Current channel effectiveness
- **Discord is effective for rapid triage** (scams caught quickly; architecture issues surfaced), but:
  - threads mix token talk + deep technical content,
  - decisions get buried,
  - repeated questions indicate poor “single source of truth.”

#### Improvements for more structured, actionable feedback
1. **Weekly structured pulse survey** (5 questions) pinned in Discord:
   - “Top blocker this week” (choose: runtime, docs, cloud, plugins, security, other)
   - “What did you try to build?”
2. **GitHub Discussion categories** for: Token/Migration FAQ, Security Alerts, Runtime Refactor RFC feedback (link from Discord).
3. **Standard issue templates**:
   - “Plugin initialization / lifecycle bug”
   - “Cloud deployment / embeddings endpoint”
   - “Scam report” (collect URLs, screenshots, user IDs)

#### Underrepresented segments (missing feedback)
- **Non-crypto enterprise devs** evaluating elizaOS purely as an agent framework (their needs: compliance, deployment, observability).
- **Operators/SREs** running cloud services (latency, reliability, cost, incident response).
- **Linux/local-model users** (hinted by earlier plugin-ollama embedding failures) who may not be active in Discord threads.


---

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

1. **Fix the plugin initialization race at the root**: implement explicit dependency injection + deterministic lifecycle (register/validate/start) and add fail-fast errors.  
2. **Publish a canonical “Token, Buybacks, and Migration Status” page** + pin it; include anti-phishing guidance and official-link policy.  
3. **Ship a runtime refactor “migration kit”**: reference minimal runtime, upgrade guide, and API stability commitments to reduce fear of churn.  
4. **Deploy Discord anti-scam hardening**: verified links channel, bot restrictions, and an incident/reporting playbook.  
5. **Start an “Agent Registry Spec v0” RFC** (capabilities/pricing/rating/payment rails) with a reference SDK and conformance tests to unify emerging marketplace usage.