# ElizaOS Developer Update (2026-03-07 → 2026-03-13)

## 1) Core Framework

### Eliza 2.0.0 alpha published
The team shipped an **ElizaOS 2.0.0 alpha**, with ongoing work to stabilize the `develop` branch and complete remaining WIP items discussed in Discord (notably in `#xfn-framework` and `#coders`). This alpha is being used as the proving ground for deeper runtime and scheduling changes described below.

### Runtime refactor proposal: decomposing `AgentRuntime` + de-risking plugin init
A major runtime refactor proposal was posted (HackMD shared in `#xfn-framework`, feedback requested by Sunday). The driving issues:

- `AgentRuntime` has grown into a **~6k-line “god object”** (reported ~6273 LOC).
- **Infrastructure registration via plugin side-effects** (notably DB adapter registration) is causing correctness issues under parallel plugin initialization.

#### Identified design flaw: plugin init race condition
Current behavior (as reported) allows `init()` for multiple plugins to run concurrently. `plugin-sql` registers the DB adapter as a **side-effect during `init()`**, which means other plugins (e.g., `plugin-personality`) may run before the adapter exists.

Milady’s current workaround is to **manually pre-register `plugin-sql` before calling `initialize()`**, which treats the symptom (ordering) rather than the root cause (side-effectful infra registration + parallel init).

#### Proposed architectural direction
- **Externalize runtime setup logic** out of the runtime module (reduce “god object” responsibilities).
- Make the **database adapter an explicit dependency** (constructor argument / required runtime component), not a “maybe available later” global registered by plugin init.

Illustrative (proposed) shape:

```ts
// Before (implicit, side-effect driven)
const runtime = new AgentRuntime({ plugins: [sqlPlugin(), personalityPlugin()] });
await runtime.initialize(); // init() may run concurrently, DB adapter may not exist yet

// After (explicit dependency injection)
import { createSqlAdapter } from "@elizaos/plugin-sql";

const db = createSqlAdapter({ url: process.env.DATABASE_URL });

const runtime = new AgentRuntime({
  db, // required dependency (or provided via RuntimeComponents)
  plugins: [
    // sql plugin may still exist, but no longer "registers infra" by side-effect
    personalityPlugin(),
  ],
});

await runtime.initialize();
```

**Developer impact:** expect follow-on changes to plugin authoring guidance—plugins should *consume* runtime-provided services (DB, queue, scheduler) rather than *create/register* them implicitly.

---

## 2) New Features

### Prompt batching subsystem (v2.0.0 direction)
After reviewing ~50–60 plugins, a new subsystem dubbed **“prompt batching”** was proposed to unify three classes of model calls into a single scheduler:

1. **Init-time LLM queries** (bootstrapping / warmup)
2. **Autonomous LLM calls** (agent loop)
3. **Evaluator calls** (scoring / judgment / guardrails)

The goal is a configurable scheduler that can be tuned for:
- **Frontier providers** (throughput/latency tradeoffs, rate limits)
- **Local models** (batch sizing, parallelism, token budgets)

A minimal conceptual API might look like:

```ts
type PromptJobKind = "init" | "autonomous" | "evaluator";

scheduler.enqueue({
  kind: "autonomous",
  priority: "normal",
  model: "provider:model-id",
  messages,
  maxTokens: 512,
});

await scheduler.flush({ mode: "batched", maxBatchSize: 8 });
```

This builds on prior “dynamic prompt execution” work and aligns with the existing autonomous system patterns referenced by the team.

### Git branch “story” analyzer
A tool for generating comprehensive narratives across branches was demonstrated and published as:

- PR: https://github.com/elizaOS/prr/pull/5

This is useful for release notes, migration audits, and understanding drift between `0.x`, `1.x`, and `2.x`.

### Cloud embeddings microservice concept (architecture)
A cloud-side **REST endpoint for embeddings** was discussed: decouple embedding computation + persistence behind HTTP, enabling:
- serverless scaling for embedding workloads
- centralization of vector storage concerns
- lighter agent runtimes

No public PR link was provided this week, but this is a key direction for ElizaCloud/Milady service decomposition.

### Ecosystem: open agent registry w/ autonomous discovery + payments (community project)
A community-built registry at **https://aiprox.dev** demonstrated:
- autonomous agent self-registration (including an external agent discovering and registering “unprompted”)
- usage-based ratings
- multi-rail settlement: **Lightning / Solana / x402**
- an auto-approver scoring pipeline (1–10) to filter low-quality registrations
- 14 live agents at time of discussion

