Skip to main content

Real Patterns from Real Plugins

These aren’t theoretical - they’re extracted from production plugins. Each pattern solves a specific problem you’ll encounter when building agents that actually work.

Action Chaining

Multi-step workflows where actions build on each other

Callbacks

Send progress updates before actions complete

State Composition

Combine multiple providers elegantly

Error Recovery

Graceful degradation and retry strategies

Action Chaining and Callbacks

Action chaining allows multiple actions to execute sequentially, with each action accessing previous results. This enables complex workflows where actions build upon each other’s outputs.

The ActionResult Interface

Actions return an ActionResult object that standardizes how actions communicate their outcomes. This interface includes:
  • success (required): Boolean indicating whether the action completed successfully
  • text: Optional human-readable description of the result
  • values: Key-value pairs to merge into the state for subsequent actions
  • data: Raw data payload with action-specific results
  • error: Error information if the action failed
The success field is the only required field, making it easy to create simple results while supporting complex data passing for action chaining. For interface definitions, see Plugin Reference. For component basics, see Plugin Components.

Handler Callbacks

The HandlerCallback provides a mechanism for actions to send immediate feedback to users before the action completes:
Example usage:

Action Context and Previous Results

When multiple actions are executed in sequence, each action receives an ActionContext that provides access to previous action results:
The runtime automatically provides this context in the options parameter:

Action Execution Flow

The runtime’s processActions method manages the execution flow:
  1. Action Planning: When multiple actions are detected, the runtime creates an execution plan
  2. Sequential Execution: Actions execute in the order specified by the agent
  3. State Accumulation: Each action’s results are merged into the accumulated state
  4. Working Memory: Results are stored in working memory for access during execution
  5. Error Handling: Failed actions don’t stop the chain unless marked as critical

Working Memory Management

The runtime maintains a working memory that stores recent action results:
The system keeps the most recent 50 entries (configurable) to prevent memory bloat.

Action Patterns

Decision-Making Actions

Actions can use the LLM to make intelligent decisions based on context:

Multi-Step Actions

Actions that need to perform multiple steps with intermediate feedback:

API Integration Actions

Pattern for external API calls with retries and error handling:

Context-Aware Actions

Actions that adapt based on conversation context:

Action Composition

Compose Multiple Actions

Workflow Orchestration

Self-Modifying Actions

Actions that learn and adapt their behavior:

Provider Patterns

Conditional Providers

Providers that only provide data under certain conditions:

Aggregating Providers

Providers that combine data from multiple sources:

Best Practices for Action Chaining

  1. Always Return ActionResult: Even for simple actions, return a proper ActionResult object:
  2. Use Callbacks for User Feedback: Send immediate feedback via callbacks rather than waiting for the action to complete:
  3. Store Identifiers in Data: When creating resources, store identifiers that subsequent actions might need:
  4. Handle Missing Dependencies: Check if required previous results exist:
  5. Maintain Backward Compatibility: The runtime handles legacy action returns (void, boolean) but new actions should use ActionResult.

Example: Multi-Step Workflow

Here’s an example of a multi-step workflow using action chaining:

Common Patterns

  1. Create and Configure: Create a resource, then configure it
  2. Search and Update: Find resources, then modify them
  3. Validate and Execute: Check conditions, then perform actions
  4. Aggregate and Report: Collect data from multiple sources, then summarize
The action chaining system provides a powerful way to build complex, multi-step workflows while maintaining clean separation between individual actions.

Real-World Implementation Patterns

This section documents actual patterns and structures used in production elizaOS plugins based on examination of real implementations.

Basic Plugin Structure Pattern

Every plugin follows this core structure pattern (from plugin-starter):

Bootstrap Plugin Pattern

The most complex and comprehensive plugin that provides core functionality:

Service Plugin Pattern (Discord, Telegram)

Platform integration plugins focus on service implementation:

Action Implementation Pattern

Actions follow a consistent structure with validation and execution:

Complex Action Pattern (Reply Action)

Provider Implementation Pattern

Providers supply contextual data to the agent:

Plugin Initialization Pattern

Plugins can have initialization logic:

See Also

Plugin Architecture

Understand the overall plugin system design

Development Guide

Build your first plugin with step-by-step guidance

Plugin Schemas

Learn about configuration and validation schemas

Plugin Migration

Migrate existing plugins to new patterns