elizaos

Explains elizaOS runtime abstractions and plugin development patterns for TypeScript agent development.

1|Updated Aug 5, 2026
One-click install
npx skills add https://github.com/Solizardking/Solana-Robotics-Kit --skill elizaos-solizardking
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: elizaos
Source: https://github.com/Solizardking/Solana-Robotics-Kit/tree/main/eliza/packages/skills/skills/elizaos
Command: npx skills add https://github.com/Solizardking/Solana-Robotics-Kit --skill elizaos-solizardking

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developers working on elizaOS-based agents often guess at runtime behavior instead of understanding the actual plugin lifecycle, state composition, and message flow, leading to bugs in actions, providers, and services. ## Core Features & Use Cases - Runtime Mental Model: Explains AgentRuntime, the Memory versus State split, and the end-to-end message processing pipeline. - Plugin Development Guidance: Covers extension points including actions, providers, services, models, evaluators, and routes with registration order details. - Use Case: When an Eliza feature behaves unexpectedly, use this Skill to determine whether the root cause lies in provider ordering, action planning, model handler selection, or plugin loading. ## Quick Start Explain how providers compose state in the elizaOS runtime and why my plugin's context is missing from the prompt.

Frequently Asked Questions about elizaos

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an elizaOS plugin?

An elizaOS plugin is a plain object registering actions, providers, services, models, evaluators, routes, and events. At registration, plugin.init runs first, components are registered, routes are namespaced under the plugin name, and services initialize asynchronously.

What is the difference between Memory and State in elizaOS?

Memory is persistent data such as messages, documents, and fragments stored across turns. State is ephemeral per-turn context with values, data, and text fields, built by providers during composeState for prompt composition and action execution.

When should I use a provider versus an action in elizaOS?

Use a provider when the feature changes prompt context, since providers run during composeState and return text, values, or data. Use an action when the feature performs an operation or side effect executed through planned tool calls.

Why is my elizaOS plugin provider not appearing in prompts?

Providers marked private or dynamic are excluded from the default provider set unless explicitly requested. Also check provider ordering via the position field, since providers are ordered during state composition.

How does elizaOS message processing work end to end?

The pipeline ingests a message, persists the incoming memory, composes state via providers, optionally processes attachments, decides whether to respond, runs model inference, executes actions, persists the response, runs evaluators, and emits lifecycle events.