Most people still judge agents by model quality.
The installable layer is what actually compounds.
That is the gap in the Hermes plugin story. The headline reads like a feature drop. The real event is distribution: agent capability finally has a format you can install, govern, and hand to someone else without rebuilding from a thread.
The headline reads like a feature drop.
I have been running agent workflows on this stack for months. I maintain awesome-hermes-agent, a map of what is installable that grew with the ecosystem. This article is that map at course depth - written from a running operator stack, not a feature recap.
This article will explain:
- Why plugins are the App Store moment for agents, not another tool type
- The full extension stack (tools, skills, MCP, cron, plugins) and where each layer belongs
- A four-gate test for when something should become a plugin
- How to spec, ship, and govern a plugin other people will trust
Part 1 · The shift from chat plus tools to installable capability
The first generation of agents was a model in a loop with a few tools bolted on. Call an API, run a shell command, hit search. Powerful, but every builder wired it from scratch. Your scraper was your scraper. Mine was mine. Nothing transferred.
The first generation of agents was a model in a loop with a few tools bolted on. Call an API, run a shell command, hit search. Powerful, but every builder wired
That is the pre-App-Store world. Lots of capability, zero distribution.
The iPhone was powerful before the App Store. The App Store made it a platform. Agents are approaching the same moment. The winning question is no longer "can this agent answer?" It is "can this agent install, govern, reuse, and share a capability?"
The second wave is different. A plugin packages a workflow once. You install it. The tool bindings, permissions, opinionated defaults, and verification hooks travel as one unit. That is the phase change.
Hermes Agent already describes the operating surface this requires: memory across sessions, skills, tools, cron scheduling, messaging gateways, MCP integration, subagents, and project context. Plugins do not become valuable in isolation. They become valuable when there is a host that can register tools, enforce permissions, isolate credentials, trigger workflows, deliver outputs, and inspect failures.
If the host is just a chat box, plugins are decorations. If the host is an operating layer, plugins are distribution.
The compounding move: every time you rebuild a workflow from scratch, you pay the full setup tax again. Every time you install a plugin with a verifier and a stop rule, tomorrow's run starts closer to done. That is why the installable layer matters more than model upgrades for operators who run the same jobs weekly.
Part 2 · The extension stack (what each layer actually is)
People use "plugin," "skill," "tool," "MCP," and "cron" interchangeably. They are not the same thing. Knowing the difference is the whole game.
People use "plugin," "skill," "tool," "MCP," and "cron" interchangeably. They are not the same thing. Knowing the difference is the whole game.
| Layer | What it packages | Best for | Failure mode |
|---|---|---|---|
| Prompt | one instruction | one-off behavior | forgotten next session |
| Skill | reusable procedure | review, writing, launch flows | vague trigger or bloated context |
| Tool | direct capability | search, shell, API, browser | too much power without policy |
| MCP server | external tool surface | shared services and integrations | tool sprawl |
| Cron job | scheduled run | monitoring, reminders, recurring research | stale automation |
| Plugin | packaged capability set | installable workflows, config, policy | unclear boundary |
| Dashboard/gateway | approval and delivery | human-in-the-loop operations | approved confused with executed |
A skill teaches the agent how to behave. A tool lets it do something. MCP exposes external capabilities. Cron tells it when to run. A plugin packages a capability so someone else can install and operate it.
That is the App Store move.
What makes a good plugin is not what makes a good tool
When distribution shows up, the design problem changes. A good tool does one thing. A good plugin makes a decision for you.
The best plugins in this wave will carry opinion:
- A permission boundary. What this thing can and cannot touch. In my own operator setup, every external write routes through a content guard before it can post. A plugin that ships capability without guardrails is a liability, not a product.
- Opinionated defaults. The point of installing someone else's plugin is that they already made the fifty small calls you would have gotten wrong.
- A packaged workflow. Not "here is an API client." Instead "here is the whole job, done the way someone who does it for a living would do it."
Anthropic's team made the same argument on stage recently: do not build agents, build skills. A skill is the method. The plugin is how the method travels. Wrap a proven skill in a plugin and you ship expertise, not just access.
The mechanism: what happens when a plugin installs
This is the part most feature recaps skip. A plugin is not a zip file the model reads. It is a contract between a host and a workflow.
When installation succeeds, four things bind together:
- Tool registration. The host exposes named capabilities to the agent loop. Search, shell, API clients, browser actions. The plugin author decides which tools exist and what each one is allowed to call.
- Permission envelope. Credentials stay scoped. A social monitoring plugin might read timelines but cannot post without an approval gate. A deploy plugin might run tests locally but cannot push to production without a human ack.
- Default config. Time windows, output formats, retry limits, quiet hours. These are the fifty small decisions that separate a demo from an operator tool.
- Verification hook. After execution, something other than the model confirms success: a URL exists, a test passes, a metric moved, a file landed in the expected path.
Without all four, you have a skill folder with marketing. With all four, the next builder installs your loop instead of reinventing it. That is the mechanism behind the App Store analogy. Distribution only works when the host enforces the contract.
Part 3 · Do you actually need a plugin? Run this test first
Most articles sell you the plugin before they tell you when it is a mistake.
A plugin earns its cost only when all four of these are true. Miss one and a skill or local script is cheaper.
| Gate | Question | If no |
|---|---|---|
| Repeat | Does this workflow run at least weekly? | keep it as a one-off skill |
| Setup | Does it need credentials, config, or install steps? | a prompt may be enough |
| Distribution | Will someone else install this without your repo? | keep it project-local |
| Governance | Does it touch external systems that can fail silently? | add harness before plugin |
The honest take: plugin packaging is real, and most builders do not need it on day one. Start as a skill inside your project. Promote to a plugin when installation, configuration, permissions, or distribution become the bottleneck.
Use this decision table when you are unsure:
| Question | If yes | If no |
|---|---|---|
| Does it need credentials or setup? | plugin candidate | skill or prompt may be enough |
| Does it expose tools to other workflows? | plugin candidate | local skill may be enough |
| Does it need repeatable config? | plugin candidate | script may be enough |
| Does it need approval states? | plugin plus dashboard | tool may be enough |
| Does it need distribution to other users? | plugin candidate | keep it project-local |
Miss the repeat gate and you are packaging a one-off. Miss the governance gate and you are shipping a liability with a README.
Part 4 · What great Hermes plugins look like (with examples)
The best plugins will not be thin API wrappers. They will be packaged operations.
A good plugin says: here is the workflow, here are the tools, here are the permissions, here is what gets stored, here is what needs approval, here is how you verify execution.
| Plugin idea | What it packages | Why it matters |
|---|---|---|
| X intelligence plugin | search, monitor, draft, approve, post verification | turns social into an ops loop |
| Founder CRM plugin | contacts, outreach, follow-ups, notes, reminders | keeps sales out of chat logs |
| Agent observability plugin | traces, costs, tool calls, failure modes | makes agent work inspectable |
| Launch command center | content, analytics, replies, milestones | connects distribution to execution |
| Security review plugin | read-only scans, reports, severity gates | safer automation before deploys |
| Solana builder plugin | program patterns, RPC checks, wallet safety | domain-specific agent defaults |
The pattern is clear. A plugin should reduce the number of decisions a user remakes every session.
This is also why curated ecosystems matter. A list of random repos is not enough. Builders need maps: what to install, what to trust, what belongs in a skill, what belongs in a plugin, what needs approval, what can run on cron. That is why I maintain the awesome Hermes list linked above. The work is not collecting links. It is turning the ecosystem into an operating map.
Part 5 · The approval problem (state machines plugins must respect)
Plugins raise the stakes. Once agents can install capabilities, touch APIs, run on schedules, and deliver messages, approval state becomes critical.
Drafted is not approved. Approved is not executed. Scheduled is not posted. Posted is not verified.
This sounds obvious until your dashboard says "scheduled" and the user thinks it means "done."
| State | Meaning | Evidence |
|---|---|---|
| drafted | the agent prepared an action | draft text, target, context |
| approved | a human accepted the exact action | approval record |
| scheduled | execution is queued | run time, job ID |
| executed | action ran | API response, post ID, deploy result |
| verified | outcome exists in the world | URL, smoke test, analytics event |
Plugins should respect this boundary by default. Otherwise the ecosystem becomes a prettier way to create silent failures.
In my system, every scheduled external write carries an idempotency claim before the API call fires. If a cron retries, it cannot double-post. That pattern belongs inside any plugin that touches messaging or publishing. The host should enforce it. The plugin author should document it. The installer should not have to discover it after an incident.
Part 6 · The developer opportunity (what to ship first)
If you are a builder, this is early. The next wave of useful agent projects will not be "chat with PDF" clones. They will be installable operating modules.
Small, sharp plugins that do one workflow well:
- turn GitHub issues into reviewed implementation plans
- turn meeting transcripts into owner-assigned follow-ups
- turn ranked reply opportunities into approved outreach drafts
- turn repeated Claude Code failures into skills the loop can reuse
- turn analytics gaps into daily operating decisions
The edge is not raw model access. Everyone will have that. The edge is packaging a workflow so the agent can run it safely again tomorrow.
In my own stack, thirty-five cron jobs run without a human in the room because each one is a defined loop with a verifier, not a hopeful prompt on a timer. That is harness plus loop engineering applied to real operator work. Plugins are how those loops become installable for the next builder.
Ship narrow before you ship broad. One workflow, one verifier, one permission boundary, one README that a stranger can follow without your Slack context.
Part 7 · Try it yourself (plugin spec template)
You do not need to publish to Hermes to design like a plugin author. Paste this into any doc and fill it in for one workflow you run weekly:
PLUGIN SPEC - [name]
PURPOSE (one sentence):
What recurring job does this replace?
TOOLS (list):
Which capabilities does it register?
PERMISSIONS (allow / deny):
What can it never touch without human approval?
DEFAULTS (3 - 5 bullets):
What decisions are pre-made for the installer?
Verifier:
How does a run prove success without the model's opinion?
Stop rule:
When does it stop trying?
State file:
What persists between runs so tomorrow resumes instead of restarts?
If you cannot fill VERIFIER and STOP RULE, you have a skill, not a plugin yet. Fix those first.
Agent Extraction Layer
Objective: Turn a recurring agent workflow into an installable, governable capability another operator can trust.
Inputs: A weekly job definition, required credentials, tool list, approval policy, and one example of a successful run with evidence.
Process:
- Run the workflow manually once and capture the exact steps the agent took.
- Extract stable decisions into DEFAULTS (formats, thresholds, quiet hours).
- Define PERMISSIONS as allow/deny lists, not vibes.
- Write VERIFIER as a check that does not depend on model self-report.
- Write STOP RULE as a hard budget (retries, time, cost, or human escalation).
- Package the skill procedure plus tool bindings as the plugin manifest.
- Test install on a clean project with no author context present.
Outputs: Plugin spec, scoped credentials, state file schema, approval state machine, and a README another builder can follow without your repo history.
Guardrails: No external write without approval gate. No cron without idempotency claim. No "installed" label without a passing verifier on a dry run. Reject plugin candidates that fail the four-gate test in Part 3.
Part 8 · The honest part
Plugins change incentives. They do not remove judgment.
Two problems get sharper as installable capability spreads:
Comprehension debt. The faster you install workflows you did not design, the larger the gap between what runs in your repo and what you can debug. A smooth plugin stack charges compound interest on that gap.
Governance theater. It is tempting to treat "installed" as "safe." Designing permissions with intent is the cure when you do it with judgment. Checking a box because the README said "secure" is how you wake up to a cron that posted the wrong thing.
When should you NOT build a plugin? When the workflow is still changing weekly, when only you will ever run it, when you cannot name a verifier, or when the real bottleneck is context quality inside a single session. Those are skill problems. Fix the procedure first. Package later.
Every ecosystem needs three things to ignite: a way to build, a way to distribute, and a reason to trust what you install. Agents have had build for a while. Plugins add distribution. Governance adds trust. When all three land, the smart move flips from "build everything yourself" to "build only what only you can build, install the rest."
The first wave rewarded people who could wire up tools. This wave rewards people who package a workflow other people will install and trust.
The prompt is one input. The installable workflow is the product.
your next action: pick one recurring job you ran manually twice this week. Fill the plugin spec template above. If VERIFIER and STOP RULE are solid, that spec is your v0 README.
Which layer in your stack is still a one-off script that should become installable?
I started a private Telegram channel where I share insights and updates regularly: https://t.me/+PE3m-F1jlwVmNjcy
Follow me on X for the daily build in public: @nyk_builderz
Follow @nyk_builderz for AI agent systems, Solana infrastructure, and build-in-public.
- Site: nyk.dev
- GitHub: 0xNyk
- RPC Edge: rpcedge.com