AI workers alongside OpenAI Dots.
Dots are OpenAI's always-on personal agents in ChatGPT. A dot can use its own cloud computer, connected apps and scheduled tasks, and it can ask for approval before consequential actions. WorkerKit adds a separate worker for a repeatable job, with its own schedule, app grants, budget and run receipt. Today the documented handoff is a worker report delivered to the email account your dot can read. Direct WorkerKit plugin access in Dots still needs verification.
What OpenAI Dots is
One personal agent with ongoing context.
OpenAI introduced Dots on September 29, 2026. A primary dot is powered by GPT-6 Astra and has its own cloud computer and browser. It can work on several projects, use connected apps, and continue between conversations. You can reach it in ChatGPT and, where configured, Slack or Teams.
The getting started guide says creation begins on desktop web or in the desktop app. Mobile can message an existing dot after setup. Rollout is gradual, so an eligible account may wait several days for access.
| Dots at launch | What it means |
|---|---|
| Cloud computer and browser | The dot can inspect and work in its own environment while the person follows its progress. |
| Connected apps and plugins | The person chooses app access in ChatGPT. A WorkerKit plugin has not been verified in Dots. |
| Scheduled and proactive work | A dot can run recurring tasks and read connected sources proactively under OpenAI's controls. |
A dot can research proactively with read-only access to connected information, and it can run tasks you schedule. Those are real background capabilities. The reason to add a WorkerKit worker is job separation: one written instruction, one set of app permissions, a model and budget chosen for that job, and a receipt for every run.
Hired specialists
Give a repeatable job its own worker.
A WorkerKit worker keeps its instruction, memory, trigger, model, budget and app access with the job. The dot remains the person-facing agent that interprets the result.
| Question | OpenAI dot | WorkerKit worker |
|---|---|---|
| What is its scope? | A personal agent that learns your goals and preferences across projects. | One defined job, with its own instruction and bounded access. |
| When does it work? | Between conversations, on scheduled tasks, and through proactive read-only research. | On demand or on its own schedule, even if the dot is paused or unavailable. |
| Where does a result go? | To the dot conversation and its activity view. | To a run receipt and the delivery channels configured for that worker, including email. |
| Who grants access? | You choose apps and Custom Rules in ChatGPT. | You grant apps to each worker separately and set its budget. |
The operator pattern
Let the worker run, then let the dot interpret.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Pick a [kit](https://workerkit.ai/kits) for a repeatable job and review its app permissions, schedule and budget. |
| 2 | The worker | Runs under its own grants and delivers a report by email to the account connected to your dot. |
| 3 | Your dot | When asked, reads that delivered report through your connected email app, summarizes it and helps you decide what to do next. |
The handoff works through a mailbox you control. It does not require a WorkerKit credential in a dot conversation.
Why OpenAI Dots and WorkerKit
Personal context meets job-level control.
Dots follow projects and preferences. WorkerKit keeps recurring jobs separately configured and accountable.
| Dots strength | WorkerKit addition |
|---|---|
| One conversation that carries context across ChatGPT, Slack and Teams. | A standing job does not need to occupy the dot conversation; a short report arrives when the run finishes. |
| A cloud computer that can work through a project. | A worker runs one repeated job under its own app grants, instruction and cost ceiling. |
| Custom Rules and action review govern the dot. | Separate worker permissions and a run receipt let you review what that specific job did and cost. |
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.
- 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.
Where the fleet is available
Operate workers from a verified client.
OpenAI Dots has no verified direct WorkerKit fleet connection here. WorkerKit publishes a public catalog and a private fleet mount for supported MCP clients.
| 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. |
These mounts describe WorkerKit's own interfaces. They are not setup instructions for OpenAI Dots. Use a supported MCP client or the REST API to operate the fleet.
The manager key reaches the fleet only. It grants no access to a worker's connected apps, which run under separate grants.
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 OpenAI Dots 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. |
| OpenAI Dots app access | Manage OpenAI Dots's connected apps in its own settings. This guide does not give it a WorkerKit manager key or fleet tools; operate the fleet from WorkerKit or a separately verified client. |
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
Use connected email for the first handoff.
OpenAI says a dot can use a connected personal email account. WorkerKit can send a worker's report by email after you connect a sending mailbox in WorkerKit. Add an email notification to the worker for the account your dot reads, run it once, and ask the dot to find and summarize the message. The setup guide gives the exact sequence.
This is a one-way delivery. It does not let the dot call WorkerKit fleet tools or answer a worker run awaiting input. Use the WorkerKit dashboard or another supported client to inspect and operate the fleet.
OpenAI's launch describes a plugin ecosystem, but it does not say that the WorkerKit fleet mounts are installed in Dots. Until that path is tested, this page does not ask you to paste an MCP URL or a manager key into the dot. Read our launch analysis for availability and the product details.
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. The delivery route on this page is not a paid feature, and the plans are on the pricing page.
Questions
OpenAI Dots and WorkerKit, answered.
- What are OpenAI Dots? Dots are OpenAI's always-on personal agents in ChatGPT. A primary dot has a cloud computer, works across connected apps, can continue between conversations and uses GPT-6 Astra. OpenAI introduced them on September 29, 2026.
- Can Dots directly control WorkerKit workers? A direct WorkerKit plugin or MCP connection in Dots has not been verified as of launch day. OpenAI documents plugins for Dots, but that alone does not prove compatibility with WorkerKit's existing mounts. Use the email report handoff described here and operate the fleet from WorkerKit or a tested client.
- Can a dot read WorkerKit run reports? OpenAI says a dot can use connected personal email, and WorkerKit can deliver a report to that mailbox. Ask the dot to find and summarize a test message, then verify its answer against the report. This is an email workflow, not a direct fleet integration.
- Who can use Dots today? OpenAI says Dots are rolling out to Pro and Business Premium users in eligible markets. Enterprise workspaces, including Edu and Healthcare, can try the beta when an admin enables it. Rollout is gradual and access can take several days.
- Are OpenAI Dots free or included in ChatGPT Plus? The first dot is included in eligible Pro and Business Premium plans; Plus is not listed in the launch rollout. OpenAI says dot usage will not count toward eligible plan allowances during the first month after launch, and it will publish later usage terms. Check the current Help Center before choosing a plan.
- Do Dots replace scheduled WorkerKit workers? Dots can run scheduled tasks. A WorkerKit worker is useful when a recurring job needs its own instruction, model, app grants, budget and run receipt. The two can coexist; choose the amount of separation the job needs.
- Should I give my dot a WorkerKit manager key? The email handoff needs no manager key in the dot. Keep fleet credentials in WorkerKit or a supported client with a proper authentication flow. Do not paste a key into a chat message as a substitute for a verified integration.
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.