## Weekly Newsletter (2026-04-27) — ElizaOS **Week of 2026-04-20 to 2026-04-26** ### 1) Executive Summary This week was all about turning “agents as demos” into “agents as products” — while making the framework safer and more production-ready. - **Eliza v3 is nearly ready, with the app close behind.** Shaw shared that **v3 is approaching release**, the **application is in its final stages**, and **Eliza Cloud is already onboarding business clients** that the app can plug into directly. This is a big signal that the ecosystem is moving from core tooling toward a complete user-facing product loop (framework → app → cloud → revenue). - **Automation + workflow reliability took a big leap forward.** The team shipped a set of hardening changes around workflow deployment (including a new *validate-and-repair* step with anti-hallucination defenses), better runtime context injection, improved trigger dispatching, and a more informative multi-stage progress UI. - **Token utility conversations converged around “no-friction payments + buybacks,” plus a concrete “dual-fee currency” proposal.** The community debated how to add token value without forcing users into awkward flows — with a clear preference emerging: let users pay however they want, then route revenue into token buybacks. --- ### 2) Development Updates (Technical Highlights) Here are the most notable engineering changes and fixes discussed or reported this week: **Workflow & Automation Hardening** - Added a **`validateAndRepair` pre-deploy pass** designed to reduce workflow mistakes before deployment, including **anti-hallucination defenses** and **deterministic credential injection**. In practice, this aims to prevent “LLM guessed the wrong config” situations and make automation deployments more predictable. - Improved prompt and runtime state quality via **`RuntimeContextProvider` extensions**, helping with **prompt engineering and keyword extraction** — a small-sounding change that usually pays off quickly in more stable tool selection and cleaner outputs. **Triggers & Event Pipeline** - The runtime **event → handler** wiring was strengthened by connecting runtime events to trigger handlers. - **Telegram `MESSAGE_RECEIVED` triggers were enabled**, unblocking event-kind triggers that register correctly but previously didn’t fire (a classic “it configured fine, but nothing happens” failure mode). **User Experience & State Management** - Shipped a **new 6-stage progress UI** for workflow generation, giving users clearer feedback during the 10–30 second “workflow building” window. - Implemented **automatic cleanup of workflow chat rooms** when workflows are removed, reducing stale rooms and confusion in the UI. **Infra & Performance** - Expanded **native desktop application support** (ongoing work toward a first-class desktop experience). - Increased streaming chat generation timeouts from **90s → 180s**, which is critical for heavier structured-output or tool-using flows that legitimately take longer. **In Review / Pending** - **Multi-chain agent-to-agent payments** integration spanning **7 chains** (awaiting review). - **Monetization features** for debiting **organizational credit balances** (awaiting review). - A **rebuilt auth consent flow** (awaiting review). - An open integration task tracking **29 commits** from `shaw/checkpoint-20260426-eliza`. --- ### 3) Community Spotlight (Discord) A few standout community moments this week captured where ElizaOS is heading: agent commerce, planning architectures, and token design that doesn’t punish the user. **Agent Monetization Demo: @elisym/plugin-elizaos-elisym** Community member **igor.peregudov** showcased a plugin that effectively turns agents into paid service providers: - **Discovery layer:** capabilities announced via **Nostr** - **Settlement layer:** payments on **Solana** (demoed on devnet) - **Flow demonstrated:** an agent publishes capabilities → receives a paid request → settles payment → delivers the result This is one of the clearest “agent-to-agent marketplace” demos we’ve seen in the community, and it aligns directly with the broader push toward monetization infrastructure. **Token Utility Design Discussion (Practical > Forced)** - **shawmakesmagic** reiterated a strong product-first stance: *accept any payment method users already have*, then use revenue to **buy back tokens**, avoiding UX friction from forcing token-only flows. - **quanteliza** proposed a v3-oriented model: allow protocol fees in **USDC or ELIZAOS**, give **discounts** for paying in ELIZAOS, and apply **buyback-and-burn** when fees are paid in USDC (a “BNB-style” early tokenomics pattern). - **odilitime** responded positively, noting it motivated him to finish earlier work enabling plugins to accept **$elizaOS and $DegenAI via x402 payments** as a “lowest-hanging fruit” implementation path. **Deep Technical Thread: HTN Planning in ElizaOS** In the coders channel, **thirti.eth** led a discussion on **HTN (Hierarchical Task Networks)** — what it is, why it matters, and how ElizaOS could evolve from “HTN-lite” toward fuller LLM-based planning over time. The thread also included a helpful clarification distinguishing **HTN (planning)** from **HTM (memory)** so people don’t conflate the concepts. **Small but Important: Broken Link Report** A community member flagged that the **Milady Play Store link** referenced from GitHub was returning an “item not available” error. It’s a good example of the community helping keep public-facing surfaces clean. --- ### 4) Token Economics (AI16z Token & auto.fun) No formal on-chain parameter changes were announced in the provided updates for **AI16z** or **auto.fun** this week, but the **direction of travel** became clearer through community discussion: - **Primary strategy emphasized:** minimize user friction by **accepting whatever users can pay with**, then convert revenue into **token buybacks** (Shaw’s position). - **Proposed protocol-fee model (community):** dual-currency fees (**USDC or ELIZAOS**) with **discounts** for ELIZAOS payments and **buyback/burn** on USDC payments (quanteliza’s proposal). - **Implementation path hinted:** expanding **x402 payment support** so plugins can accept ELIZAOS / DegenAI in standardized paid routes (odilitime). Takeaway: the token conversation is shifting from abstract “utility” to concrete fee-routing mechanics that can ship without breaking onboarding. --- ### 5) Coming Soon Here’s what to watch for next: - **Eliza v3 release** (nearing completion) and the **near-finish app launch**, with Eliza Cloud already onboarding business customers. - **DegenAI updates** were confirmed as “imminent.” - **Multi-chain A2A payments (7 chains)** moving from review to merge — potentially a major unlock for agent commerce. - **Auth consent flow rebuild** and **org-credit monetization** features once review completes. - Fixing the **Milady Play Store** repository link and auditing any similar public-facing docs/resources for drift. --- ### 6) Resources (Links & References) **Discord discussions** - Token utility + v3/app/cloud updates (Apr 26): https://discord.com/channels/1253563208833433701/1253563209462448241 - HTN vs HTM clarification (coders, Apr 26): https://discord.com/channels/1253563208833433701/1300025221834739744 **Key PRs / change areas referenced in this week’s dev summary** - Event-kind triggers bridged to runtime event bus: `elizaos/eliza` **#7116** - Telegram `MESSAGE_RECEIVED` trigger support: `elizaos/eliza` **#7122** - Workflow generation **6-stage progress UI**: `elizaos/eliza` **#7127** - Workflow chat-room cleanup on deletion: `elizaos/eliza` **#7121** - Streaming timeout increased to **180s**: `elizaos/eliza` **#7117** If you’re building this week: keep an eye on the pending reviews (multi-chain payments, org credit debiting, consent flow), and consider testing the trigger pipeline if you rely on Telegram or other event-kind trigger sources.