AI workers for Hermes.
Hermes is the agent you run yourself, and it answers wherever you already talk. WorkerKit gives it a fleet to operate: background workers scoped to one job each, carrying their own instruction, memory, schedule, budget and app grants on hosted runtime rather than on your machine. Two entries in one YAML file put all of it in reach, each run comes back as a short costed digest, and the schedules hold while your gateway is down. Setup takes about a minute of your time.
What Hermes is
The agent you run, wherever you run it.
Hermes Agent is Nous Research's autonomous agent runtime, open source under the MIT licence: a Python agent loop with persistent memory, scheduling, terminal, browser and file tools, a messaging gateway, and a skills system it can write for itself. It installs on Linux, macOS, WSL2, native Windows, Nix and NixOS, Docker, and Android under Termux, and Nous Research also runs it as Hermes Cloud for people who would rather not keep a process alive at all.
It is not one chat window. The same agent, with the same memory, answers across more than twenty messaging surfaces, Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost, Email, SMS, Microsoft Teams and Google Chat among them, plus a CLI, the native Hermes Desktop app and a local web dashboard. It speaks the Model Context Protocol on both sides: as a client that connects out to remote servers, and as a server other clients connect to.
One disambiguation before anything else, because the names collide. Nous Research also publishes the Hermes family of open-weight language models. Hermes Agent is the runtime that shares the name, and the runtime is what this page is about; which model it thinks with is a separate choice you make.
| What a fleet adds | Why it helps |
|---|---|
| Work that outlives the process | A Hermes agent answers while its gateway is up. A WorkerKit worker runs on hosted runtime, so a closed laptop, a restarted container or a machine you are migrating does not take the schedule down with it. |
| A grant per job, not per agent | Every credential in config.yaml belongs to the whole agent. A worker holds its own narrow grant instead, so the reach of one job is never the reach of all of them. |
| A session per job | One Hermes agent has one memory that everything shares. Each worker runs sealed in its own context, on a model chosen for that job, and hands back only the digest. |
| A receipt per run | Every run settles its exact model cost inside the budget you set for that worker, so background work is a line item rather than a habit. |
Hermes is good at the work you are in the room for, and that is where it should stay. A fleet beside it takes the standing jobs: the ones that must keep their schedule when your laptop closes, hold their own app access rather than borrowing the agent's, and report a paragraph rather than a screen.
Hired specialists
What a worker adds beside Hermes.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so Hermes never has to stay awake for them.
| Aspect | Hermes | A WorkerKit worker |
|---|---|---|
| Context | One agent with one persistent memory, shared by every channel it answers on | Its own, sealed per run; only the digest returns |
| Where it runs | The machine you installed it on, or a Hermes Cloud instance you deployed | WorkerKit's hosted runtime, with no process of yours to keep alive |
| Model | The model you configured the agent to think with | Chosen per worker from any supported provider, or your own provider key |
| Identity | The credentials in config.yaml and .env, which the whole agent shares | Its own key, with an explicit grant per app, read-only by default |
| When it runs | Its cron schedules and its messaging gateway, while the process is up | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | A reply on the channel you spoke to it on | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| What it learns | Skills it writes for itself in ~/.hermes/skills/, and memory it keeps as it goes | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Remove the server entry, or stop the gateway | Disable or revoke one worker; nothing else moves |
The operator pattern
Hermes operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in plain language, on whichever surface you are already on. "Which workers ran today?", "Run the invoice chase now", "Pause the scanner." |
| 2 | Hermes | Reads its key's scopes first with key_info, picks the matching tool from the fleet mount, and follows the operating rules in its WorkerKit skill. |
| 3 | The worker | Executes in its own context, on its own runtime, on its schedule or on demand. |
| 4 | Both | Hermes reads the result with runs_feed and run_get and answers on the channel you asked from: one connection covers the whole fleet, and the run's receipt carries the digest, the typed structure when the run produced one, and the settled cost. People receive it through the worker's delivery channels. |
Hermes becomes the fleet operator, and it does it from wherever you already talk to it: a terminal, the desktop app, or a Telegram thread on a phone. The workers do the unattended work, Hermes does the thinking about it, and the interactive work workers are not for stays exactly where it is.
Why Hermes and WorkerKit
Each one covers what the other is not for.
Use Hermes for the agent you own, the one that lives where you put it and answers where you already are. Use a WorkerKit worker for run unattended against my apps, on a schedule, with its own grant, and deliver to Slack.
| Hermes strength | What WorkerKit adds beside it |
|---|---|
| Open source under MIT, and yours to run | A hosted fleet beside it, so the standing jobs need no process of yours to stay alive and no machine of yours to stay awake |
| One agent across more than twenty messaging surfaces | Workers that deliver on their own to email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, so a report reaches people who never talk to your agent |
| Skills on an open standard, installed from a URL | A WorkerKit skill file at a stable address, so teaching the agent the fleet is one hermes skills install |
| A full MCP client, request headers and all | Two streamable-HTTP mounts, the public catalog and your fleet, live on the next reload |
| Persistent memory that spans every channel | Memory scoped to a JOB instead, carried across that worker's runs, and approved by you before a run may use it |
| Terminal, browser and file tools on your own machine | Pre-scoped grants into business apps, behind a firewall that checks, masks and logs every tool call |
What it unlocks
Background work that stays out of the chat.
Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest comes back. A long crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
- The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
- Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
- Standing monitors and briefings Workers watch on a schedule and report only what is new, so you stop relying on remembering to ask.
- Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer.
- Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
- Kits: install one or make your own Browse the catalog, install a ready-made worker, or author your own through the authoring guide, the validator and the publisher. Every path runs the same validators.
- Fleet operations Clone a tuned worker for the next client, set budgets, route deliveries, and start and stop workers, all from the assistant you already talk to.
- Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
- Auditable trails Every run leaves a typed event stream, liveness heartbeats, owner and self scores, and the allow or redact outcome of each tool call underneath it.
What the two mounts expose
A public catalog, and your fleet.
WorkerKit publishes two mounts over streamable HTTP. The catalog is public, so it is never walled behind a sign-in; the fleet is yours, so it is never anonymous.
| Mount | Address | What it carries |
|---|---|---|
| Directory | https://mcp.workerkit.ai/directory | The public kits catalog: 9 read-only tools, including what WorkerKit is and when to use it, written for an agent, plus the guide, the vocabulary and the app-by-app tool explorer a kit is written from. No key at all, so the catalog can be browsed before anyone signs in. |
| Workers | https://mcp.workerkit.ai/workers | Your fleet and authoring on one connection: 91 tools in the full profile (84 manager tools plus 7 public discovery reads), or 20 tools in the decision profile. Discover sources, create classifiers, run and configure workers; the full profile also includes fleet administration, publishing and connection management. A manager key on the header, and the key's scopes are exactly its reach. |
| Area | Tools | What it covers |
|---|---|---|
| Key | key_info | What your key is and exactly which scopes the other tools will honour. Call it first. |
| Fleet | workers_list, worker_get, worker_set_enabled, worker_permissions_get | Every worker with live run state, one worker in full, start or stop, and what a worker may touch, read-only, in the same vocabulary a kit is written in. |
| Runs | worker_run, run_bulk, worker_runs, run_get, run_events, run_transcript, run_cancel, run_score, run_clear_digest | Trigger a run with a prompt for that run, or one prompt across up to 20 workers; watch it step by step, read the receipt and the stored process log, cancel or grade it. On a decision worker it decides instead and acts on what it routes: sourceArgs and maxItems narrow and cap what is judged, and waitSeconds waits for the settled receipt, which carries the per-item decisions. |
| Fleet activity | runs_feed, fleet_pulse, fleet_health, account_usage | Every worker’s runs in one feed, everything running right now, what is quietly wrong across the fleet, and the account’s headroom before you spend a slot or a run. One call each, instead of asking each worker in turn. |
| Two-way runs | run_question, run_answer | A run that needs an answer ends by asking; the answer starts a linked follow-on run. |
| Memory | memory_get, memory_add, memory_update, memory_delete | The rules and facts a worker carries into every run. |
| Schedules | schedules_list, schedule_create, schedule_update, schedule_delete | When a worker starts on its own, in its own time zone. |
| Instruction | instruction_get, instruction_set, instruction_versions, instruction_version_get, instruction_restore | The standing instruction, versioned on every change, with the history to compare against and roll back to. On a decision worker it reads the routing table and the install questions instead, and writes their answers. |
| Deliveries | delivery_list, delivery_channels, delivery_create, delivery_update, delivery_secret_rotate, delivery_delete | Where a run report goes when the worker finishes: email, Slack, Teams, Telegram, Notion, Discord, SMS or a signed webhook. |
| Deployment | models_list, deployments_list, deployment_get, worker_deploy, deployment_update, worker_undeploy | What makes an installed worker actually run: pick its model from the priced catalog, cap its spend, pause or resume it, take it off again. A worker with no deployment fires no schedule and refuses a run with not_deployed. |
| Budgets | budget_get, budget_set, fleet_budget_get, fleet_budget_set | A worker’s spend and run ceilings, and the account-wide fleet ceiling. Their own scope, because raising a dollar cap is the one management action that can cost money. |
| Creation | worker_clone_preview, worker_clone, worker_clone_bulk | Clone a worker into new ones, singly or in bulk, with a dry run first. A clone carries only permissions a person already approved on the source. |
| Deletion | worker_delete | Remove a worker for good, with its sub-workers. Permanent, where stopping one is not — which is why it is a scope of its own. |
| Kits | kit_install_preview, kit_install | Preview a directory kit against your account, then install it as a new worker — with deploy set, in the same call, which is what makes it run. |
| Kit authoring | kit_validate, kit_publish, kit_update, kit_replace, kit_unpublish, kit_relist, kit_make_private, kit_delete, kit_scan_get, my_kits_list, publisher_get_mine, publisher_set | Validate a kit in one dry run that reports every gate at once, publish it from content or from a worker you own, keep it private or list it, and keep your publisher profile. A private kit installed with kit_install is how an agent builds a worker from scratch. |
| Connected apps | apps_list, app_connect, app_disconnect | Which apps an operator can use right now, in the kit vocabulary, and connecting the rest by credential: validated live, stored encrypted, never returned. Browser sign-ins stay on the Apps page. |
| Model keys | model_keys_list, model_key_set, model_key_delete | Your own model-provider API keys, so runs bill your provider account instead of the wallet. |
| Onboarding and wallet | onboarding_get, wallet_get, wallet_checkout_create, wallet_checkout_get | Check model funding, hand off BYOK setup, inspect wallet balance, and request a human-confirmed Stripe checkout. A purchase is complete only when its status is credited. |
| Custom MCP servers | mcp_servers_list, mcp_server_get, mcp_server_create, mcp_server_discover, mcp_server_set_tools, mcp_server_delete | An app the platform does not offer, reached through its MCP server: register it as your own custom MCP app with its credential in the same call, enable the tools a job needs, and bind it in a kit. |
| Decision authoring | decision_worker_create | Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires publishKits and installKits, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. |
| Discovery and authoring reads | workerkit_about, directory_overview, kits_search, kit_get, kit_app_tools, kit_authoring_guide, kit_vocabulary | Public reads also available on the workers connection. Discover classification sources with kit_app_tools(purpose:"decision") and read kit_authoring_guide(section:"decision"). These reads never forward the manager bearer upstream. |
The manager key reaches the fleet only. It grants no access to any connected app: workers reach apps under their own grants and firewall, and no prompt can widen that.
The same two mounts answer every other MCP client, and the same fleet answers the REST API for hosts that speak plain HTTPS instead.
Classification on demand
Create a decision worker from your questions.
Categorize, score or triage connected data, then reuse and adjust the worker.
Reuse an existing worker or decision kit when its questions fit. For a custom classification task, creation compiles a supported source recipe and typed questions into a private kit and an installed decision worker. Optional deploy:true adds deployment; creation never starts a run or adds a schedule. The kit can be edited and published later through the normal kit lifecycle.
On the workers connection, call kit_app_tools(purpose:"decision") for recipes, argument schemas, permissions and examples, then kit_authoring_guide(section:"decision"). Check account connections with apps_list; public discovery does not check them. Send the request to decision_worker_create, follow nextCall, then use worker_run and run_get. Running needs runWorkers; results need readRuns. Use instruction_get / instruction_set for saved category or level answers, or answers on one run. Structural question/source changes need a revised kit and a replacement install. Check receipt status, coverage, omissions, warnings and cost before claiming completion.
Start with email-previews, calendar-events or sheets-rows. These recipes return judgments without app writes. Email previews do not include full threads; calendar events are invitation data, not transcripts; Sheets needs a Google file ID, a finite tab-qualified range and a columns map. A connected app alone does not make every tool a supported source. Source filters select evidence, not permissions: the Sheets recipe grants spreadsheet reads across the linked Drive account.
Supply 1–8 questions: choice with named options, score with ordered levels, or noul for the probability of a statement. Choice adds unclear automatically. Set an explicit confidenceFloor between 0 and 1; it routes uncertainty and does not promise accuracy. maxItems is 1–50, default 20. Creation requires publishKits and installKits; optional deployment also needs manageDeployments.
Use a fresh requestId for each new worker. Retry with the same ID and identical body to recover the original receipt; a changed body returns 409. The response includes tokenId for MCP/CLI worker commands, stable workerId, kitSlug, readiness and nextCall. A deploymentError means the worker already exists: fix deployment on that worker. The receipt is a snapshot; check current worker readiness before running. No worker API secret is returned.
The workers connection includes discovery and authoring, so classification needs one MCP connection. Its full profile has 91 tools (84 manager tools and 7 public discovery reads); only decision_worker_create is new. For a smaller list, a client that supports custom headers can send X-WorkerKit-Profile: decision on every request, including initialization, listing and calls, to select 20 workflow tools. A server operator can instead set MCP_WORKERS_PROFILE=decision. The endpoint and existing sign-in stay the same; a profile grants no additional permissions. Reconnect and relist after changing profiles. Use the advertised tool list: fleet administration, publishing and event-stream tools require the full profile. Successful responses include structured content and a text fallback; creation declares an output schema.
Access and control
Scoped per worker, and scoped for Hermes too.
| Layer | What it holds |
|---|---|
| Per-worker grant | You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted. |
| The app firewall | Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed. |
| Prompt injection | A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed. |
| The assistant's own access | A manager key carries explicit scopes, is shown once and stored hashed. It reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM. An agent reads its scopes before planning, and an admin can revoke the key at any time without touching a worker. |
A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.
How it connects
Two entries in one YAML file.
Hermes reaches a remote MCP server by URL, and headers beside that URL is an ordinary mapping of request headers. So the catalog mount is a url and nothing else, and the fleet mount is that same entry with one Authorization header carrying a manager key you keep in ~/.hermes/.env. Nothing to register, nothing to pre-approve, and no refresh cycle to maintain.
Nous Research recommends exactly this over its own OAuth mode for a remote gateway, in as many words: "always prefer headers.Authorization: 'Bearer <token>' when the user is willing. Simpler, no refresh dance." The WorkerKit fleet mount is an OAuth 2.1 authorization server as well, so the other path is open; on this platform the header is the one the vendor points at.
The whole procedure, written for the agent doing it, is the setup guide. The human's part is creating one key and pasting it into an env file once.
The same fleet answers from anywhere else you work: any other MCP client, the wk CLI in a terminal, and the REST API for hosts that speak plain HTTPS. The fleet outlives the choice of assistant.
Hermes runs on a machine you control and carries terminal tools, so it can run wk directly as well as speak MCP. The commands are generated from the same tool definitions the MCP server serves, so neither surface is a subset of the other: what an agent can do over MCP, a shell can do. The wk CLI is the reference, and the setup guide carries the step.
Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. Connecting Hermes is not a paid feature, and the plans are on the pricing page.
Questions
Hermes and WorkerKit, answered.
- Is this the same Hermes as the Hermes models? No, and the two are worth separating. Nous Research publishes both: the Hermes family of open-weight language models, and Hermes Agent, the MIT-licensed agent runtime you install and run. This page is about the runtime. Which model it thinks with is your choice, and a WorkerKit worker picks its own model per worker either way.
- Where do I set this up, and does Hermes Cloud work? In `~/.hermes/config.yaml`, on an install you control: the gateway on Linux, macOS, WSL2, native Windows, Nix, Docker or Android under Termux. The CLI registers a server too (`hermes mcp add <name> --url <url> --auth header`), though Nous Research documents no flag for the header value, so that path finishes in the YAML as well. The local dashboard and Hermes Desktop both manage MCP servers, and the vendor documents their MCP form as taking a URL, a command, arguments and environment variables rather than custom headers. Hermes Cloud is real managed hosting from Nous Research and a cloud agent is a real Hermes agent, but how an MCP server is configured on a cloud deployment is not documented today, so this guide promises the connection on an install you control and does not guess at the rest.
- Do I have to paste a key anywhere? Once, into a file on your own machine. An admin creates a manager key at workerkit.ai/fleet-access, puts it in `~/.hermes/.env`, and config.yaml references it as a variable rather than carrying the secret itself. That keeps the key out of the file people copy, paste into a support thread or commit, and it never travels through a message to the agent.
- Should I use OAuth instead of a static header? On this platform, no, and that is the vendor's advice rather than ours: "always prefer headers.Authorization: 'Bearer <token>' when the user is willing. Simpler, no refresh dance." Nous Research documents why. Hermes registers a 127.0.0.1 callback, which resolves to the browser you are sitting at rather than to the machine the gateway runs on, and an expired refresh token on a remote gateway can need a restart rather than a reload. The WorkerKit fleet mount does publish OAuth discovery, so the option stays open for anyone who wants it.
- Can Hermes read my email or CRM through WorkerKit? No. The key in your config file carries fleet scopes and nothing else, and no scope on it opens a mailbox, a calendar or a CRM. An app is reached by the worker that was granted it, per app and read-only unless you widened it, behind the firewall that checks, masks and logs each call. So what Hermes can do and what a worker can do never meet, whatever anything it reads tries to talk it into. It is also why the key belongs in .env rather than in a config file that gets copied.
- What does Hermes need to set this up? A WorkerKit account with admin access, a manager key created at workerkit.ai/fleet-access, write access to `~/.hermes/config.yaml` and `~/.hermes/.env`, and the WorkerKit skill file at workerkit.ai/hermes/SKILL.md. The person's part is about a minute: create the key and paste it into the env file once. Hermes writes the YAML, reloads, verifies its scopes with key_info, installs the skill and runs a smoke test.
- How does Hermes get a worker's results? Two paths. Hermes reads them with runs_feed and run_get and answers on whichever channel you asked from: one connection watches every worker on the account, and each run's receipt carries the closing report, a typed digest when the run produced one, and the settled cost. People receive them through the worker's own delivery channels: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook, which is how a report reaches someone who never talks to your agent.
- I connected it and the fleet is empty. What now? That is the expected state of a new account, and the connection is already proved. A kit is a ready-made worker, so filling the fleet is one install. Open any kit at workerkit.ai/kits and install it from the page, which needs no scope on the key at all. Or, with installKits on the key, ask Hermes on whichever channel you are already in: it shortlists with kits_search, shows you exactly what the new worker would be allowed to touch with kit_install_preview, and installs it with kit_install once you say yes. Then have it run the worker once and read you the receipt.
- What does it cost? WorkerKit has a Free plan with no card required: 5 workers, 500 tool calls a day and the complete safety layer. A run pays for its model tokens at the provider list price with no markup, drawn from a prepaid wallet or from a provider key of your own, and never past the per-worker and fleet ceilings you set. Connecting costs nothing on either side: Hermes Agent is MIT-licensed and free to run, and nothing here asks for Hermes Cloud or Nous Portal credits, which are Nous Research's own products.
The setup guide is written for the agent doing the work, the MCP server page holds the surface behind it, and the wk CLI reaches the same fleet from a terminal.