The WorkerKit CLI.
One binary, wk, and your whole worker fleet is in the terminal: runs, schedules, memory, instructions, and the public kit directory without an account. Open source under MIT, installed from npm or Homebrew.
The commands
Everything the fleet does, as commands.
Commands are generated from the same tool definitions the MCP server serves to agents, so nothing here is a subset: what an agent can do, a shell can do.
| Commands | What they cover |
|---|---|
wk auth login / wk onboarding / wk wallet | Start or resume browser-approved account signup and login from a headless machine, inspect funding requirements, and request a Stripe checkout for the person to pay. JSON output never contains a login credential. |
wk about | What WorkerKit is and when to use it, written for an agent: the request shapes that call for a worker, how a fleet is operated, the access model, the money rules, and how to connect. No sign-in needed; the first command an agent should run. |
wk workers | The fleet: every worker with its live state, one worker in full, start and stop, what it may touch, its spend ceilings, and cloning it into new workers. |
wk run / wk runs / wk fleet | Trigger a run with a prompt for that run, watch it step by step, read the receipt, cancel or grade it; answer a run that ended by asking a question; the account-wide run feed, everything in flight, and the fleet ceiling. On a decision worker wk run decides instead and acts on what it routes: --source-args and --max-items narrow and cap what is judged, and --wait-seconds waits for the settled receipt and its per-item decisions. |
wk memory / wk instruction | The rules and facts a worker carries into every run, and its standing instruction, versioned on every change with the history to roll back to. On a decision worker wk instruction get reads the routing table and its install questions, --options-for lists one app pick's live options, and wk instruction set --answers fills them. |
wk schedules / wk deliveries | When a worker starts on its own, in its own time zone, and where its run report goes when it finishes. |
wk kit / wk publisher | The public directory: search kits, read one in full, preview an install against your account, then install it as a new worker. And authoring: explore what every app lets a worker do, read the guide and the vocabulary, validate, publish a kit of your own (private first), and keep your publisher profile. |
wk apps / wk model-keys / wk mcp-servers | Which apps your operator can use and connecting the rest by credential; your own model-provider keys; and registering an MCP server as your own custom MCP app when the platform does not offer the app. |
wk decision sources / wk decision guide / wk decision create | Discover classification recipes and create a private kit plus decision worker from typed questions. Read JSON from --file or stdin; optionally deploy, never run automatically. Reuse the returned worker with the existing deploy, run and instruction commands. |
- npm
npm install -g @workerkit/cli - Homebrew
brew install workerkit/tap/wk
The directory side needs no account at all: wk kit search and its siblings read the public catalog the way a visitor does. For the fleet, wk auth login runs a browser-approved sign-in: the CLI prints a code, an account admin approves it at workerkit.ai and picks the key's scopes, and the key lands in your OS keychain without ever appearing in the browser.
It is written for scripts and agents as much as for hands: --json is a stable machine contract, --plain strips the chrome, exit codes are documented, and a WK_MANAGER_KEY environment variable carries the key in CI without touching a profile.
The same tool definitions serve AI agents over the WorkerKit MCP server, and the packages themselves live on npm, MIT licensed.
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.
- Discover
wk decision sources --app email wk decision guide - Save as decision.json
{ "requestId": "customer-email-triage-001", "name": "Customer email triage", "source": { "recipe": "email-previews", "args": { "after": "-7d" } }, "questions": [ { "key": "category", "type": "choice", "instructions": "Which category best describes this message?", "options": { "followup": "A customer asks for a reply", "other": "A different topic" } } ], "confidenceFloor": 0.7, "maxItems": 20, "deploy": false } - Create
wk decision create --file decision.json
Run wk decision sources (optionally --app email), then wk decision guide. Save a request as decision.json and use wk decision create --file decision.json, or pipe JSON on stdin. Discovery needs no sign-in; creation uses your manager key. Continue with wk deploy, wk run and wk runs get, using the returned tokenId. Read or update saved answers through wk instruction; read the run receipt 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.