# User Feedback Analysis — 2026-01-22 (elizaOS)

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

### A. Technical Functionality
1) **DB migration fragility (PGLite → PostgreSQL)**
- **Example:** DigitalDiva reported that even with correct `DATABASE_URL` and schema/permissions, the runtime still attempted to use `.eliza/.elizadb` and failed on `CREATE SCHEMA IF NOT EXISTS migrations`, then errored creating `worlds` (UUID/JSONB) while “searching for PGLite instead of Postgres.”
- **Severity:** High (blocks startup / data persistence).
- **Frequency signals:** Multiple back-and-forth messages; also aligns with ongoing `plugin-sql` complexity and recent DB-focused fixes/refactors in the repo.

2) **Plugin/core version mismatch causing runtime failures**
- **Example:** Discord plugin failures after upgrading from 1.6.5; resolved only after aligning to **elizaos 1.7.2 + plugin-discord 1.3.7** and performing a clean DB reset.
- **Severity:** High (integration breaks core user workflow).
- **Frequency signals:** Repeated “which version works?” questions; multiple users referenced the breakage.

3) **Python examples/plugins not runnable out-of-the-box**
- **Example:** PR **elizaos/eliza#6358** added Python quickstart docs, `.env` loading, and corrected `inmemorydb` plugin interface usage—implying prior user friction running examples.
- **Severity:** Medium–High (onboarding and adoption impact, especially for Python-first builders).

### B. Documentation
4) **Integration “how-to” gaps for real user goals (Cloud + plugins)**
- **Examples (unanswered):**
  - “How can I integrate the Polymarket plugin to elizacloud agent?” (ElizaBAO)
  - “Best practices for marketing/sales agents for automated LinkedIn + email?” (Thirtieth)
- **Severity:** Medium–High (users are trying to build production-ish agents; lack of guidance stalls them).

5) **Operational/upgrade/migration guidance missing or scattered**
- **Example:** Users needed community guidance for `elizaos update`, version pinning, and the “drop & recreate DB” workaround.
- **Severity:** Medium (causes downtime and risky recovery steps).
- **Related prior signal:** Core devs noted missing CLI upgrade instructions (Jan 20).

### C. Integration
6) **Risk controls unclear for autonomous transactions (Safe / onchain actions)**
- **Example (unanswered):** UNKE_CED asked about “risk management, limits, approvals for agents that transact autonomously, building on top of Safe.”
- **Severity:** High (security/financial loss risk; enterprise adoption blocker).

7) **External API readiness unclear (X/Twitter API key, etc.)**
- **Example (unanswered):** “Do we have a X api key yet?” (jin)
- **Severity:** Medium (blocks social/marketing automations that community is actively building).

### D. Community / Communication
8) **Token/airdrop expectations vs. reality**
- **Examples:**
  - Repeated airdrop eligibility questions for CEX holdings; response: “no official details announced.”
  - Broader partner frustration (Jan 20) around token utility clarity and roadmap linkage.
- **Severity:** Medium–High (sentiment + trust; distracts from building).

**Quantified signal (from captured FAQs Jan 20–21):** 13 distinct “FAQ-style” questions were logged across channels; **5 were unanswered (~38%)**, concentrated in integrations (Polymarket/ElizaCloud, Safe risk controls, X API key, marketing outreach best practices).

---

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

### How users are actually using elizaOS
- **Support automation (production-adjacent):** Thirtieth pivoted from a Polymarket agent to a support agent (“Hank”) that handled a real support request for a scientific research tool.
- **Growth/marketing automation:** Strong pull toward agents that do **LinkedIn + email campaigns**, plus social content pipelines (auto transcripts → tweet notes).
- **Moderation/ops automation:** Community has deployed an Eliza-based Telegram moderation bot (“Solimp”) with escalating timeouts—suggesting real demand for “agent-as-ops-tooling.”
- **Cost-avoidant local-first building:** Shl0w explicitly wants an Eliza/n8n-like system that **doesn’t require paid APIs or databases** to stay scalable.

### Mismatch vs intended positioning
- Intended: open-source agent framework + cloud + future network (Jeju).
- Actual: users need **immediate, opinionated recipes** for:
  - deploying agents reliably (DB, plugin versions),
  - integrating with cloud and third-party platforms,
  - safe automation that can touch money/social accounts.

