# ElizaOS Developer Update (2026-02-01 → 2026-02-05)

## 1) Core Framework

### Autonomous mode is now a first-class runtime capability (no longer “just a plugin”)
Core runtime behavior is trending toward *always-on autonomy*. In current internal guidance, autonomous mode is enabled directly at runtime construction time:

```ts
import { AgentRuntime } from "@elizaos/core";

const agentRuntime = new AgentRuntime({ autonomous: true });
```

This shift matters because it changes the “default mental model” for agent execution: scheduled work (cron/heartbeats), background loops, and proactive tasking are expected to be available without extra plugin wiring. Discussion emphasized that ElizaOS has long supported cron jobs + autonomous behaviors, but adoption has lagged due to packaging/presentation rather than missing primitives.

**Context:** Discord discussions comparing ElizaOS vs OpenClaw converged on the idea that both ecosystems are moving toward autonomy-by-default, but ElizaOS is positioning this for business-grade workflows rather than “personal assistant loops.”  
Refs: Discord threads (core-devs / coders) summarized in daily report:  
- https://discord.com/channels/1253563208833433701/1377726087789940836  
- https://discord.com/channels/1253563208833433701/1300025221834739744

### “Dynamic providers” vs `skill.md` are equivalent concepts (typed providers preferred)
A recurring point of confusion was cleared up: **dynamic providers and `skill.md` are functionally the same abstraction**, but providers in ElizaOS are **well-typed**, which is important for tool invocation correctness and safer composition.

This clarification is relevant for developers porting skills from other ecosystems (e.g., clawhub/OpenClaw) into Eliza’s provider/skill pipeline.  
Ref: core-devs Q&A (Stan ⚡): https://discord.com/channels/1253563208833433701/1377726087789940836

### cskill plugin direction (absorbing OpenClaw-style skills)
Work is ongoing to make ElizaOS “skill ingestion” compatible with OpenClaw-like ecosystems via a **cskill plugin** approach. This is framed as a compatibility layer that preserves Eliza’s stronger project-building/runtime model while importing the best UX/loop ideas.

**Security note:** discussion flagged malicious skills in clawhub-style distribution. Proposed mitigations include:
- “scanner skills” for static checks
- an automated rewrite/adaptation phase for Eliza compatibility
- LLM-based skill review
- possible sandboxing for execution isolation  
Ref: Discord (coders): https://discord.com/channels/1253563208833433701/1300025221834739744 and Feb 3 summary.

---

## 2) New Features

### OAuth integrations landing in Eliza app chat (X/GitHub/Slack/Linear done; Notion next)
OAuth support is being rolled out across major providers. Completed integrations reported this week:
- **X (Twitter / x.com)**
- **GitHub**
- **Slack**
- **Linear**

Notion is next, and **MCP testing is explicitly queued after OAuth stabilizes across adapters**.

Key implementation insight from the team: the internal OAuth architecture makes adding new providers straightforward; the main overhead is operational (credentials + redirect URIs per provider).  
Ref: core-devs channel summary: https://discord.com/channels/1253563208833433701/1377726087789940836

**Developer takeaway:** if you’re building a plugin that needs delegated access, align your callback handling and token storage with the app-chat OAuth adapter pattern so MCP/Composio-style interop is a drop-in later.

### Reliable skill invocation pattern (prompt-hook enforced activation sequence)
A major reliability issue surfaced: in internal evals, **skills were not triggered in ~56% of cases** even when agents had docs and access.

A working mitigation was shared: enforce a **mandatory 3-step “consider → activate → implement” sequence** in a `UserPromptSubmit` hook so the model must explicitly decide and then call tools *before* it begins free-form implementation.

```ts
// Pseudocode sketch of the pattern discussed
app.hooks.onUserPromptSubmit(async (ctx) => {
  // 1) Force explicit evaluation of each skill (YES/NO + reasoning)
  ctx.system.add(`
For EACH available skill:
- Decide YES/NO whether it is relevant
- Give 1 sentence reasoning
Then:
- Immediately call the Skill(...) tool for each YES
Only after tool calls, continue with implementation.
`);

  return ctx;
});
```

Stan noted a similar pattern is already being used in Eliza Cloud. This aligns with observed patterns in Composio/Zapier-style tool routers, but it can make conversations feel “procedural.” The tradeoff is significantly improved tool/skill activation reliability.  
Ref: Feb 2 discussion summary.

---

## 3) Bug Fixes (critical / high-impact)

### Babylon.market internal testing blockers (auth + infinite loading)
Internal launch testing surfaced multiple blocking issues:
- **Farcaster login failures**
- **infinite loading spinners** when switching networks / checking waitlist position
- waitlist rank not loading reliably

While not strictly core-framework bugs, these are high-impact integration issues for any agent-driven growth loops or onchain-connected UX that depends on reliable auth/session establishment. Tracking/triage is ongoing.  
Refs: core-devs thread: https://discord.com/channels/1253563208833433701/1377726087789940836

