What Is an Agent Plugin? The New App Layer for Agents
An agent plugin is an installable package of Skills, tools, and integrations for an agent harness. Learn how plugins relate to Skills and how to measure them.
An agent plugin is an installable package that extends an agent harness with reusable capabilities. A plugin can include one or more Skills, tools or MCP configuration, hooks, connectors, UI resources, or agent definitions. If an agent harness is an operating system, a plugin is an app installed on it.
Codex, Microsoft 365 Copilot Cowork, Claude, OpenClaw, Hermes Agent, and other harnesses use different package shapes, but the product shape is converging: users install a plugin; the harness activates its capabilities as work requires them. The opportunity for builders is to maintain one plugin product and deploy it through the adapters each harness expects.
Plugins and Skills
A plugin is not a replacement word for every Skill. It is the product that packages and distributes Skills:
| Layer | What it represents | Example signal |
|---|---|---|
| Plugin | The installable app a team publishes and manages | install, update, adoption |
| Skill | A task-specific capability inside the plugin | invocation, error, latency, outcome |
| Tool or connector | Access to an external action or data source | tool call, auth or dependency failure |
| Component directory | A package surface such as skills/, hooks/, .mcp.json, monitors/, or bin/ | validation, scan, runtime availability |
| Harness adapter | The package shape for Codex, Copilot Cowork, Claude, OpenClaw, Hermes, or another runtime | deployment, version drift, runtime health |
A plugin may initially contain a single Skill. As it grows, it can expose several capabilities while remaining one installed product.
Why plugin and Skill improvement matters
An installed plugin is only useful if its capabilities work in real tasks, across the surfaces where users run agents. Builders need three views:
- Distribution: which plugin versions are installed, retained, updated, or abandoned.
- Deployment: which harness adapters are live, stale, or failing.
- Execution: which Skills are invoked, how often they succeed, where they fail, how long they take, and whether a new release improved outcomes.
Telvine is built for that loop. It keeps the plugin product, component inventory, harness adapters, versions, directories, telemetry, eval evidence, and promotion decisions together. It instruments SKILL.md capabilities and accepts typed package/component events for observable connectors, hooks, MCP config, apps, agents, or directory-level packaging work without collecting prompts or file contents.
Start measuring a plugin capability
If your plugin contains a Skill, use Telvine-backed distribution and metrics to publish the plugin and instrument its capability telemetry:
npm i -g @telvine/cli@0.1.0
telvine login
telvine publish ./my-plugin
This records capability behavior while preserving the plugin as the app-level object you ship across harnesses. For richer plugin systems such as Claude, also record the component directory and manifest field so you can compare skills/, hooks/, .mcp.json, monitors/, and other package surfaces without sending file contents. See plugin components for package inventory and non-Skill telemetry.