### Emerging / unexpected use cases to support
- **Agentic content ops:** transcript generation + “tweet-ready” notes as a repeatable internal toolchain.
- **Swarm/multi-bot deployments:** interest in running many bots in one environment (cost efficiency), which increases the importance of observability and data retention controls.

---

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

### Pain point: DB migration fragility (PGLite → Postgres)
**High impact / Medium difficulty**
1) **Add an explicit “active adapter” startup check + diagnostic output**
- On boot, print: selected adapter, resolved `DATABASE_URL`, and the reason (env var precedence, config file, defaults).
- Fail fast with a clear error if `DATABASE_URL` is set but runtime still resolves to local `dataDir`.

**High impact / Medium difficulty**
2) **Provide a first-class `elizaos db migrate` / `elizaos db doctor` command**
- Doctor runs connectivity, permissions, extension checks, and confirms schema readiness.
- Offer guided “safe reset” steps (export, drop, re-init), avoiding ad-hoc Discord advice.

**Medium impact / Low difficulty**
3) **Publish a supported matrix for DB modes**
- Document: PGLite vs Postgres vs Neon (noting ongoing Neon support work in `plugin-sql`) and what features differ.

*Comparable approach:* Supabase/Prisma-style “doctor” commands and migration troubleshooting guides reduce “silent fallback” and environment confusion.

---

### Pain point: Plugin/core version mismatch
**High impact / Low–Medium difficulty**
1) **Compatibility matrix + automated warning**
- Maintain a small machine-readable mapping (core ↔ plugin versions) and warn during `elizaos start` if mismatched (e.g., “plugin-discord 1.3.6 detected; recommended 1.3.7 for core 1.7.2”).

**High impact / Medium difficulty**
2) **Lockfile-based template starters**
- Provide official starter repos with pinned versions and a one-command upgrade path (`elizaos update --safe`) that updates core + official plugins together.

**Medium impact / Low difficulty**
3) **Release notes that explicitly call out “breaking plugin sync”**
- Discord users asked “which version works?”—this should be answered by release artifacts, not chat archaeology.

*Comparable approach:* Homebrew-style “keg-only” warnings and Next.js “upgrade codemod” guidance reduce ecosystem drift.

---

### Pain point: Integration docs missing for Cloud + plugins (Polymarket, outreach, etc.)
**High impact / Medium difficulty**
1) **Write “task-based” guides instead of component docs**
- Example guides:
  - “Deploy a Cloud agent with plugin-Polymarket”
  - “Build a support agent (ticket ingestion → answer → escalation)”
  - “Marketing outreach agent (guardrails + rate limits + opt-out)”

**High impact / Medium difficulty**
2) **Ship runnable reference implementations**
- A minimal repo per use case with:
  - environment variables checklist,
  - rate limit defaults,
  - audit logging enabled,
  - “safe mode” toggles.

**Medium impact / Low difficulty**
3) **Add an “Integration Requests” issue template**
- Forces: goal, platform, auth method, expected/actual, logs, and whether Cloud or self-hosted.

*Comparable approach:* Stripe and LangChain succeed via “recipes + runnable examples,” not only API references.

---

### Pain point: Safe / autonomous transaction risk controls unclear
**High impact / Medium difficulty**
1) **Introduce a “transaction policy” layer**
- Configurable per agent:
  - allowlists (contracts, methods),
  - max spend per window,
  - human approval requirement above thresholds,
  - simulation-first mode.

**High impact / Medium–High difficulty**
2) **Provide Safe-specific integration patterns**
- Reference architecture: proposal creation → policy check → optional human signer → execution.
- Include event/audit logs suitable for incident review.

**Medium impact / Low difficulty**
3) **Document the security stance**
- Explicitly state what elizaOS does *not* provide yet (e.g., “no built-in key custody,” “no default Safe policy engine”) to prevent unsafe assumptions.

*Comparable approach:* OpenZeppelin Defender and Safe modules emphasize policy gating + audit trails as defaults.

---

### Pain point: Data storage concerns (“storing too much info”)
**High impact / Medium difficulty**
1) **Add retention controls + storage reporting**
- Per adapter: max memory age, max per-room messages, max vector store size, purge schedule.
- Provide a `storage report` command that summarizes table sizes and growth.

**Medium impact / Medium difficulty**
2) **PII-aware logging and memory controls**
- Toggle to prevent storing sensitive fields (especially for outreach/support agents).

**Medium impact / Low difficulty**
3) **Document “what gets stored where”**
- A single diagram page for: messages, memories, entities, worlds, logs.

