## User Feedback Analysis — 2026-03-26 (elizaOS)

### Data Sources Reviewed
- Discord summaries (2026-03-23 to 2026-03-25): 💬-discussion, 💬-coders
- Project context from latest available GitHub weekly summary (Feb 15–21, 2026) referenced in knowledge base (for comparative implementation examples)

---

## 1) Pain Point Categorization (Top recurring issues)

> Note: The dataset is Discord-heavy and skewed toward crypto/trading builders. Quantification is based on the small set of explicit questions and repeated themes.

### 1. Documentation — Unanswered “basic clarity” questions (High frequency, high severity)
**What users are experiencing**
- Token/platform confusion: “relationship between bas milady and sol milady.ai” and whether the Milady app supports both (explicitly asked, **unanswered**).
- Hackathon/workshop context mentioned but not linked as canonical onboarding steps (users told “watch the hackathon,” but no structured “do X, then Y” path).

**Evidence**
- Of the 3 FAQ-style questions captured on 2026-03-25, **2/3 (67%) were unanswered**, both being “clarity” questions (token/app support; “anyone built trading agents?”).

**Primary impact**
- Newcomers stall immediately; conversation drifts into speculation rather than building.

---

### 2. Community — Support routing & response reliability (High frequency, medium-high severity)
**What users are experiencing**
- Builders ask for feedback/collaboration (autonomous trading agents) and get partial direction (“join hackathon”) but limited concrete review, code pointers, or “who to ask.”
- Business/partnership inquiries reveal confusion about official representatives (Odilitime clarifying that a responder does not represent the project).

**Evidence**
- “Anyone here built any ai agents that are trading autonomously?” (unanswered).
- “Who should I contact to discuss collaboration with Eliza OS?” → clarification required about representation.

**Primary impact**
- Perception that support is ad-hoc; slows down serious adopters and external partners.

---

### 3. Technical Functionality — Lack of reference implementations for autonomous trading agents (Medium frequency, high severity)
**What users are experiencing**
- Multiple users are building trading agents (single-agent, multi-agent, NFT-personality agents), but they’re improvising architecture: memory layers, market data ingestion, safety controls, and evaluation.

**Evidence**
- Ape Ape | KairoGuard seeking setup feedback and collaboration.
- Naman building 24/7 multi-agent trading with a 200–500B local model (needs optimization/monitoring partner).
- sailorpepe.eth built a full stack (MemGPT-style memory + live market APIs + personality mapping) and is explicitly “seeking feedback,” implying lack of standard patterns.

**Primary impact**
- Repeated reinvention; higher risk of unsafe/fragile trading deployments.

---

### 4. Integration — Market data pipelines and oracle-based alternatives are fragmented (Medium frequency, medium severity)
**What users are experiencing**
- Two competing patterns emerge:
  1) Off-chain API pipelines (CoinGecko/DeFiLlama/DexScreener) injected into sessions
  2) On-chain verifiable indicator access (Pythia MCP using Chainlink on Polygon)
- Users need guidance on when to use which, plus standard interfaces/plugins.

**Evidence**
- Pythia MCP server release and offer to help integration.
- The Undesirables project builds an off-chain live market data pipeline.

**Primary impact**
- Integration choices are unclear; inconsistent tooling increases maintenance burden.

---

### 5. Security — Dependency supply-chain awareness but no visible “what to do now” (Lower frequency, high severity when it occurs)
**What users are experiencing**
- litellm-pypi supply chain attack was flagged, but there’s no visible follow-through playbook shared in the same channels.

**Evidence**
- DorianD raises the alert; acknowledgement follows.

**Primary impact**
- Builders may continue using compromised patterns; erodes trust if guidance isn’t centralized.

---

### 6. UX/UI — Onboarding experience is mostly “social,” not task-driven (Medium frequency, medium severity)
**What users are experiencing**
- General channel is dominated by intros/greetings; newcomers are told “build with elizaos” without a next step.
- Users looking for specific outcomes (trading agent examples, Milady app status) don’t get a clear path.

**Evidence**
- 2026-03-25 discussion channel described as primarily social with minimal technical problem-solving.

**Primary impact**
- High drop-off risk for new members who arrive ready to build.

---

### 7. Community/Moderation — Promotional/off-topic posts leak into builder spaces (Low frequency, medium severity)
**What users are experiencing**
- At least one “promotional investment solicitation” appears in coders context.

**Primary impact**
- Reduces signal-to-noise in technical channels and discourages serious contributors.

---

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

### Observed primary usage patterns (what people are actually building)
1) **Autonomous crypto trading agents** (dominant theme across 3/23–3/25)
   - Single-agent and multi-agent setups
   - 24/7 operations, high emphasis on market context ingestion and memory
