# ElizaOS Developer Update (2026-03-24 → 2026-03-31)

This update summarizes core runtime changes, plugin/ecosystem activity, and developer-facing implications from GitHub + community discussions.

---

## 1) Core Framework

### Message/action parsing hardening (XML-first, param-safe)
Two related fixes landed in the TypeScript runtime message pipeline to make action extraction resilient to common LLM formatting patterns:

- **Parse XML action tags instead of comma-splitting `<actions>` content**  
  PR: https://github.com/elizaos/eliza/pull/6661  
  Context: the old parser would split on commas, which corrupts actions or arguments containing commas (e.g., tasks like “orange, black, and red…”).

- **Extract action params from standalone sibling XML blocks when `<actions>` are comma-separated**  
  PR: https://github.com/elizaos/eliza/pull/6692  
  Context: when an LLM emits `<actions>REPLY,START_TASK</actions>` but emits params in separate blocks (`<task>…</task>`), params were dropped.

**Why this matters:** if you’re building plugins/actions that depend on structured arguments, these changes significantly reduce “action fired but arg missing” failures and make prompt-output contracts more tolerant of model variance.

---

### Trajectory/trace context propagation fixed (AsyncLocalStorage init)
- **Initialize trajectory AsyncLocalStorage synchronously**  
  PR: https://github.com/elizaos/eliza/pull/6687

**Problem:** trajectory context was initialized via async dynamic import; early messages would fall back to a non-ALS context manager that doesn’t propagate cleanly through async/await chains. Result: LLM calls weren’t attributed to the correct trajectory, producing incomplete traces.

**Impact for developers:**
- Observability/telemetry built on trajectories should now capture early-run LLM calls reliably.
- If you have custom instrumentation that reads trajectory context at startup, you should see more consistent values without needing artificial warmups.

---

### Prompt size reduction (core prompt template cleanup)
- **Remove redundant action params example (~500 chars per prompt)**  
  PR: https://github.com/elizaos/eliza/pull/6684  
This reduces baseline token overhead in core prompts. If you were close to context limits, you should see slightly improved headroom.

---

## 2) New Features

### Ecosystem: Agent Commerce integrations emerging (x402 + paid APIs)
While not merged into core this week, multiple integration surfaces are converging on **HTTP 402 “payment required”** patterns for agent-native commerce:

- **Dreamline x402 Policy Facilitator (spend governance layer) — proposal**  
  Issue: https://github.com/elizaos/eliza/issues/6695  
  Goal: intercept x402 payment flows *before execution* to enforce:
  - blacklists (on-chain registry)
  - per-agent budgets
  - allowlists / tx limits
  - auditability

- **Pyrimid x402 Agent Commerce via MCP — proposal**  
  Issue: https://github.com/elizaos/eliza/issues/6668  
  MCP server provides tools for discovering paid APIs and paying per-call in USDC on Base.

- **Orbis API marketplace (Discord announcement)**: `402 → pay USDC on Base → retry` gateway flow  
  Discovery endpoint shared: `https://orbisapi.com/api/agents/discovery` (Discord summary, 2026-03-29)

- **TaskBounty (Discord announcement)**: autonomous task completion + crypto payouts via REST + OpenAPI  
  Spec: https://task-bounty.com/api/v1/openapi.json  
  Docs: https://task-bounty.com/for-agents

#### Example: implementing a 402 payment handshake (client-side skeleton)
Below is a generic pattern you can adapt inside an ElizaOS plugin tool wrapper when calling a 402-protected endpoint:

```ts
type PaymentRequired = {
  paymentUrl: string;     // where to execute settlement
  amount: string;         // e.g. "0.25"
  currency: "USDC";
  chain: "base";
  memo?: string;
};

async function fetchWith402(url: string, init?: RequestInit) {
  const res1 = await fetch(url, init);

  if (res1.status !== 402) return res1;

  const pr: PaymentRequired = await res1.json();

  // 1) Ask governance/policy layer (human-in-the-loop or policy plugin) BEFORE paying
  //    (see spend governance discussion in #6695)
  // await runtime.tools.policy.checkOrThrow(pr);

  // 2) Settle payment (implementation-specific: wallet plugin / x402 plugin / external facilitator)
  // await runtime.tools.wallet.pay({ to: pr.paymentUrl, amount: pr.amount, ... });

  // 3) Retry the original request after settlement
  return fetch(url, init);
}
```

**Important:** this week’s governance discussion highlighted an open design question: *does the current x402 plugin surface pre-flight events to the operator before a fetch executes?* If you’re building commerce agents, budget enforcement should happen **before** settlement (see §7 Breaking Changes / Migration notes for recommended patterns).

---

## 3) Bug Fixes (critical)

### CI/release pipeline fixes (unblocking publishing & Linux builds)
A sequence of fixes landed to stabilize releases, particularly for Linux and for package dist-tag correctness:

