Overview
Plugin components are the building blocks that give agents their capabilities. Each component type serves a specific purpose in the agent’s decision-making and interaction flow. For system architecture, see Plugin Architecture.Component Types
Component | Purpose | When Executed |
---|---|---|
Actions | Tasks agents can perform | When agent decides to take action |
Providers | Supply contextual data | Before actions/decisions |
Evaluators | Process and extract from responses | After agent generates response |
Services | Manage stateful connections | Throughout agent lifecycle |
Actions
Actions are discrete tasks agents can perform. They represent the agent’s capabilities - what it can DO.Action Interface
Actions define discrete tasks that agents can perform. Each action has:- name: Unique identifier for the action
- description: Clear explanation of what the action does
- similes: Alternative names or aliases for fuzzy matching
- examples: Training examples showing when to use the action
- validate: Function to check if the action can run in the current context
- handler: The execution logic that returns an
ActionResult
ActionResult
with a success
field indicating whether the action completed successfully.
For complete interface definitions, see Plugin Reference.
Core Actions (Bootstrap Plugin)
The bootstrap plugin provides 13 essential actions:Communication Actions
Action | Description | Example Trigger |
---|---|---|
REPLY | Generate response | ”Tell me about…” |
SEND_MESSAGE | Send to specific room | ”Message the team…” |
NONE | Acknowledge silently | ”Thanks!” |
IGNORE | Skip message | Spam/irrelevant |
Room Management
Action | Description | Example Trigger |
---|---|---|
FOLLOW_ROOM | Subscribe to updates | ”Join #general” |
UNFOLLOW_ROOM | Unsubscribe | ”Leave #general” |
MUTE_ROOM | Mute notifications | ”Mute this channel” |
UNMUTE_ROOM | Unmute | ”Unmute #general” |
Data & Configuration
Action | Description | Example Trigger |
---|---|---|
UPDATE_CONTACT | Update contact info | ”Remember that I…” |
UPDATE_ROLE | Change roles | ”Make me admin” |
UPDATE_SETTINGS | Modify settings | ”Set model to gpt-4” |
Media & Utilities
Action | Description | Example Trigger |
---|---|---|
GENERATE_IMAGE | Create AI images | ”Draw a cat” |
CHOICE | Present options | ”Should I A or B?” |
Creating Actions
For advanced patterns, see Plugin Patterns.Minimal Action
With Validation
With Examples
Handler Patterns
Best Practices for Actions
- Name actions clearly (VERB_NOUN format)
- Always return ActionResult with
success
field - Validate before executing
- Return consistent response format
- Use similes for alternative triggers
- Provide diverse examples
- Handle errors gracefully
Providers
Providers supply contextual information to the agent’s state before it makes decisions. They act as the agent’s “senses”, gathering relevant data.Provider Interface
Providers supply contextual data to enhance agent decision-making. Each provider has:- name: Unique identifier for the provider
- description: Optional explanation of what data it provides
- dynamic: If true, data is re-fetched each time (not cached)
- position: Execution order priority (-100 to 100, lower runs first)
- private: If true, hidden from the default provider list
- get: Function that returns a
ProviderResult
with text, values, and data
get
function receives the runtime, current message, and state, returning data that will be composed into the agent’s context.
For complete interface definitions, see the Provider Interface in the Reference.
Core Providers (Bootstrap Plugin)
Provider | Returns | Example Use |
---|---|---|
characterProvider | Agent personality | Name, bio, traits |
timeProvider | Current date/time | ”What time is it?” |
knowledgeProvider | Knowledge base | Documentation, facts |
recentMessagesProvider | Chat history | Context awareness |
actionsProvider | Available actions | ”What can you do?” |
factsProvider | Stored facts | User preferences |
settingsProvider | Configuration | Model settings |
Creating Providers
Basic Provider
Dynamic Provider
Private Provider
Provider Priority
Provider Execution Flow
- Providers are executed during
runtime.composeState()
- By default, all non-private, non-dynamic providers are included
- Providers are sorted by position and executed in order
- Results are aggregated into a unified state object
- The composed state is passed to actions and the LLM for decision-making
Best Practices for Providers
- Return consistent data structures
- Handle errors gracefully
- Cache when appropriate
- Keep data fetching fast
- Document what data is provided
- Use position to control execution order
Evaluators
Evaluators are post-processors that analyze and extract information from conversations.Evaluator Interface
Evaluators process and extract information from agent responses. Each evaluator has:- name: Unique identifier for the evaluator
- description: Explanation of what it evaluates or extracts
- similes: Alternative names for matching
- alwaysRun: If true, runs on every agent response
- examples: Training examples for the evaluator
- validate: Function to determine if evaluator should run
- handler: Processing logic that analyzes the response
Core Evaluators (Bootstrap Plugin)
Evaluator | Purpose | Extracts |
---|---|---|
reflectionEvaluator | Self-awareness | Insights about interactions |
factEvaluator | Fact extraction | Important information |
goalEvaluator | Goal tracking | User objectives |
Evaluator Flow
Common Use Cases
Memory Building
- Extract facts from conversations
- Track user preferences
- Update relationship status
- Record important events
Content Filtering
- Remove sensitive data
- Filter profanity
- Ensure compliance
- Validate accuracy
Analytics
- Track sentiment
- Measure engagement
- Monitor topics
- Analyze patterns
Creating Evaluators
Basic Evaluator
With Examples
Best Practices for Evaluators
- Run evaluators async (don’t block responses)
- Store extracted data for future context
- Use
alwaysRun: true
sparingly - Provide clear examples for training
- Keep handlers lightweight
Services
Services manage stateful connections and provide core functionality. They are singleton instances that persist throughout the agent’s lifecycle.Service Abstract Class
Services are singleton instances that manage stateful connections and provide persistent functionality throughout the agent’s lifecycle. Services extend an abstract class with:- serviceType: Static property identifying the service type
- capabilityDescription: Description of what the service provides
- start(): Static method to initialize and start the service
- stop(): Method to clean up resources when shutting down
- config: Optional configuration metadata
Service Types
The system includes predefined service types:- TRANSCRIPTION, VIDEO, BROWSER, PDF
- REMOTE_FILES (AWS S3)
- WEB_SEARCH, EMAIL, TEE
- TASK, WALLET, LP_POOL, TOKEN_DATA
- DATABASE_MIGRATION
- PLUGIN_MANAGER, PLUGIN_CONFIGURATION, PLUGIN_USER_INTERACTION
Creating Services
Service Lifecycle Patterns
Delayed Initialization
Sometimes services need to wait for other services or perform startup tasks:Best Practices for Services
- Handle missing API tokens gracefully
- Implement proper cleanup in
stop()
- Use delayed initialization for non-critical tasks
- Log service lifecycle events
- Make services resilient to failures
- Keep service instances stateless when possible
Component Interaction
Execution Flow
- Providers gather context → compose state
- Actions validate against state → execute if valid
- Evaluators process responses → extract information
- Services provide persistent functionality throughout
State Composition
Service Access
Plugin Example with All Components
Guide: Create a Plugin