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

This week focused on **V2 runtime correctness (schema-driven execution + validation)**, **multi-tenant configuration via request-scoped settings**, and **infrastructure hardening** for centralized messaging (Discord as a service, Telegram webhook registration). The community also surfaced **critical onboarding bugs in ElizaCloud** and Babylon production issues that were quickly patched.

---

## 1) Core Framework

### V2 dynamic execution engine: schema-driven prompt execution + validation (merged)
PR: **“V2.0.0: dynamic execution engine”** ([elizaos/eliza#6384](https://github.com/elizaos/eliza/pull/6384))

**What changed**
- Introduced a new **schema-driven execution path** across TS/Python/Rust:
  - `dynamicPromptExecFromState` (TS) / `dynamic_prompt_exec_from_state` (Python/Rust)
- Adds **validation codes** (UUID markers) and **required-field checks** to detect:
  - truncated outputs due to context window overflow
  - incomplete structured responses
- Implements **retry with exponential backoff** for failed validations.
- Adds **validation-aware streaming** (TS) using extractors (e.g., `ValidationStreamExtractor`) and richer stream events.

**Why it matters**
- If your agents rely on structured outputs (XML/JSON), this reduces silent failures and “half-parsed” states by actively detecting and retrying invalid generations.

**Developer note**
- This is a foundational V2 behavior shift: message flows (should-respond, single-shot, multi-step decision, final summary) now bias toward **structured schemas** vs ad-hoc parsing.

---

### Request-scoped entity settings (multi-tenant runtime) (merged)
PR: **“feat(core): add request context for per-user entity settings”** ([elizaos/eliza#6457](https://github.com/elizaos/eliza/pull/6457))

**What changed**
- Adds `RequestContext` propagated via **AsyncLocalStorage** (Node).
- `AgentRuntime.getSetting()` now resolves settings in this order:
  1. **Request-scoped `entitySettings`** (per-user / per-entity)
  2. Character/agent settings/secrets (existing behavior)

**Important semantic details**
- `undefined` in `entitySettings` means “fall through to character settings”.
- `null` is treated as an **explicit override** (i.e., return null).
- Entity settings are treated as **already-decrypted** (so `getSetting` does not decrypt them again).

---

### Infra items closed (core repo issues)
- Telegram webhook registration tracked as infra work: **closed** ([elizaos/eliza#6425](https://github.com/elizaos/eliza/issues/6425))
- Discord deployed as an AWS service tracked as infra work: **closed** ([elizaos/eliza#6424](https://github.com/elizaos/eliza/issues/6424))

(Implementation PRs were referenced in Discord, but only the issue closures are present in the aggregated GitHub activity.)

---

## 2) New Features

### Structured execution with validation + retries (V2)
With [#6384](https://github.com/elizaos/eliza/pull/6384), you can drive LLM output through a schema and automatically detect invalid/truncated results.

**TypeScript example (conceptual usage)**
```ts
import { AgentRuntime } from "@elizaos/core";

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

// Pseudocode: refer to V2 runtime docs/implementation for exact types.
const schema = [
  { key: "title", required: true, type: "string" },
  { key: "summary", required: true, type: "string" },
];

const result = await runtime.dynamicPromptExecFromState({
  state: { /* injected state */ },
  schema,
  options: {
    // validation level 0–3 (higher = stricter/more checkpoints)
    validationLevel: 2,
    maxRetries: 3,
    retryBackoff: { baseMs: 250, maxMs: 4000, factor: 2.0 },
    format: "xml", // xml/json supported depending on runtime path
  },
});

if (!result) {
  // Validation failed after retries
  throw new Error("LLM failed schema validation");
}
```

---

### RequestContext for per-user settings (multi-tenant agents)
Use request context to run multiple users through the same runtime while maintaining isolated settings (API keys, OAuth tokens, etc.). See [#6457](https://github.com/elizaos/eliza/pull/6457).

**Node/TS example**
```ts
import { runWithRequestContext } from "@elizaos/core";
import type { AgentRuntime } from "@elizaos/core";

async function handleUserMessage(runtime: AgentRuntime, userId: string, message: string) {
  // Example: fetch entity settings from your DB (already decrypted)
  const entitySettings = new Map<string, unknown>([
    ["OPENAI_API_KEY", process.env.USER_SCOPED_OPENAI_KEY],
    ["X_OAUTH_TOKEN", process.env.USER_SCOPED_X_TOKEN],
  ]);

  return runWithRequestContext(
    { entityId: userId, entitySettings },
    async () => {
      // Any runtime.getSetting("...") inside this async call chain
      // will prefer entitySettings.
      return runtime.handleMessage({ content: message });
    }
  );
}
```

---

### Babylon production launch (platform feature; external to core repo)
Discord (core-devs): Babylon production onboarding + testing flow (babylon.market → play.babylon.market). A critical profile update bug was discovered and patched quickly (see “Bug Fixes”).

Channel reference:  
- core-devs discussion (Babylon production) https://discord.com/channels/1253563208833433701/1377726087789940836

---

## 3) Bug Fixes (Critical)

### MESSAGE_SENT event not emitted for central bus submissions (fixed)
Item listed as completed in monthly summary: **“fix(server): emit MESSAGE_SENT event after sending to central server”** ([elizaos/eliza#6378](https://github.com/elizaos/eliza/pull/6378))  
Related issue: **EVENT MESSAGE SENT not working** ([elizaos/eliza#5216](https://github.com/elizaos/eliza/issues/5216)) (closed)

**Technical context**
- Previously, plugin authors listening to `EventType.MESSAGE_SENT` would not receive events when responses were submitted to `/api/messaging/submit`, causing downstream automations (analytics, relays, audit logs) to miss dispatch confirmation.
- The fix ensures `MESSAGE_SENT` is emitted after the server successfully sends to the central API, restoring correct lifecycle semantics for message bus observers.

---

### Babylon profile image upload failing (“Failed to update profile”) (fixed in production)
Discord report and confirmation:
- Bug discovered by **ziflie**; fix merged by **tcm390**; confirmed resolved.
- Channel reference: https://discord.com/channels/1253563208833433701/1377726087789940836

**Impact**
- Blocked basic user profile customization in Babylon production and risked undermining first-session UX during rollout.

---

### ElizaCloud onboarding regression: “Get started” link creates duplicate accounts + wrong credits (unresolved; critical)
Discord (coders): https://discord.com/channels/1253563208833433701/1300025221834739744  
Summary:
- Welcome email “get started” links routed users to **dev.elizacloud.ai** instead of **elizacloud.ai**, causing:
  - duplicate accounts under the same email
  - agent fragmentation across accounts
  - incorrect crediting: $5 promo not applied; $1 seen on the dev account

**Developer-facing implications**
- If you are integrating ElizaCloud provisioning into CLI or onboarding flows, ensure environment URLs are not mixed and that account-linking logic is idempotent per email/identity provider.

---

## 4) API Changes (Developer-facing)

### `AgentRuntime.getSetting()` resolution now prefers RequestContext entity settings
PR: [#6457](https://github.com/elizaos/eliza/pull/6457)

**What to watch**
- If you previously relied on character settings/secrets always winning, that assumption is no longer valid inside a request context.
- If your code sets `entitySettings` with `null`, it will intentionally override (return null) and may disable downstream integrations unless handled.

**Practical guidance**
- Prefer `undefined` (or absence of key) to “inherit defaults”.
- Use `null` only when you explicitly want to disable a setting.

---

### V2 execution path biases toward structured schemas and validation-aware flows
PR: [#6384](https://github.com/elizaos/eliza/pull/6384)

**What to watch**
- If you parse raw model text yourself, confirm whether your runtime path now returns normalized structured outputs (XML/JSON) and whether validation codes/checkpoints are injected/removed as expected.
- Streaming consumers should be prepared for richer stream event types and validation buffering depending on validation level.

---

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

### Telegram: webhook registration infra completed (issue closed)
Issue closed: [elizaos/eliza#6425](https://github.com/elizaos/eliza/issues/6425)

**Operational implication**
- Telegram deployments can run **pure webhook** (no polling) and route inbound messages to the correct agent instance once webhook registration is configured in your infra environment.

---

### Discord: deploy as an AWS service completed (issue closed)
Issue closed: [elizaos/eliza#6424](https://github.com/elizaos/eliza/issues/6424)

**Operational implication**
- Moves Discord event ingestion toward a scalable service pattern suitable for Cloud routing to agents.

---

### Farcaster login failures observed in Babylon testing (investigation ongoing)
Discord context (Babylon internal launch issues): February 4 discussions indicated Farcaster login failures and other loading problems during internal testing.

(Tracked in Discord; no linked GitHub issue/PR present in the provided activity.)

---

## 6) Model Provider Updates

### No provider SDK swaps merged this week; V2 execution defaults emphasize “large text models”
PR: [#6384](https://github.com/elizaos/eliza/pull/6384)

**What changed at runtime level**
- V2 dynamic execution introduces configurable validation levels and model selection, with defaults targeting **large text models** to improve structured reliability under schema constraints.

**Community signals**
- Discord discussions referenced interest in newer Anthropic model tiers (e.g., “Opus 4.6” pricing parity questions) and potential shifts to “Sonnet” for cost/perf tradeoffs, but no merged provider change was included in this week’s aggregated GitHub data.

---

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

### V2 structured execution + validation can change response shapes and failure modes
PR: [#6384](https://github.com/elizaos/eliza/pull/6384)

**Potential breakpoints**
- Workflows that depended on “best-effort” parsing of partially generated XML/JSON may now:
  - trigger retries (increased latency)
  - return `null` on repeated validation failures (hard fail instead of partial output)
- Streaming consumers may observe buffering behavior depending on validation level (especially at stricter levels).

**Migration action**
- If you maintain custom prompts/actions expecting unstructured text, consider introducing explicit schemas (or lowering validation level) during transition.

---

### `getSetting()` precedence changes under RequestContext
PR: [#6457](https://github.com/elizaos/eliza/pull/6457)

**Potential breakpoints**
- Multi-tenant servers that introduce request contexts can inadvertently override global/character settings.
- `null` being a valid override can disable integrations unexpectedly if your settings hydration layer emits nulls.

**Migration action**
- Audit settings hydration and ensure you only set keys you intend to override.
- Add logging around active request context during debugging of “wrong API key / wrong OAuth token” reports.

---

## Docs & References

- Core documentation guides (architecture, concepts, plugin dev, interop, deployment, API reference):  
  PR: [elizaos/eliza#6356](https://github.com/elizaos/eliza/pull/6356)

- Discord threads referenced in this update:
  - ElizaCloud onboarding/account duplication: https://discord.com/channels/1253563208833433701/1300025221834739744  
  - Babylon production testing + profile bug fix: https://discord.com/channels/1253563208833433701/1377726087789940836  
  - Broader discussion (cross-chain, Cloud login cycling, BuildAMolt): https://discord.com/channels/1253563208833433701/1253563209462448241