Install vs Evolve: What Plugin Architectures Can't Do

Every major agent framework ships a plugin system. Install a plugin, get a capability. It's clean, it's modular, and it works — until you have 200 plugins claiming to do the same thing and no way to tell which one is actually good. We spent time studying ElizaOS (formerly ai16z/eliza), one of the most mature and widely-adopted Web3 agent frameworks. Not to attack it — ElizaOS has a thriving ecosystem and real production usage — but to understand a deeper question: what can a plugin architecture structurally do, and where does it hit a ceiling? The answer reveals something fundamental about how we should think about agent capabilities. How ElizaOS Organizes Capabilities ElizaOS uses a clean four-part extension model: Component Role Actions What the agent can do — executable behaviors selected by the LLM at runtime Providers What the agent can see — context data injected before each model call Evaluators What the agent learns — post-response processors that extract facts and track goals