### ElizaCloud account duplication risk (email aliasing)
A critical account/access issue was reported: using different Proton email formats (`@proton.me` vs `@protonmail.com`) can create **duplicate accounts**, causing an agent to “disappear” from the dashboard. This is likely an identity canonicalization bug in account linking.  
Ref: Feb 2 summary (ElizaCloud.ai Account Management).

---

## 4) API Changes

### Agent runtime construction: autonomy as configuration (not plugin wiring)
If you previously enabled autonomous behaviors via a dedicated plugin or optional module, the updated guidance is to enable it directly in `AgentRuntime` configuration:

```ts
const agentRuntime = new AgentRuntime({ autonomous: true });
```

**Impact:** plugin authors should assume background scheduling/heartbeats may be enabled by default and ensure their tools/skills are idempotent and safe under repeated autonomous invocation.

### MCP tool surface: dynamic tool actions (recent plugin-mcp work)
Recent work in `elizaos-plugins/plugin-mcp` introduced **dynamic MCP tool actions** (tagged as a `feat!` release). If you depend on older static action mappings, confirm compatibility before upgrading.  
Ref (historical but relevant to current MCP push): PR “feat!: Dynamic MCP tool actions (v1.8.0) #22” (mentioned in activity summary).

---

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)

### X (Twitter) via OAuth
X.com OAuth is now integrated into Eliza app chat (see OAuth section). This is the foundation for secure posting, account linking, and later brokered/enterprise auth modes.

### Telegram
Telegram remains a key channel for “Moltbot-style” deployments (Claude-like skill standard + Telegram transport + autonomous mode). If you are building Telegram agents, align skills to the **agentskills.io** standard to maximize portability.  
Ref: coders discussion (Moltbot is “Claude code + Telegram + autonomous mode”).

### Farcaster
Farcaster issues are currently surfacing primarily through Babylon.market auth flows (login failures). If you maintain Farcaster-related plugins or OAuth adapters, prioritize:
- better error visibility (provider error codes surfaced to UI)
- robust callback state handling
- network switching/session refresh correctness  
Ref: Babylon.market internal testing thread: https://discord.com/channels/1253563208833433701/1377726087789940836

---

## 6) Model Provider Updates (OpenAI / Anthropic / DeepSeek / etc.)

### Skill standard compatibility: Claude skills == Moltbot skills
The team confirmed Moltbot skills follow the same open standard as Claude skills via **https://agentskills.io**. This is relevant for model/provider routing because it implies skill packaging can remain model-agnostic while execution policies (autonomy, scheduling, safety) stay framework-specific.

### Ongoing model evaluation pressure: “Sonnet” mentioned for cost/quality tradeoffs
Issue tracking in `elizaos/eliza` indicates active consideration of switching/testing Eliza character prompting against Anthropic Sonnet variants due to price/quality differences.  
Ref: Issue “[Agent] Eliza Character File & Prompt Engineering” https://github.com/elizaos/eliza/issues/6447

---

## 7) Breaking Changes / Migration Warnings (V1 → V2)

### V2: agent skills become native (and autonomy is assumed)
Shaw’s stated direction for “2.0” includes **native agent skills** (not bolted on), and the runtime is moving toward **autonomous-by-default** operation. Expect migration friction in these areas:

- **Initialization paths:** code that assumed “manual mode” may now see background tasks firing (cron/heartbeats).
- **Skill/tool invocation expectations:** you may need to adopt stricter activation prompting (see the `UserPromptSubmit` hook pattern) or improve skill descriptions to maintain reliability.
- **Provider typing:** if you depended on loose `skill.md`-style parsing, migrating to typed providers may require schema cleanup.

### Ecosystem migration (token): ai16z → elizaOS window closed (operational breaking change)
While not a code-level API break, it *is* a breaking operational change for integrators building token-gated features:
- the migration window was a hard 3-month deadline
- bridging off Solana is **optional**
- post-snapshot purchases won’t be auto-migrated  
Ref: partners/discussion summaries:  
- https://discord.com/channels/1253563208833433701/1301363808421543988

---

## Links / PRs / Issues Mentioned This Week

- Pending review: PR #6457 (elizaos/eliza) — https://github.com/elizaos/eliza/pull/6457  
- Pending review: PR #278 (elizaos/eliza-cloud-v2) — https://github.com/elizaos/eliza-cloud-v2/pull/278  
- Issue: Eliza character file & prompt engineering — https://github.com/elizaos/eliza/issues/6447  
- Issue: Billing — https://github.com/elizaos/eliza/issues/6448  
- Skill standard: https://agentskills.io  
- Discord threads (technical):  
  - core-devs: https://discord.com/channels/1253563208833433701/1377726087789940836  
  - coders: https://discord.com/channels/1253563208833433701/1300025221834739744