2) **Agent “identity/personality as configuration”**
   - Deterministic personality generation from NFT traits (Big Five + “trading scores”)
   - Exportable workspaces (YAML frontmatter + character.json) aligned with ElizaOS V1 spec compatibility
3) **Market data retrieval as agent infrastructure**
   - On-chain indicators without API keys (Pythia MCP)
   - Off-chain aggregated APIs piped into sessions (CoinGecko/DeFiLlama/DexScreener)

### Mismatches vs intended/expected platform positioning
- elizaOS is presented as a general agent framework, but community demand is currently **finance/trading-first**; documentation and examples do not appear to match this concentration.
- Users treat Discord as primary support + product truth source, but key answers remain unresolved (tokens/app support, who to contact).

### Emerging / unexpected use cases to lean into
- **Mass “agent workspace minting”**: 4,444 pre-configured agent workspaces suggests demand for “agent templates at scale,” portable configs, and deterministic generation pipelines.
- **Oracle-native agent context**: verifiable on-chain indicators are being used as a way to avoid API keys and improve trust—this could become a first-class integration story.

### Feature requests implied by usage (even when not stated explicitly)
- A canonical **trading agent starter kit** (reference repo, risk controls, evaluation harness)
- A standard **market data provider interface** (pluggable sources: off-chain APIs, on-chain oracles)
- Better **workspace packaging/export/import** workflows (since users are shipping downloadable workspaces)

---

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

### A) Fix “basic clarity” documentation gaps (Tokens/Milady app support; hackathon path)
**High impact / Low–Medium difficulty**
1) Publish a single pinned “Milady app + tokens” FAQ in Discord + docs site:
   - “What tokens exist, which are supported, what is not supported, and why”
   - Include a “last updated” timestamp and ownership (who maintains it)
2) Add an “Official links & contacts” page (Discord pinned + website/docs):
   - Who represents elizaOS for partnerships
   - Where to file integration requests (GitHub Discussions vs Discord)
3) Create a “Hackathon/Builders Challenge quickstart” checklist:
   - Install → run sample agent → add one integration → submit
   - Link to workshops (March 26 / April 2 mentioned)

**Comparable patterns in similar projects**
- Kubernetes/CNCF-style “Getting Started” + “FAQ” pages that answer the top 10 recurring questions and are aggressively kept current.
- LangChain’s approach: multiple “cookbooks” plus a central “Integrations” index.

---

### B) Improve support routing and response reliability in Discord
**High impact / Medium difficulty**
1) Add a triage workflow for unanswered questions:
   - A weekly “Unanswered Questions” thread
   - Lightweight tagging: `#trading`, `#integrations`, `#security`, `#milady-app`
2) Create role-based office hours:
   - “Trading agents clinic” (weekly)
   - “Integrations clinic” (MCP/oracles/plugins)
3) Convert high-signal answers into durable artifacts:
   - When Denis/Ivan answer something, auto-promote to a “knowledge base” channel or GitHub Discussions summary

**Comparable patterns**
- Rust / Next.js communities use scheduled office hours and structured Q&A threads to prevent Discord from becoming an unsearchable support sink.

---

### C) Ship a canonical autonomous trading agent reference implementation
**High impact / Medium–High difficulty**
1) Provide a “trading agent starter kit” repository:
   - Paper trading mode by default
   - Risk controls: position sizing, max drawdown stop, rate limits
   - Evaluation harness: backtesting hooks + replay logs
2) Standardize memory & telemetry patterns:
   - Recommended memory tiers (short-term / long-term / episodic) with clear APIs
   - Built-in metrics: decision latency, error rates, PnL attribution (even for paper trading)
3) Add safety guidance explicitly:
   - Threat model (prompt injection via market data, compromised plugins, key leakage)
   - Secure key handling recommendations

**Comparable patterns**
- “Reference architecture” repos common in Terraform/AWS CDK ecosystems; reduces repeated reinvention.
- Trading bot communities (e.g., Freqtrade-style projects) succeed by making paper trading + backtesting first-class, not optional.

---

### D) Unify market data integrations (off-chain APIs vs on-chain oracles)
**Medium–High impact / Medium difficulty**
1) Define a MarketDataProvider interface in elizaOS plugin ecosystem:
   - Common outputs: price, volume, OHLCV, indicators, confidence/source
2) Provide two maintained implementations:
   - Off-chain aggregator provider (CoinGecko/DeFiLlama/DexScreener)
   - On-chain oracle provider (Pythia MCP / Chainlink)
3) Add a “when to use which” guide:
   - Off-chain: broader coverage, faster iteration, but trust/API dependency
   - On-chain: verifiable, fewer assets/timeframes, chain-specific constraints

**Comparable patterns**
- OpenTelemetry’s “common data model” approach: many backends, one interface.

