# ElizaOS Weekly Newsletter (2025-12-29 → 2026-01-04) ## 1) Executive Summary This week was about **speed, stability, and setting up the next wave of “public agents”**: - **Multi-step agents got faster**: The core message service now runs provider work in parallel (instead of sequentially), improving responsiveness for agents that rely on multiple providers in one turn. This landed via **PR #6263**. - **A critical database isolation fix is in flight**: A targeted fix for `plugin-sql` addresses a PostgreSQL limitation around `SET LOCAL` statements that can break DB operations when `ENABLE_DATA_ISOLATION=true`. The fix is proposed in **PR #6316** and comes with strong unit + integration tests. - **Roadmapping accelerated for public agent UX**: A cluster of new issues laid out clearer states for public-agent interactions, guest message limits, and better agent cards—big signals that the **agent discovery + sharing** layer is becoming a near-term focus. --- ## 2) Development Updates (Core + Plugins) ### Core platform: performance and reliability - **Parallel provider execution in multi-step runs (merged)** In `default-message-service`, providers in multi-step mode now execute via `Promise.allSettled`, which improves throughput when an agent needs multiple data fetches at once (and keeps fault tolerance). *Impact:* faster multi-provider turns; fewer “long tail” waits when one provider is slow. Reference: **elizaos/eliza PR #6263**. - **Ongoing: SQL data isolation bug fix (opened)** PostgreSQL `SET` commands don’t accept parameterized queries. The proposed fix swaps parameterized `sql\`...\`` usage for `sql.raw()` with inline values for `SET LOCAL app.entity_id = ...`. *Why it matters:* When `ENABLE_DATA_ISOLATION=true`, this can break DB operations entirely. The PR includes both unit tests (for `withEntityContext`) and an integration test against a real Postgres instance. Reference: **elizaos/eliza PR #6316**. - **Maintenance** License year was updated to 2026 (routine, but appreciated). Reference: **elizaos/eliza PR #6301**. ### Product/UX direction: public agents and chat ergonomics (issues opened) A number of issues were created that collectively point toward a more polished “public agent” experience: - Clear **public agent UI states** based on authentication/ownership (unauthenticated visitor vs authenticated non-owner vs owner). Reference: **Issue #6313**. - **Guest message limits** (2–3 messages) before prompting sign-up. Reference: **Issue #6312**. - Better **public agent cards** (e.g., displaying total chat/message counts). Reference: **Issue #6314**. - Ongoing quality-of-life concerns like chat summary usefulness and conversation lifecycle quirks. Reference: **Issue #6311** (summaries), plus additional UX issues opened this week. ### Plugins: security and media handling (in progress, from late-week recap) While not all of this merged during the window, work continued in key ecosystem plugins: - **Twitter plugin security upgrade**: OAuth2 PKCE work is underway to improve auth security and simplify configuration. Reference: **elizaos-plugins/plugin-twitter PR #46**. - **OpenAI plugin media improvements**: work started to improve image description handling and introduce caching for audio/images. Reference: **elizaos-plugins/plugin-openai PR #23**. --- ## 3) Community Spotlight (Discord) ### “How does ElizaOS work?” — crisp explanation for newcomers A new user asked what ElizaOS actually *is*, and the community delivered a strong, accessible explanation: **create an agent**, equip it with **specific knowledge/data**, attach **multiple model providers**, and extend it via **plugins** (X/Discord/Telegram and even real-world device integrations). This kind of onboarding clarity is crucial as we push toward public agent discovery. ### RoseOS framework: autonomy engineering, not hype A community member shared **RoseOS**, a framework built on top of ElizaOS emphasizing: - explicit agency boundaries, - constraint-aware reasoning, - accountability layers, - treating autonomy like an engineering discipline (control surfaces, decision limits, predictability). The discussion was notable because it connected ElizaOS primitives to a more formal “autonomous systems” design philosophy—useful for anyone building agents that need *guardrails* and *auditable behavior*. ### Multi-model agents: practical guidance There was a focused thread on running **multiple LLMs in a single agent** (e.g., Anthropic for certain tasks and OpenAI for others). The recommended approach: use the **OpenRouter plugin** and set provider/model choices via environment configuration. ### Real talk: Solana trading requirements A deep technical exchange outlined what’s needed for profitable on-chain trading automation on Solana: - GRPC ingesters with millisecond precision, - “full payload preshoting” systems, - avoiding slow paths like SDK/Jupiter routes that can add multi-second delays, - monitoring token creation via live Twitter feeds + automated bundlers. Even if you’re not building a trading agent, this discussion was a great reminder: **latency budgets define architecture**. ### Pain point surfaced: Turbo build memory spikes Multiple messages flagged Turbo builds consuming extreme memory (21GB+). It’s now a clear action item to investigate—especially important for contributors on constrained dev machines/CI. --- ## 4) Token Economics (AI16z + auto.fun) No official protocol-level changes were documented in the provided activity this week, but a few ecosystem signals came up: - Community chatter continued around **token price movement** and short-term trading behavior (as usual during volatile periods). - On the product side, the direction of travel is consistent with long-term token utility: **more public agents, easier sharing/forking, and clearer onboarding** tends to increase usage and ecosystem stickiness—often the prerequisite for sustainable token mechanics. If you’re tracking AI16z and auto.fun closely, treat Discord price talk as sentiment only and rely on **official announcements** for anything supply, emissions, incentives, or fee-related. --- ## 5) Coming Soon (What to Watch) Based on issues and active work, here’s what looks “next up”: - **Public agent experience overhaul**: distinct UI states (guest vs signed-in vs owner), lightweight viral sharing, and sign-up gating after a short guest trial. - **Public agent discovery + forking**: the roadmap momentum suggests more visibility into agents, better metadata/cards, and streamlined cloning of existing agents. - **More reliable data isolation workflows**: once the SQL fix lands, expect fewer “mysterious DB failures” in isolated/multi-tenant setups. - **Plugin hardening**: OAuth2 PKCE in Twitter plugin and improved OpenAI media caching both point toward better security and performance for real production agents. - **Build performance fixes**: investigation into Turbo memory consumption is likely to become a priority if it impacts CI and contributor productivity. --- ## 6) Resources (Links & References) ### Pull Requests - Parallel provider execution (merged): https://github.com/elizaos/eliza/pull/6263 - SQL isolation fix (`SET LOCAL` via `sql.raw()`) (opened): https://github.com/elizaos/eliza/pull/6316 - License year update (merged): https://github.com/elizaos/eliza/pull/6301 - Twitter OAuth2 PKCE (in progress): https://github.com/elizaos-plugins/plugin-twitter/pull/46 - OpenAI plugin media caching work (in progress): https://github.com/elizaos-plugins/plugin-openai/pull/23 ### Key Issues (Product/UX direction) - Separate public agent states: https://github.com/elizaos/eliza/issues/6313 - Limit guest messages (~2–3): https://github.com/elizaos/eliza/issues/6312 - Public agent cards: show chat number: https://github.com/elizaos/eliza/issues/6314 - Improve chat summaries: https://github.com/elizaos/eliza/issues/6311 ### Discord highlight themes to revisit - RoseOS autonomy engineering discussion (Jan 3) - Solana trading latency requirements + GRPC ingestion (Jan 4) - Turbo build memory usage investigation (Jan 4)