Key REST endpoints (as described):
- `POST /api/agents/register`
- `GET /api/agents`

Example registration payload:

```bash
curl -X POST "https://aiprox.dev/api/agents/register" \
  -H "content-type: application/json" \
  -d '{
    "capability": "text-summarization",
    "paymentRail": "lightning",
    "pricePerCall": 50,
    "endpoint": "https://your-agent.example.com/invoke"
  }'
```

Discovery via query:

```bash
curl "https://aiprox.dev/api/agents?capability=text-summarization&sort=rating&paymentRail=lightning"
```

For agentskills.io discovery, a `skill.md` file was added at:
- https://aiprox.dev/skill.md (implementation confirmed in Discord)

---

## 3) Bug Fixes (Critical / High-impact)

### Plugin initialization race condition (root cause identified; fix planned)
**Bug class:** nondeterministic runtime startup due to parallel plugin initialization and side-effectful infra registration (`plugin-sql` DB adapter availability).

**Symptoms observed:**
- Dependent plugins can execute before DB adapter is registered.
- Downstream failures appear as “missing adapter/service” during early lifecycle hooks.

**Current mitigation:** Milady manually pre-registers SQL plugin before `initialize()` (defensive ordering).

**Planned fix:** remove adapter registration side effects; require adapter at runtime construction time (see Core Framework section). This is the highest-impact correctness fix discussed this week because it affects startup determinism across plugin-heavy agents.

### Security incident response (user-impacting)
A fake support bot directed users to a site requesting seed phrases (reported as “colabdesk”). This is not a code bug, but it is a critical operational issue affecting developers and users during token migration support. Guidance reiterated:
- **Never provide seed phrases**
- Discord does not require wallet linking

---

## 4) API Changes (Developer-facing)

### Upcoming: runtime constructor / initialization contract changes (v2 migration pressure)
If the runtime refactor lands as proposed, expect changes such as:

- `AgentRuntime` (or the new runtime composition root) requiring explicit provision of core services:
  - DB adapter
  - scheduler / prompt batching config
  - potentially other infra components currently registered implicitly

**Action for plugin authors:** audit plugins that:
- “register” infra globally in `init()`
- assume DB is present without declaring dependency
- rely on implicit initialization ordering

**Guidance:** treat plugin initialization as *pure* setup where possible; consume dependencies from runtime rather than creating them behind the scenes.

---

## 5) Social Media Integrations

### X (Twitter)
- Work is queued to improve automated Twitter posting for `$degenai` / `$elizaos` (mentioned as blocked by the broken `develop` branch and pending next version completion).

### Telegram / Discord briefings
A “video briefing” system is being developed to summarize Discord/Telegram activity with modular MP4 generation and plans for weekly/monthly rollups. While not a plugin update per se, it affects how developer-facing change summaries will be produced and distributed.

---

## 6) Model Provider Updates

No concrete provider SDK changes (OpenAI/Anthropic/DeepSeek/etc.) were linked this week. Provider-related discussion was primarily operational/quality commentary rather than integration changes.

If prompt batching ships, expect indirect provider-impact via:
- more explicit rate-limit handling
- batch sizing strategies per provider
- unified scheduling policies for evaluator vs autonomous calls

---

## 7) Breaking Changes (V1 → V2 migration warnings)

### Potential breaking change: DB adapter provisioning
If V2 enforces **explicit DB adapter injection**, any V1 agent relying on:

- `plugin-sql` registering adapters as a side effect
- implicit service availability during concurrent plugin init

may fail at startup until updated.

**What to do now:**
- Stop depending on plugin load order for infra availability.
- Refactor agent bootstrap to construct runtime with explicit dependencies (DB adapter, scheduler).

### Potential breaking change: plugin lifecycle assumptions
As runtime setup logic is split out and initialization becomes more deterministic, plugins that:
- perform network calls in `init()` expecting other plugins’ side effects
- mutate shared registries during `init()`

may need to move that work into explicit runtime composition or declare dependencies more formally.

---

## Links / References

- Git branch story analyzer: https://github.com/elizaOS/prr/pull/5  
- Docs PR (cloud content): https://github.com/elizaos/elizaos.github.io/pull/243  
- Babylon ticker (product surface): https://play.babylon.market/ticker  
- Community agent registry: https://aiprox.dev and discovery file https://aiprox.dev/skill.md