AI plugin vs AI worker: what is the difference?
An AI plugin is an installable bundle adding skills, subagents and MCP config to an AI client you drive. An AI worker runs one job unattended, on its own key.
A plugin is a box. An AI worker is a worker. Both are distributed from a marketplace and installed in one click, which is why they get compared, and the resemblance stops at the install button.
The line in one sentence: **a plugin adds capability to a client you are driving, and a worker does a job while nobody is driving anything.**
AI plugin vs AI worker, side by side
| AI plugin | AI worker | |
|---|---|---|
| Installs into | An AI client you use | Your WorkerKit account |
| What you get | Skills, subagents, hooks, MCP config | A configured worker doing one job |
| Identity | None of its own | Its own key |
| App access | Whatever the client already holds | Granted per app at Off, Read or Write |
| Starts | When you invoke it | A schedule, a webhook, or on demand |
| Runs unattended | No | Yes |
| Memory | The session | Facts carried between runs |
| Audit trail | The session transcript | A receipt per run |
| Model | The client's model | Claude, ChatGPT, Gemini or Grok, switchable |
The two rows that decide everything else are starts and identity. Once something starts itself, it needs credentials that are not yours and a record of what it did, and neither is a packaging concern.
What an AI plugin actually bundles
The contents vary by client, but the pattern is consistent. In Claude Code a single plugin can carry:
- skills and slash commands, the instructions an agent loads on demand
- subagents, specialised agents with their own context and token budget
- hooks, code that fires at points in the session lifecycle
- MCP server configuration, so the tools those skills assume are connected
Installing the plugin installs all of it together, which is the point: the pieces in a good plugin depend on each other, and shipping them separately means people assemble something half-wired and then report it as broken.
Plugins are distribution, not capability
This is the sentence worth keeping. **A plugin does nothing a skill or an MCP server could not do.** It solves packaging, versioning and installation.
Which makes "should I write a skill or a plugin?" the wrong question most of the time. Write the skill. Reach for a plugin when several pieces travel together, or when other people need to install them.
And a plugin installs into a client, and a client is a thing a person is using. Whatever it adds is available while you are there.
Where a plugin stops, with a real example
Suppose you build a plugin for your support team: a skill for your reply tone, a subagent that checks the knowledge base, and MCP config for your helpdesk. It is a genuinely good plugin. Every agent on the team now answers tickets in the same voice.
It still only helps when somebody opens the client and starts working the queue.
The worker from the Support Inbox Triager kit is the other half: it connects email and tasks, and on its schedule it classifies and prioritises the support inbox, drafts replies, and files tickets for real issues. Nobody invokes it. The queue is already triaged when the team arrives.
Two more of the same shape:
| A plugin might give your team | A worker that runs without them |
|---|---|
| A CRM subagent and hygiene rules | CRM Scribe logs meetings and email threads into the CRM so records stay current |
| Meeting-prep prompts and templates | Meeting Prep Assistant builds a prep sheet for each meeting from calendar, email, notes and CRM |
What changes when nobody is driving
Three problems appear the moment a thing runs on its own, and none of them is a packaging problem, which is why a plugin format does not address them.
Credentials of its own. A plugin borrows the client's access. A worker holds its own key with its own scope list, so it can be switched off without touching anything else, and it cannot reach an account you never connected.
Restraint the model cannot argue with. Contact rules filter reads and refuse blocked recipients. Redaction strips sensitive values outside the model's reach. An instruction in a bundled skill is a request; these are not.
A record. Every run leaves a receipt: what it read, what it did, what it cost, what it skipped and why.
Where a kit fits
You do not assemble a worker from nothing, any more than you assemble a plugin from nothing. A worker kit is the distribution format on this side of the line: the instruction, the app permissions, the memories and the schedule for one job, already written and tested by a publisher.
So the fair comparison is not plugin against worker but **plugin against kit as packages**, and worker against client as things that run:
| Package | What installing it gives you | |
|---|---|---|
| AI plugin | Skills, subagents, hooks, MCP config | Capability inside a client you drive |
| Worker kit | Instruction, per-app access, memories, schedule | A worker in your account that runs itself |
Use both
The layers compose, and a good setup uses all of them: MCP to reach your systems, skills to encode how your team works, plugins to distribute those skills, and workers for the jobs that should happen whether or not anyone opens an editor. The longer version of that argument is plugins, skills and kits.
FAQ
What is an AI plugin?
An AI plugin is an installable bundle that adds capability to one AI client, packaging skills, subagents, hooks and MCP server configuration into a single unit. It solves distribution: everything a technique needs travels together and installs in one step, into a client a person is using.
What is the difference between an AI plugin and an AI worker?
A plugin adds capability to a client you drive, using the access that client already holds, and it does nothing until you invoke it. An AI worker is an agent set up to do one job unattended: it has its own key, its own per-app permissions, a schedule or a trigger, memories carried between runs, and a receipt for every run.
Is a WorkerKit kit a plugin?
No. A plugin installs capability into an AI client that you drive. A kit mints an AI worker in your own account, with its own key, its own per-app permissions and its own schedule, and that worker does its job unattended.
What is the difference between a plugin and a skill?
A skill is instructions that teach a technique. A plugin is a container that can bundle several skills, plus subagents, hooks and MCP configuration, into one installable unit. Plugins solve distribution; skills provide the capability.
Can a plugin give an agent access to my email or CRM?
Only through the client it is installed in, using the access that client already holds. That is the practical difference from a worker, where you grant access per app and per level (Off, Read or Write), can narrow or revoke it at any time, and the worker keeps running with whatever is left.
Do I need to install anything to run an AI worker?
No. WorkerKit hosts the runs, so there is no agent to install and no machine to keep alive. You connect the accounts the kit asks for and deploy it. Running a worker on your own infrastructure is coming later.
Can I publish a kit the way I would publish a plugin?
Yes. The Kit Creator Studio is a no-code builder, and a published kit gets its own page and a permanent address for life, so updates land on the same URL. Kits can also stay private, on every plan including Free.