*Comparable approach:* Sentry and PostHog ship retention controls + “data management” pages to build trust and prevent runaway storage.

---

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

1) **Airdrop eligibility and token utility**
- Users repeatedly asked about CEX eligibility; answer is effectively “unknown.”
- Gap: community is acting on implied benefits (“holders will receive free access and exposure to airdrops”), but operational rules aren’t published.

**Improvements**
- Publish a living “Token Utility & Airdrops” page with:
  - what is confirmed vs rumored,
  - eligibility principles (if any),
  - timelines (if any),
  - explicit disclaimer when unknown.

2) **Hosted Eliza Town availability**
- Users asked for a hosted version; it exists as community GitHub work, but “user-facing version coming soon” is vague.

**Improvements**
- Add a public status page (or pinned Discord post) with:
  - current state (repo-only vs hosted),
  - who maintains it,
  - expected milestones.

3) **“It should just work” assumption for upgrades**
- Real workflow required: update core/plugin + drop DB + reinstall.
- Gap: users expect upgrades to preserve state or at least provide a guided migration.

**Improvements**
- Upgrade guide that explicitly lists when DB reset is required, how to back up, and how to confirm adapter selection.

---

## 5) Community Engagement Insights

### Power users (and what they need)
- **0xbbjoker:** high-leverage community support for debugging (plugin + DB). Needs: canonical troubleshooting docs to link instead of repeating steps.
- **Odilitime / core devs:** raising systemic concerns (storage, roadmap clarity). Needs: structured intake of technical risks and a prioritization loop visible to users.
- **DorianD:** repeatedly driving communication strategy improvements; wants clearer narrative artifacts.
- **ElBru:** shipping real-world moderation automation; needs plugin patterns, deployment guidance, and false-positive tuning playbooks.
- **Thirtieth:** building business agents (support, outreach); needs compliance + safety guardrails templates.

### Newcomer friction (common questions)
- “Which version works with Discord now?”
- “How do I integrate plugin X into Cloud?”
- “Do we have API keys / what’s supported?”
These indicate onboarding is not oriented around end-to-end goals.

### Converting passive users into contributors
- Create “Good First Issue” bundles that match observed needs:
  - docs: Polymarket → Cloud guide,
  - tooling: db doctor command,
  - safety: transaction policy spec draft.
- Recognize and formalize “Community Support Engineers” (like 0xbbjoker) with a lightweight role and a curated FAQ they can maintain.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord:** great for rapid debugging, but outcomes are brittle (critical fixes buried in chat; repeated questions).
- **GitHub issues/PRs:** strong for actionable engineering tasks (e.g., API 404 fixes, Python example fixes), but many user questions never become issues.

### Improvements for more structured, actionable feedback
1) **Add a “Help → Turn into issue” bot command in Discord**
- One command generates a prefilled GitHub issue with logs/version/env details.
2) **Introduce standardized templates**
- “Plugin integration help,” “Upgrade regression,” “DB migration,” “Cloud deployment.”
3) **Weekly triage digest**
- Post a short digest: top unanswered questions, newly created issues from Discord, resolved items.

### Underrepresented segments
- **Non-dev / semi-technical builders** trying to use Cloud + plugins (questions indicate they exist, but they’re not filing detailed issues).
- **Security/compliance-minded users** (Safe question surfaced once, but likely broader need as “agents that can transact” becomes common).

---

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

1) **Ship “DB Doctor + Adapter Selection Diagnostics”** (high impact, medium effort)  
Reduce startup blockers and prevent silent fallback to PGLite/local paths.

2) **Publish and enforce a Core↔Plugin Compatibility Matrix + startup warnings** (high impact, low–medium effort)  
Directly addresses recurring Discord plugin breakages and repeated “which version works?” questions.

3) **Create 3 task-based integration guides with runnable examples** (high impact, medium effort)  
Start with: (a) Polymarket → Cloud, (b) Support agent template, (c) Outreach agent with rate limits + opt-out + logging.

4) **Define and document an “Autonomous Transactions Safety Model” (Safe-ready)** (high impact, medium effort)  
Even a v0 policy spec + reference architecture will unblock serious builders and reduce risk.

5) **Consolidate expectation-setting pages (Airdrops/Token utility, Hosted projects status, Upgrade guide)** (medium–high impact, low effort)  
Cuts repeated community questions and improves trust via clear “known vs unknown” boundaries.