---

### E) Turn security alerts into a standard response playbook
**High impact / Medium difficulty**
1) Publish a “Dependency incident response” checklist:
   - How to check if affected, how to rotate keys, how to pin versions
2) Add automated dependency scanning guidance for plugin authors:
   - Recommend Renovate/Dependabot policies and lockfile hygiene
3) Create a security advisories channel + monthly roundup:
   - Summarize incidents like litellm-pypi and what action is required

**Comparable patterns**
- npm/PyPI ecosystems rely on quick advisory posts + pinned mitigation steps; projects that centralize this reduce panic and rumor spread.

---

## 4) Communication Gaps (Expectations vs reality)

### Gap 1: “Is this supported?” (tokens/app) vs silence
- Users asked whether the Milady app supports both base and SOL milady.ai tokens; no answer was captured.
- This creates speculation and “bad news” hints rather than clarity.

**Fix**
- Maintain an explicit support matrix (Supported / Not supported / Planned / Unknown).

### Gap 2: “Where do I get help?” vs “ask in Discord”
- Builders want architectural feedback (trading agents) but only get directional advice (hackathon).
- Partnership inquiries required clarification about official representation.

**Fix**
- Publish official support routes and escalation paths (Discord → GitHub Discussion → issue → maintainer office hours).

### Gap 3: “Security alert acknowledged” vs “what should builders do now?”
- The supply-chain alert was recognized but not followed by steps.

**Fix**
- Always pair alerts with a mitigation snippet and link to a living security page.

---

## 5) Community Engagement Insights

### Power users / high-leverage contributors observed
- **Denis**: organizes Builders’ Challenge, offers support, routes builders to workshops.
  - Need: tooling to capture workshop outcomes into docs; structured intake for stuck participants.
- **Ivan Jeremic**: shipped Pythia MCP server + offers integration help.
  - Need: a clear plugin/integration pathway and a standard provider interface so adoption scales.
- **sailorpepe.eth**: advanced implementation (V1 spec compatibility, memory tiers, live data pipeline, large-scale workspaces).
  - Need: design review channel, reference architecture alignment, and distribution via official registry/templates.
- **Odilitime**: provides Milady app dev status; clarifies official representation.
  - Need: centralized announcements + a single source of truth to reduce repeated questions.
- **satsbased**: onboarding greeter.
  - Need: a scripted onboarding flow (what to do in first 30 minutes) to convert greetings into builds.

### Common newcomer questions indicating onboarding friction
- “Anyone built autonomous trading agents?” (seeking examples/community validation)
- “Does the app support X token?” (seeking official product clarity)
- “When will the app be online?” (release expectation management; appears repeatedly in recent days)

### Converting passive users into contributors
1) Add “Good First Contribution” lists tied to what users are building now:
   - Market data provider interface tasks
   - Trading agent starter kit issues (docs, tests, connectors)
2) Host “Show & Tell” threads for agent setups:
   - Require a short template: goal, architecture, plugins used, issues encountered
3) Reward documentation contributions:
   - Visibility in release notes/Discord roles for people who convert repeated Qs into docs

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- Discord captures energy and early ideas, but feedback is **unstructured** and **answers are not durable**.
- Key product questions go unanswered, indicating weak triage and ownership.

### Improvements for more structured, actionable feedback
1) Add a pinned “Feedback intake” form (or GitHub Discussion template) with required fields:
   - Goal, environment, plugins, logs, expected vs actual, severity
2) Weekly digest process:
   - Summarize top questions + decisions + known issues
   - Post back into Discord and archive in GitHub Discussions
3) Channel hygiene:
   - Route investment/promotional content away from coders
   - Add moderation triggers for solicitation posts

### Underrepresented segments (missing voices)
- Non-crypto builders (productivity, customer support, knowledge agents) are not visible in this slice.
- Teams deploying agents in production (ops, compliance, enterprise security) are not represented.
- UX/UI feedback about actual product surfaces (dashboard, onboarding flows) is absent—likely because users are stuck at “where do I start” or building custom stacks.

---

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

1) **Publish and pin an “Official: Milady app + tokens + support matrix” FAQ** (Docs + Discord), with an owner and update cadence.  
2) **Launch a canonical “Autonomous Trading Agent Starter Kit”** (paper trading by default, risk controls, evaluation harness) to match dominant community usage.  
3) **Create a MarketDataProvider standard + two reference integrations** (off-chain APIs + on-chain oracle/Pythia MCP), plus a selection guide.  
4) **Implement Discord support triage**: unanswered-questions weekly thread, tagging, and scheduled “Trading agents clinic / Integrations clinic” office hours.  
5) **Add a security response playbook** for dependency incidents (like litellm-pypi) and standardize alert→mitigation communication.