AI workers beside Instinct.
Instinct, at instinct.com, is the personal AI assistant you text or call. As of 2026-09-15 it publishes no MCP server, no connector directory and no inbound API, so there is no connection to make between it and WorkerKit, and this page will not invent one. What does work is mail: each Instinct assistant has its own email address, and a WorkerKit worker delivers its run report to an address like any other. The fleet runs unattended, scoped and costed, and its reports land where the assistant already reads.
What Instinct is
The assistant you text or call.
Instinct is a personal AI assistant from Spear Street Technology, Inc. Its homepage describes "a personal assistant that understands what you're working on and what's important to you", connected to "email, messaging, screen, audio, location, and more", and reached by texting or calling it. It is invite only, and the site says so: it "is currently available to a private access group as we're scaling up compute", by waitlist or an invitation from an existing member.
This is instinct.com, the personal assistant. It is not Instinct Science at instinct.vet, which is veterinary practice software from an unrelated company, and it is not Deep Instinct, which is security software. All three own this search term.
| What a fleet adds | Why it helps |
|---|---|
| Work that runs while nobody is asking | An assistant you text acts when you reach it. A hosted worker keeps its schedule at 6am on a Sunday, in its own time zone, whether or not anyone is awake. |
| A separate identity per job | Each worker holds its own key and its own per-app grant, read-only by default, so a standing job never rides on the access you gave your personal assistant. |
| Output that arrives as mail | Email is a first-class delivery channel, and an email address of its own for each assistant is a vendor feature announced on 2026-09-09. That is where the two meet. |
The direction of its integrations is the fact that decides this page. Instinct reaches outward: the person authorises it to sign into and act inside their own accounts, which its Terms call Connected Services and its Privacy Policy names as Google Workspace over Google OAuth. That is a real integration model and the opposite of the one a third party needs: nothing published lets an outside service register a tool server, a connector or an action. So the useful question is the other one, what is worth having beside an assistant that reads your mail.
Hired specialists
What a worker adds beside Instinct.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so nothing waits on a conversation and no assistant has to be reachable for the work to happen.
| Aspect | Instinct | A WorkerKit worker |
|---|---|---|
| What it is for | One assistant that knows your context and acts for you personally | One job, done the same way every time, with its method written down |
| Where it acts | Inside the accounts you authorise as Connected Services, on your behalf | Inside the apps granted to that worker alone, read-only by default, under a firewall that checks and redacts every call |
| When it runs | When you reach it | 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 in the channel you used | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| What a third party can wire to it | Nothing published as of 2026-09-15: no MCP server, no connector directory, no inbound API | Two MCP mounts, a REST API and a CLI, with OAuth 2.1 and dynamic client registration on the fleet mount |
The operator pattern
Instinct reads. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You, from a surface that connects | Decide what should be watched or chased, then install a kit for it or author one. A kit is a ready-made worker: instruction, app permissions and schedule already written. You do this at workerkit.ai, or from any MCP client, the wk CLI or the REST API, and the manager key lives there rather than in an Instinct message. |
| 2 | The worker | Runs hosted, in its own context, on its schedule, under its own grant, and settles its own cost. |
| 3 | The delivery | The run report goes to the worker's delivery channels, and one of them can be the Instinct assistant's email address. Instinct then reads it the way it reads your mail: what follows is between you and it, the vendor documents no rule you can set from outside, and nothing returns to WorkerKit. |
There is no operator connection here, so the pattern is the honest one: the fleet is driven from a surface that does connect, and Instinct stays the thing you talk to.
Why Instinct and WorkerKit
Each one covers what the other is not for.
Instinct is the assistant that knows you and reaches you anywhere. A WorkerKit worker is the unattended, scoped, scheduled, costed half, and it delivers to an address.
| Instinct strength | What WorkerKit adds beside it |
|---|---|
| You reach it by text or by call, with no new interface to learn | Work that needs no one to reach it at all: hosted runs on a schedule in their own time zone, reporting only when there is something to report |
| It acts inside your own accounts, which you authorise as Connected Services | A separate identity per job: each worker with its own key and per-app grant, read-only by default, narrowed by rules and revocable one worker at a time |
| It has its own email address, so mail is a first-class way in | Run reports delivered as email, which is precisely why the mailbox is where the two meet today with no connector on either side |
| It is one assistant, which is what makes it simple | A fleet of specialists, each with its own memory and priced to the token with a receipt per run, so ten standing jobs stay ten line items rather than ten conversations |
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.
Use this from another connected client, the CLI or the API. This does not add a direct connection to this assistant.
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 Instinct 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
No connector today, and one real bridge.
The plain version, checked twice on 2026-09-15. Instinct publishes no MCP server, remote or local; no OAuth path and no header path; no public REST API; no connector directory, extension store or actions surface. Its sitemap carries a single URL, it publishes no documentation or developer site, and the MCP project's own client list does not name it.
The bridge that does work is mail. Since 2026-09-09 each Instinct assistant has its own email address, claimed at mail.instinct.com, and email is a first-class WorkerKit delivery channel, so a worker given that address reports where the assistant already reads. It is a delivery, not an integration: nobody registers anything and nothing comes back. One thing not to do instead: never hand Instinct a WorkerKit sign-in or a manager key to drive the dashboard with. A credential in a chat is a credential in a log, and an assistant at the controls sits outside the scope model that keeps a key safe.
The things a person can actually do are in the setup guide, in order, ending with what changes the day Instinct opens a door, which is nothing on our side.
Meanwhile the fleet answers everywhere else: any MCP client takes both mounts by URL, and the fleet mount is itself an OAuth 2.1 authorization server with dynamic client registration, so a client that speaks OAuth connects with nothing pasted anywhere. The wk CLI reaches the same fleet from a terminal, and the REST API from any host that speaks plain HTTPS. The fleet outlives the choice of assistant, which is the useful half of an honest not yet.
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 Instinct is not a paid feature, and the plans are on the pricing page.
Questions
Instinct and WorkerKit, answered.
- Can Instinct connect to WorkerKit today? No. As of 2026-09-15 Instinct publishes no MCP server (remote or local), no connector directory, no extension store and no public API, so there is nothing to connect to and no setting to change. Two independent checks on that date looked for each of those and found none published. What does work is email: each Instinct assistant has its own address, and a WorkerKit worker can deliver its run report there like any other recipient.
- Is this the same Instinct as the veterinary software? No, and the confusion is common enough to be worth stating. This page is about instinct.com, the personal AI assistant from Spear Street Technology, Inc. that you text or call. Instinct Science at instinct.vet is veterinary practice software from an unrelated company, and Deep Instinct is a security product. A guide that cites instinct.vet documentation for this product is citing the wrong company.
- Which surface do I set this up on? None of Instinct's, because none of them accepts a connection. The fleet is built at workerkit.ai and operated from any MCP client, the wk CLI or the REST API. The only Instinct-side action on this page is claiming the assistant's own email address at mail.instinct.com, which an existing member does in a browser, and then using that address as a delivery channel on a worker.
- Do I have to paste a key into Instinct? No, and there is nowhere published to paste one. Do not work around that by giving Instinct a WorkerKit sign-in either: a credential in a chat is a credential in a log, and an assistant at the controls of the dashboard sits outside the scope model that makes a manager key safe. Scripting the other way is ruled out too, because Instinct's Terms of Use prohibit automated access to its Services. A manager key belongs in the client that operates the fleet, where it is either approved through the fleet mount's own OAuth flow or held as one Authorization header.
- Can Instinct read my email or CRM through WorkerKit? No, on both halves. WorkerKit holds no connection to Instinct at all, and a manager key reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM, and workers reach apps under their own per-app grants and firewall. Separately, Instinct reaches your accounts through its own Connected Services authorisation, which you grant to it directly and which has nothing to do with WorkerKit.
- What does an agent need to set this up? On the Instinct side, nothing, because nothing connects. On the WorkerKit side: an account with admin access, a manager key created at workerkit.ai/fleet-access or approved through the fleet mount's consent page, and the skill file at workerkit.ai/instinct/SKILL.md, which tells the agent plainly that Instinct is not connected so it does not improvise a procedure. For reports in the assistant's mailbox, you also need its email address.
- How do results come back? Through the worker's delivery channels: email, Slack, Teams, Telegram, Discord, Notion, SMS or a signed webhook. Email is the one that reaches an Instinct assistant, at its own address. Separately, whichever client operates the fleet reads runs_feed and run_get directly, and each run's receipt carries the closing report, a typed digest when the run produced one, and the settled cost.
- I built a fleet and it is empty. What now? That is the expected state of a new account rather than a fault. Install a kit to get the first worker: open any kit at workerkit.ai/kits and install it in one click, or, with installKits on the manager key, let the operating client shortlist with kits_search, preview exactly what the new worker would be allowed to touch with kit_install_preview, and install it with kit_install once you approve. Then run it once and read the receipt.
- What does it cost? WorkerKit's Free plan asks for no card and carries 5 workers, 500 tool calls a day and the whole safety layer. Model tokens are charged at the provider's list price with no markup, drawn from a prepaid wallet or from your own provider key, and held under the ceilings you set per worker and across the fleet. Nothing on this page adds to that: mail is an ordinary delivery channel, and there is no connection to pay for. Instinct publishes no price of its own as of 2026-09-15, so this page quotes none.
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.