# ElizaOS Weekly Newsletter (2026-01-28) **Week of 2026-01-22 to 2026-01-28** ## 1) Executive Summary **1. Eliza V2 momentum + “workflow-first” pivot is now explicit.** Core devs aligned around building *Eliza as an AI agent app* that can automate real work, with **n8n as the primary workflow backbone** (instead of hand-building integrations for every service). Eliza **v2.0.0 is available for testing via npm** as `@elizaos/core@next`, and the team is rallying around natural-language workflow creation. **2. Major clarity on Knowledge plugin cost blowups (and a practical fix).** Community debugging identified why the Knowledge plugin could become unexpectedly expensive: **contextual embeddings** (`CTX_KNOWLEDGE_ENABLED=true`) can dramatically increase token usage. A minimal config path was shared to bring costs back down—even for large documents. **3. Ecosystem focus: multi-product strategy + holder reward narrative.** The team reiterated a parallel product strategy (Babylon, Hyperscape, Cloud, OTC desk, Eliza Anime), with the intent to **reward long-term ElizaOS holders via airdrops** when products hit traction. Babylon airdrop intent is confirmed “in principle,” but details are still pending. --- ## 2) Development Updates (Technical) ### Eliza V2 + n8n workflow automation (core-devs) The biggest technical direction this week: **adopt n8n’s plugin architecture** as the main path to “connect everything” workflows. **Proposed 3-layer architecture** - **Layer 3:** AI Workflow Generator (NL → workflow plan) - **Layer 2:** Workflow Engine (TaskService/cron execution + reliability) - **Layer 1:** OAuth Gateway (multi-tenant credentials, secure by design) **Implementation strategy (pragmatic)** - Build a library of *pre-fab workflows* (Gmail triage, calendar scheduling, Notion updates, Linear ticketing, etc.) - Use strong models (developers voiced preference for **Opus 4.5**) to generate “closest match” workflows - Mark generated workflows as **experimental**, debug with users, then promote into the library **How to try V2** - `npm install @elizaos/core@next` (shared by core devs for early testing) - V2 includes **computer use** and **browser use** capabilities built from working open-source patterns ### Knowledge plugin: config correctness + cost control (💬-coders) Two issues came up repeatedly, and both now have clear fixes: 1) **Validation error:** `EMBEDDING_PROVIDER` receiving `openrouter` - The enum currently expects **`openai` or `google`**, so set embedding provider accordingly. (OpenRouter can still be used in other parts of the stack, but not as this enum value.) 2) **High per-query costs:** $0.03–0.04 for tiny docs - Root cause: **contextual embeddings enabled** via `CTX_KNOWLEDGE_ENABLED=true` - Suggested approach: disable contextual embeddings for most use cases, and use a small embedding model (example shared: `openai/text-embedding-3-small`) to keep ingestion/query costs predictable. ### Plugin callbacks (v1.7.2 behavior investigation) A developer reported that plugin action handler callbacks seemed to only send the first response. Core feedback indicated **multiple callbacks are supported**, and troubleshooting focused on planner configuration (e.g., onestep vs multistep). If you rely on progressive callbacks, keep an eye out for follow-up guidance and doc clarifications. ### MCP integration via Eliza Cloud API (builders + red teamers) Workflows aren’t only n8n: community members also explored connecting **external MCP servers** to Eliza Cloud agents. The key detail shared: - Register external MCP servers via **`POST /api/v1/mcps`**, allowing Eliza Cloud to proxy calls for agent reasoning/task execution. --- ## 3) Community Spotlight (Discord) **Community debugging wins** - **DigitalDiva** helped resolve the Knowledge plugin enum error by pinpointing the incorrect `EMBEDDING_PROVIDER` setting. - **0xbbjoker** broke down why contextual embeddings spike costs and provided a minimal config example, including a real-world benchmark (multi-megabyte PDF ingestion with hundreds of chunks at reasonable cost). **Security awareness: scam ticket bot** - A “Create A Ticket” bot reportedly asked users for wallet addresses and pushed suspicious links. Team members confirmed this was a **scam**. Reminder: never share wallet details with unofficial support bots; use official channels and verify links. **Builders’ corner** - Interest is growing in **self-hosting** (mini-PC setups, Oracle Cloud free tier guides, etc.), suggesting more community members are experimenting beyond basic local runs. **Big-picture product discussions** - Users asked hard questions about adoption (“why aren’t there more single-purpose agents?”), and the team’s response is effectively: remove friction by making **workflow creation conversational**, not code-heavy. --- ## 4) Token Economics (AI16z / ElizaOS / auto.fun) **Babylon airdrop (planned, details pending)** - Team intent: **airdrop Babylon to ElizaOS holders**, with active consideration for **rewarding long-term holders** specifically. - Community questions remain open (DEX trading eligibility, exchange custody questions, snapshot rules). Official details have not been published yet—avoid acting on rumors. **AI16z → ElizaOS migration support signals** - Migration questions continue to surface (hardware wallets, portal mismatches, deadlines). Community guidance consistently routes users to formal ticketing/support channels for account-specific fixes. **Market sentiment** - Token price concerns were prominent, but community voices emphasized the “builder thesis”: execution and product-market fit first, token narrative follows. **auto.fun** - No concrete shipping updates were shared in the captured discussions this week. Community interest remains high, so expect future announcements to focus on clearer mechanics, eligibility rules, and how auto.fun ties into the broader multi-product strategy. --- ## 5) Coming Soon **Near-term product funnel goal (end-of-week focus):** - **Landing page → poke integration → agent conversation** - Personality target: “**funny, spunky, and spicy**” (but not mean) **In progress (parallel tracks)** - **SMS/iMessage plugins + Cloud runtime integration** (for chat-native agent experiences) - **Mail/Calendar plugins** + **n8n plugin with OAuth** (credentialed workflows) - **plugin-pim** (entity/component architecture + memories) **Expected next decisions** - Credential passing model between existing Eliza plugins (e.g., Gmail) and n8n workflows - How “workflow validation” works (credential requirements, safe execution, review loop) --- ## 6) Resources (Links & References) - **Eliza V2 Python + examples fixes (merged):** PR #6358 https://github.com/elizaos/eliza/pull/6358 - **CLI create bug report (closed):** Issue #6388 https://github.com/elizaos/eliza/issues/6388 - **CLI import fix (merged):** PR #6389 https://github.com/elizaos/eliza/pull/6389 - **Dynamic execution engine for V2 (open):** PR #6384 https://github.com/elizaos/eliza/pull/6384 - **Discord discussions (high signal):** - Knowledge plugin debugging (💬-coders): https://discord.com/channels/1253563208833433701/1300025221834739744 - Core workflow strategy (core-devs): https://discord.com/channels/1253563208833433701/1377726087789940836 - Babylon / airdrop questions (💬-discussion): https://discord.com/channels/1253563208833433701/1253563209462448241 --- If you’re building this week: try `@elizaos/core@next`, experiment with one pre-fab n8n-style workflow, and share where the UX breaks—those early pain points are exactly what the team is optimizing for.