AI workers for Gemini.
Gemini is the assistant you think and build with, and it arrives as several products under one name. WorkerKit puts a fleet behind the one you use: background AI workers that hold their own instruction, memory, schedule, budget and app grants, run around the clock with nothing of Google's open, and answer in short, costed digests. The wiring is two entries in Antigravity's MCP config, or one URL in the Gemini app's Connected Apps. Setup takes about a minute of your time.
What Gemini is
One name, several products.
Gemini is Google's assistant family rather than a single app, and the difference matters here more than on any other platform. People use the Gemini app at gemini.google.com and on mobile, where user-installed MCP tools live under Connected Apps and the agentic tier is called Gemini Spark. Developers use Antigravity, Google's agent-first platform: the desktop app, the Antigravity CLI and Antigravity for IDEs, which took over from the standalone Gemini CLI for individual users. Organisations use Gemini Enterprise and its Business edition, and underneath it all the Gemini API serves the models directly.
All of them speak the Model Context Protocol. What differs is the credential each will hold, and that decides where a fleet is wired: Antigravity takes a header you supply, the Gemini app runs an OAuth flow, and Gemini Enterprise takes either no authentication or an OAuth client an admin configures by hand.
| What a fleet adds | Why it helps |
|---|---|
| One fleet behind every Gemini surface | The workers belong to your WorkerKit account, not to a client, so the same fleet answers from Antigravity on your machine and from the Gemini app on your phone. You wire it twice at most, and you build it once. |
| Work that survives closing the editor | An Antigravity agent works while you are there. A hosted worker keeps its schedule whether or not anything of Google's is open. |
| A grant per job | App access is wired once, per worker, so Gemini orchestrates the work without every integration hanging off one Connected Apps list on one Google Account. |
Gemini is already good at the work you watch it do, in the chat and in the editor, and that is where it should stay. A fleet beside it takes the standing jobs: the ones that keep running when the window is closed, hold their own app access, and report a paragraph rather than a screen.
Hired specialists
What a worker adds beside Gemini.
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 of Google's stays open.
| Aspect | Gemini | A WorkerKit worker |
|---|---|---|
| Context | One conversation, plus the Gem or the workspace you are in | Its own, sealed per run; only the digest returns |
| Model | The Gemini model behind that surface | Chosen per worker from any supported provider, or your own provider key |
| Identity | Your Google Account and the apps connected to it, or the servers in your MCP config | Its own key, with an explicit grant per app, read-only by default |
| When it runs | While the app or the editor is open | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | The work itself, in the chat or the editor | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Memory | A Gem's saved instructions and knowledge files, and whatever the surface keeps between sessions | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Disconnect the custom app, or remove the entry from the config file | Disable or revoke one worker; nothing else moves |
The operator pattern
Gemini operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in plain language. "Which workers ran today?", "Run the invoice chase now", "Pause the scanner." In the Gemini app a custom app is invoked by typing @ and picking it. |
| 2 | Gemini | Reads its key's scopes first with key_info, picks the matching MCP tool, 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 | Gemini reads the result with runs_feed and run_get: 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. |
Gemini becomes the fleet operator. The workers do the unattended work, Gemini does the thinking about it, and the interactive work workers are not for stays where it is.
Why Gemini and WorkerKit
Each one covers what the other is not for.
Use Gemini for the work you want to watch and steer, in the chat or in the editor. Use a WorkerKit worker for the standing job: run it unattended against my apps, on a schedule, with its own grant, and deliver the result to Slack.
| Gemini strength | What WorkerKit adds beside it |
|---|---|
| Antigravity agents that work inside your repository | Hosted runs that keep going after the editor is closed, with a receipt and a settled cost for every one |
| Remote MCP with your own headers, in one config file | Two streamable-HTTP mounts that drop into that file as two entries, the public catalog and your fleet |
| A consumer app that connects custom apps by sign-in rather than by key | A fleet mount that is itself an OAuth 2.1 server, so that flow completes on WorkerKit's own consent page and no credential passes through a chat |
| Gems that carry a brief, a tool and knowledge files | Workers that carry a JOB across runs, with memory you approve before it is used |
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 Gemini 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 mounts, and two doors into Gemini.
Antigravity is the fleet door. Its MCP config takes a remote server as a serverUrl plus a headers object, and Google's own example in that object is an Authorization bearer token, so a manager key goes exactly where the vendor documents one. The desktop app, the Antigravity CLI and Antigravity for IDEs share that file.
The Gemini app is the other door, and it takes no key at all. Under Settings, then Connected Apps, a custom app is an MCP server URL, and the authentication Google documents there is OAuth with dynamic client registration. The fleet mount supports that, so the app registers itself and sends you to a WorkerKit consent page where an account admin picks the key. Google publishes gates on that surface worth knowing first: 18 or over, in the United States, a personal Google Account rather than a work or school one, Keep Activity on, English, and set up on desktop web.
The whole procedure is the setup guide, written for the agent doing it. The human's part is one wiring step and about a minute.
One door Gemini does not have: no Gemini surface documents a user-supplied REST or OpenAPI action carrying a static bearer key, so there is no plain-HTTPS fallback here. The route is MCP, through one of the two doors above.
The same fleet answers elsewhere: any other MCP client, the wk CLI in a terminal, and the REST API for hosts that do speak plain HTTPS. The fleet outlives the choice of assistant.
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 Gemini is not a paid feature, and the plans are on the pricing page.
Questions
Gemini and WorkerKit, answered.
- Which Gemini surface should I set this up on? Antigravity for the fleet. Its MCP config takes a remote server as a serverUrl plus a headers object, which is where the manager key goes, and the Antigravity desktop app, the Antigravity CLI and Antigravity for IDEs all read it. The Gemini app is the other documented door: Settings, then Connected Apps, then a custom app by MCP server URL, authenticated by OAuth rather than by a key. Google publishes gates on that one: 18 or over, in the United States, a personal Google Account rather than a work or school one, Keep Activity on, English only, and set up on desktop web.
- Do I have to paste a key into Gemini? It depends on the surface, and the answer is honest in both directions. In Antigravity, yes: you create a manager key at workerkit.ai/fleet-access and it becomes the Authorization value in the headers object of mcp_config.json. Google does not document environment-variable expansion inside that object, so assume the key sits in that file as written and treat the file as a secret. In the Gemini app, no: the fleet mount publishes OAuth discovery and accepts dynamic client registration, so the app registers itself and sends you to workerkit.ai/mcpauth, where an account admin picks or creates the key. Nothing is typed into the chat.
- Can I still use the Gemini CLI for this? No, and a guide that tells you to is out of date. Google announced the transition on 2026-05-19: Antigravity CLI went generally available, and on 2026-06-18 the Gemini CLI and the Gemini Code Assist IDE extensions stopped serving requests for Google AI Pro, Ultra and free individual users. Organisations on Gemini Code Assist Standard or Enterprise licences are unchanged. Wire the Antigravity CLI instead, which uses the same mcp_config.json as the rest of Antigravity.
- Can Gemini read my email or CRM through WorkerKit? No, and the fence stands in both directions. The manager key Gemini holds operates workers: no scope on it opens a mailbox, a calendar or a CRM, and nothing typed into a chat widens it. Each worker reaches its own apps under its own grant, its own firewall and its own rules. Going the other way, connecting WorkerKit hands a worker nothing from your Google Account or from anything else in Connected Apps.
- What does Gemini need to set this up? A WorkerKit account with admin access, and one of the two doors. On Antigravity: a manager key created at workerkit.ai/fleet-access and one entry added to mcp_config.json. On the Gemini app: no key, but an admin who can approve on the WorkerKit consent page. Either way the skill file at workerkit.ai/gemini/SKILL.md carries the tool reference and the operating rules, and the person's part is about a minute.
- Does this work in Gemini Enterprise? Partly, and the limit is Google's rather than ours. A custom MCP server data store offers two authentication choices, no authentication or an OAuth 2.0 client configured by hand with an authorization URL, token URL, client ID, client secret and scopes, over StreamableHTTP only, and an administrator normally has to allow the server's domain by organisation policy first. The public catalog mount fits the no-authentication choice. The fleet mount expects a client that registers itself rather than one issued in advance, so we do not document a pairing with that hand-configured OAuth form until we can state it exactly. Business edition adds an MCP server under Settings and help, then your team, then Manage team, then Connected apps, and Google labels that flow a Pre-GA offering.
- How does Gemini get a worker's results? Two paths, and neither needs a Gemini window open. Gemini reads them over the mount it already has: runs_feed for the fleet, run_get for one run, and each receipt carries the closing report, the typed digest when the run produced one, and the settled cost. Away from Gemini, the worker delivers on its own to the channels set on it: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook.
- I connected it and the fleet is empty. What now? That is the expected state of a new account, and it already proves the connection. Fill it from the catalog: open a kit at workerkit.ai/kits and install it in one click, which asks no scope of the key at all. With installKits on the key Gemini can do it without leaving the chat, shortlisting with kits_search, showing you exactly what the new worker would be allowed to touch with kit_install_preview, and calling kit_install when you say yes. Then have it run the new worker once and read you the receipt.
- What does it cost? WorkerKit has a Free plan and asks for no card: 5 workers, 500 tool calls a day and the whole safety layer. A run pays for the model tokens it used, at the provider list price with no markup, out of a prepaid wallet or your own provider key, and the per-worker and fleet budgets you set are the ceiling. Connecting Gemini is not a paid feature here, and nothing on the WorkerKit side asks for a Google subscription.
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.