AI workers for Hark.
Hark Pro handles the errands of a life from one thread: it books, buys, pays and remembers. A WorkerKit fleet adds the jobs that should happen without anyone asking, such as a morning briefing, an inbox watch or a weekly report, each with its own instructions, app access, model and budget. Hark connects to the fleet over MCP, so it can find a kit, run a worker and bring the result back into the conversation you already have with it.
What Hark is
A personal agent with its own computer.
Hark Pro is the personal AI app from Hark Labs, Inc., released on 2026-10-06 for iOS, Android and the web, free to use with paid tiers for more usage. It works in one persistent chat, remembers what you tell it, and uses Handoff, its own cloud computer, to sign into sites and act for you. Home adds Action Buttons that finish a suggested task with a tap, and Panels, small apps Hark builds over services you connect.
| What a fleet adds | Why it helps |
|---|---|
| Jobs that run without a prompt | Hark acts when you ask or when it spots something. A worker keeps its own schedule in its own time zone, so its report is waiting before you open the app. |
| An identity per job | Hark holds a vault of your logins and cards. A worker holds only the per-app grant its job needs, read-only by default, so a standing job never borrows that reach. |
| A receipt per run | Every run settles its own cost and writes a digest, so ten recurring jobs are ten line items to read rather than ten threads to scroll back through. |
Hark connects to Google Workspace and Microsoft 365 by API, and its launch article says it reaches files, external databases and other information over MCP. That last door is the one that matters here. On 2026-10-06 Hark connected to the WorkerKit fleet mount as a remote MCP server and answered key_info, workers_list, fleet_health, account_usage, onboarding_get and wallet_get on the first call.
Hired specialists
What a worker adds beside Hark.
A worker is a background agent with one job: its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, and Hark reads what comes back and decides the next step with you.
| Aspect | Hark | A WorkerKit worker |
|---|---|---|
| What it is for | Your errands and projects, from one thread that knows you | One job, done the same way every time, with its method written down |
| Where it acts | Handoff, its cloud computer, signed into sites with logins from its vault | Inside the apps granted to that worker alone, under a firewall that checks and redacts every call |
| When it runs | When you ask, on a Scheduled Task, or when it suggests an Action Button | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed webhook |
| What it remembers | You: your preferences, your people, your plans | Its job: rules and facts it proposed and you approved |
| What comes back | A reply in the thread, or a card on Home | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
The operator pattern
Hark operates. Workers work.
Ask Hark in plain language. It reads the fleet over MCP, and every run is its own sealed job.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in the thread: "Which workers failed today?", "Run the morning briefing now", "Pause the price tracker." |
| 2 | Hark | Reads its key with key_info, picks the matching tool, and confirms with you before any run that sends, writes or spends. |
| 3 | The worker | Runs hosted, in its own context, under its own grant, and settles its own cost. |
| 4 | Hark | Reads the receipt with run_get or the fleet feed with runs_feed, then tells you what happened in a few lines and what, if anything, needs you. |
Not sure which job comes first? Hark can search the kit directory by outcome and app. Good first workers: the executive daily briefing, the follow-up tracker or the support inbox triager.
Why Hark and WorkerKit
Each one covers what the other is not for.
Hark is the agent that knows you. The fleet is the unattended, scoped and costed half.
| Hark strength | What WorkerKit adds beside it |
|---|---|
| Handoff signs into thousands of sites and finishes errands end to end | Recurring work that needs no browser and no prompt: a hosted run on a schedule that reports only when something changed |
| Memory that builds a portrait of you across every conversation | Memory scoped to one job, where a fact a run proposes waits for your approval before the next run may use it |
| A vault of logins and cards so it can act for you anywhere | A separate identity per job: its own key and per-app grant, read-only by default and revocable one worker at a time |
| One thread for everything, with no agents to juggle | A fleet of specialists behind that thread, each priced to the token with a receipt, so ten standing jobs stay ten line items |
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. Connect through OAuth or a protected bearer header; the approved scopes control fleet operations and result access. |
| 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, app_github_accounts, app_github_repos, app_github_branches | 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 Hark 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
How Hark connects.
Remote MCP over streamable HTTP. The public catalog mount needs no credential at all. The fleet mount takes a manager key in the Authorization header, the route tested with Hark on launch day. WorkerKit's sign-in flow is not open to Hark yet, so a key is the way in.
The setup guide is written for Hark to follow and for you to approve, in order: the catalog, a narrow key, a scope check, the operating reference, the smoke test, a first worker and reports by email.
Two things to know before you start. Hark asked for the key in the chat when it was tested, so the guide tells you how to keep that key narrow, short-lived and out of Hark's memory. And Hark sends only the Authorization header to an MCP server, so it receives the full tool set rather than a focused profile; the scopes on the key are what bound its reach.
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 Hark is not a paid feature, and the plans are on the pricing page.
Questions
Hark and WorkerKit, answered.
- Can Hark connect to WorkerKit? Yes. On 2026-10-06 Hark connected to the WorkerKit fleet mount as a remote MCP server, over streamable HTTP with a scoped manager key in the Authorization header, and its first calls answered: key_info, workers_list, fleet_health, account_usage, onboarding_get and wallet_get. The public catalog mount needs no key at all.
- Do I have to paste a key into Hark? Today, yes. Hark asks for the key in the chat, and WorkerKit's sign-in flow is not open to Hark yet. So make the key harmless: one created for Hark alone, observer scopes first, with an expiry. Paste it once, ask Hark to forget the text once the fleet answers, and revoke it at Fleet access the moment it shows up anywhere else.
- Can Hark see my email or my CRM through WorkerKit? Not through the key. A manager key reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM. Workers reach apps under their own per-app grants, and a run's receipt can include what the worker found there, so reading results is the part to scope. Hark's own Google and Microsoft connections are separate and granted to Hark directly.
- Why does Hark see every WorkerKit tool? The fleet mount picks a focused tool profile from a request header, and Hark sends only the Authorization header to an MCP server, so it receives the full set. That costs some context on each turn but grants nothing: what Hark can actually do is exactly the scopes on its key, and a refused call names the scope it wanted.
- Will Hark run a worker without asking me? It should not. Hark's own Terms say it asks before it spends your money or sends a message for you unless you tell it otherwise, and the WorkerKit skill tells it to confirm any run that sends, writes or spends. The key is the hard limit: an observer key with readWorkers and readRuns cannot start a run at all.
- What does it cost? Hark Pro is free to use, with Hark Pro² and Pro³ for more usage. WorkerKit's Free plan needs no card and carries 5 workers. Model tokens are billed separately at provider list prices, from a prepaid wallet or on your own provider key, with the small platform fees listed at workerkit.ai/pricing, and every run stays under the ceilings you set per worker and across the fleet. Connecting Hark adds nothing to either bill.
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.