# ElizaOS Developer Update - July 25, 2025

## Core Framework

This week saw major architectural improvements across the ElizaOS platform:

- **XML Prompt Format Migration**: Completed refactoring of all JSON-based prompts to XML format across the codebase, significantly improving LLM response reliability for core entities and bootstrap plugin. This affects action formatting and memory handling ([#5623](https://github.com/elizaos/eliza/pull/5623)).

- **EventTarget Migration**: Replaced Node.js EventEmitter with Bun's native EventTarget API in InternalMessageBus and SimpleMigrationAgent for improved performance and runtime compatibility ([#5609](https://github.com/elizaos/eliza/pull/5609), [#5614](https://github.com/elizaos/eliza/pull/5614)).

- **Enhanced Module Resolution**: Implemented a robust ModuleLoader system with local-first guarantees for consistent module resolution across the platform, ensuring that local development environments behave identically to production ([#5629](https://github.com/elizaos/eliza/pull/5629)).

- **Service Type System**: Added a standardized service interface system with the new `getServicesByType()` method, enabling multiple services of the same type and simplifying service discovery ([#5565](https://github.com/elizaos/eliza/pull/5565)).

## New Features

### Action Chaining

Introduced a powerful action chaining capability that allows agents to execute sequential, interdependent actions:

```typescript
// Define chained actions
const result = await runtime.executeAction({
  type: "FIRST_ACTION", 
  payload: { initialData: "value" }
});

// Access results from previous action
if (result.success) {
  // Use result.data in next action
  const secondResult = await runtime.executeAction({
    type: "SECOND_ACTION",
    payload: { previousResult: result.data }
  });
}
```

Action state is stored on the State object and passed to subsequent actions, enabling complex workflows. The feature includes callback support for user messaging during execution ([#5436](https://github.com/elizaos/eliza/pull/5436), [#5490](https://github.com/elizaos/eliza/pull/5490)).

### Test Utils Package

Added a new `@elizaos/test-utils` package that centralizes mock utilities and streamlines testing:

```typescript
import { createMockRuntime } from '@elizaos/test-utils';

// Create a standardized mock runtime with consistent behavior
const mockRuntime = createMockRuntime();

// Test your plugin actions
test('my action works correctly', async () => {
  const result = await myAction(mockRuntime, { param: 'value' });
  expect(result.success).toBe(true);
});
```

This provides consistent test setup across plugins and significantly reduces boilerplate code ([#5507](https://github.com/elizaos/eliza/pull/5507)).

### Plugin Quick Starter

Added a new `plugin-quick-starter` template for backend-only plugins:

```bash
elizaos create --type plugin mybackendplugin
# Select "Quick Starter" when prompted
```

This streamlined template removes frontend overhead, perfect for developers focusing on actions, providers, or services without UI requirements ([#5589](https://github.com/elizaos/eliza/pull/5589)).

## Bug Fixes

- **Plugin Actions Loading**: Fixed critical issue where plugin actions weren't being received by the runtime when using the NPM deployed version of the CLI ([#5624](https://github.com/elizaos/eliza/pull/5624)).

- **SQL JSON Handling**: Resolved a bug in the SQL base plugin where raw objects were improperly passed to SQL queries instead of being properly stringified ([#5628](https://github.com/elizaos/eliza/pull/5628)).

- **Windows Compatibility**: Improved path handling for Windows users, fixing plugin loading failures with proper path normalization and localhost resolution ([#5437](https://github.com/elizaos/eliza/pull/5437), [#5416](https://github.com/elizaos/eliza/pull/5416)).

- **Project Creation Isolation**: Fixed an issue where creating a new project inside an existing one would incorrectly inherit parent's database configuration, causing data corruption ([#5618](https://github.com/elizaos/eliza/pull/5618)).

- **Build Process**: Corrected a bug where tsup builds were wiping vite builds in plugin and project starters, ensuring both builds coexist properly ([#5555](https://github.com/elizaos/eliza/pull/5555)).

## API Changes

- **Action Interface Update**: The `Action` interface now requires all handlers to return `Promise<ActionResult>` instead of any, enforcing stricter type compliance.

```typescript
// Before
async function myAction(runtime: Runtime, payload: any): Promise<any> {
  // Implementation
}

// After
async function myAction(runtime: Runtime, payload: MyPayload): Promise<ActionResult> {
  return {
    success: true,
    data: { result: 'value' }
  };
}
```

- **Service Registration**: Services now must implement a static `start` method and define their service type:

```typescript
// Example service with type registration
export class MyBrowserService implements BrowserService {
  serviceType = 'browser';
  
  static async start(opts: ServiceOptions): Promise<MyBrowserService> {
    return new MyBrowserService(opts);
  }
  
  // Service implementation
}
```

- **ModuleLoader Changes**: Added new `ModuleLoader` utility for consistent module resolution across environments:

```typescript
import { ModuleLoader } from '@elizaos/cli';

// Consistent module loading with local-first guarantees
const serverModule = await ModuleLoader.load('@elizaos/server');
```

## Social Media Integrations

### Twitter Plugin

- The Twitter plugin has ongoing issues with accounts being suspended. The team is working with X to resolve the situation, with communication showing recent improvement.
- Added Twitter posting examples to the default Eliza character template to ensure better functionality when the plugin is activated ([#5652](https://github.com/elizaos/eliza/pull/5652)).
- Authentication errors with Twitter API persist, likely due to rate limiting or token issues, as reported in Discord discussions.

### Discord Updates

- Developers discussed socket communication challenges between ElizaOS and Discord in Discord channels.
- Issues with receiving responses in extensions were addressed, with recommendations to listen for 'messageBroadcast' events.
- Room creation and management for services was identified as a key topic in development.

## Model Provider Updates

- **Ollama Integration**: Made the Ollama plugin truly conditional based on the presence of `OLLAMA_API_ENDPOINT` environment variable, rather than being included by default ([#5594](https://github.com/elizaos/eliza/pull/5594)).

- **Google Generative AI**: Fixed plugin installation issue where the system was incorrectly trying to install `@elizaos/plugin-google-ai` instead of `@elizaos/plugin-google-genai` ([#5503](https://github.com/elizaos/eliza/pull/5503)).

- **Local Model Resolution**: Corrected the mapping of 'local' models to 'ollama' plugin in the character converter, ensuring proper plugin loading ([#5587](https://github.com/elizaos/eliza/pull/5587)).

- **Provider Selection**: Refined LLM provider selection prompts to reduce unnecessary provider use and improve reply speed ([#5526](https://github.com/elizaos/eliza/pull/5526)).

## Breaking Changes

Several important migration considerations for V1 to V2:

- The prompt format has changed from JSON to XML, requiring updates to any custom plugins parsing LLM output.

- Added automatic V1 → V2 character conversion during JSON import, with plugin matching to ensure backward compatibility ([#5536](https://github.com/elizaos/eliza/pull/5536)):

```typescript
// Before conversion (V1):
{
  "name": "MyAgent",
  "provider": "openai"
}

// After conversion (V2):
{
  "name": "MyAgent",
  "plugins": ["@elizaos/plugin-openai"]
}
```

- Service implementations now require a static `start` method and must specify their service type, requiring updates to any custom services.

- The EventEmitter to EventTarget migration maintains backward compatibility APIs, but internal event handling has changed, potentially affecting plugins with deep integration.