- **Fix: ensure `@elizaos/core` dist-tag is updated in release**  
  PR: https://github.com/elizaos/eliza/pull/6667  
  Root cause: `lerna ls` didn’t include `@elizaos/core`, so the tag verification loop skipped it and the release failed post-publish.

- **Fix: remove stale `packages/agent` dist check from release**  
  PR: https://github.com/elizaos/eliza/pull/6666  
  Root cause: release workflow referenced a deleted package path; caused false-negative failures.

- **Fix: Linux Rust build errors (computeruse)**  
  PR: https://github.com/elizaos/eliza/pull/6664

- **Fix (CI): add system deps for Linux builds (`libpipewire`, `libegl`, `libgbm`, `libxcb`, `libssl`)**  
  PRs:  
  https://github.com/elizaos/eliza/pull/6662  
  https://github.com/elizaos/eliza/pull/6663  
  https://github.com/elizaos/eliza/pull/6665

**Developer takeaway:** if you maintain Rust-adjacent plugins or rely on the `computeruse` package, Linux CI should now be materially less flaky, and release publishing should no longer fail due to dist-tag validation.

---

## 4) API Changes (developer-facing behavior)

No explicit public API version bump was recorded this week, but there are **behavioral changes** that affect plugin authors:

### Action extraction behavior changes (recommended review for action-heavy agents)
Due to PRs **#6661** and **#6692**, the runtime now:
- prioritizes **XML structure** over comma-based heuristics when parsing action tags
- better associates **standalone XML param blocks** with actions in comma-separated `<actions>` outputs

If your plugin depended on the previous comma-splitting behavior (e.g., expecting multiple actions to be derived from comma-delimited text regardless of XML), validate your prompts and tests.

---

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

No new social plugin merges were captured in the provided GitHub activity for this week.

Community discussions were focused on:
- improving **ecosystem discoverability** (proposal for a centralized “agents/apps/dApps/projects hub” on the website) (Discord 2026-03-29)
- Discord fragmentation and bridging between builder-focused and investor-focused servers (Discord 2026-03-29)

If you maintain social integrations, this is a good time to ensure your agent/project metadata is easy to surface in a future directory/hub.

---

## 6) Model Provider Updates

### Tooling: Claude code review workflow updated
- **Update Claude Code Review action and model version**  
  PR: https://github.com/elizaos/eliza/pull/6681

This affects automated reviews in CI, not runtime inference directly. If you mirror ElizaOS workflows in downstream repos, re-sync your GitHub Actions to keep parity.

---

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

### Spend governance is currently an ecosystem-level sharp edge (x402)
This week surfaced a **critical security gap**: autonomous agents can spend via x402 without a standardized pre-flight governance layer (discussion referenced in relation to Dreamline Policy Facilitator proposal, issue **#6695**).

**Migration guidance (V1 → V2 commerce agents):**
- Treat **any** “agent can pay” capability as requiring a **policy gate**:
  - per-tx limits
  - daily budget caps
  - allowlist/denylist checks
  - operator approval hooks for high-risk categories
- Prefer architectures where the payment step is mediated by:
  1) a policy tool/plugin (pre-flight decision)
  2) a wallet/payment executor
  3) an auditable receipt emitter

Track and participate here: https://github.com/elizaos/eliza/issues/6695

### Known DX issue: CLI availability on macOS (PATH/global bin)
An open report indicates some users install the CLI but can’t run `elizaos` due to PATH/global bin resolution issues:
- Issue: https://github.com/elizaos/eliza/issues/6636

If you’re onboarding teams from V1 tooling, proactively verify bun global bin setup in your docs or project bootstrap instructions.

---

### References (quick links)
- Daily dev summary feed (2026-03-30): https://elizaos.github.io/api/summaries/overall/day/2026-03-30.json
- Key merged PRs:  
  - https://github.com/elizaos/eliza/pull/6692  
  - https://github.com/elizaos/eliza/pull/6687  
  - https://github.com/elizaos/eliza/pull/6684  
  - https://github.com/elizaos/eliza/pull/6667  
  - https://github.com/elizaos/eliza/pull/6666  
  - https://github.com/elizaos/eliza/pull/6665  
  - https://github.com/elizaos/eliza/pull/6664  
  - https://github.com/elizaos/eliza/pull/6663  
  - https://github.com/elizaos/eliza/pull/6662  
  - https://github.com/elizaos/eliza/pull/6661
- Key issues/proposals:  
  - Dreamline governance: https://github.com/elizaos/eliza/issues/6695  
  - Pyrimid MCP commerce: https://github.com/elizaos/eliza/issues/6668  
  - AgentID proposal: https://github.com/elizaos/eliza/issues/6688  
  - macOS CLI PATH: https://github.com/elizaos/eliza/issues/6636