# WorkerKit glossary

> Plain definitions for the words around AI workers: kits, skills, plugins, MCP, runtimes, schedules and triggers. One page per term, answered in a sentence.

Terms defined: 32. Ordered A to Z.

Every term below is also a page of its own, linked under each heading. This file carries the complete text of all of them, so one fetch is the whole vocabulary.

## Agent Skill

URL: https://workerkit.ai/glossary/agent-skill
Also called: skill, SKILL.md, Claude skill, agent skills
Updated: 2026-10-08

**Agent Skill vs worker kit: how do they differ?** An Agent Skill is markdown instructions an AI agent loads on demand to learn one technique. A worker kit is a configured worker that does a job unattended.

Skills teach an agent a **technique**. Kits do a **job**. Almost every question
about how the two relate resolves once you hold that line.

Neither is a better version of the other. A skill improves the work you do while
you are sitting there; a [kit](/glossary/worker-kit) is the work happening while
you are not.

### Agent Skill vs worker kit, side by side

| | Agent Skill | [WorkerKit kit](/glossary/worker-kit) |
| --- | --- | --- |
| What it carries | Markdown instructions, optional scripts | Instruction, app permissions, memories, schedule |
| Lives in | An agent's skill folder | Your WorkerKit account, as a worker |
| Identity | None | Its own worker, its own key |
| App access | Whatever the session already has | Granted per app at Off, Read or Write, revocable |
| Starts | When you invoke the agent | On a schedule, a webhook, or on demand |
| Runs when you are asleep | No | Yes |
| Leaves an audit trail | No | A [receipt](/glossary/run-receipt) per run |
| Cost model | Your client's tokens | Provider list price, no markup |

### What an Agent Skill actually is

A skill is a folder. At its root sits `SKILL.md`: YAML frontmatter with a `name`
and a `description`, then markdown instructions. Those two fields are the only
required ones.

```
brand-voice/
  SKILL.md          # name, description, instructions
  reference.md      # loaded only when needed
  scripts/
    lint-copy.py    # run only if the task calls for it
```

Agents load skills by **progressive disclosure**, in three stages: at startup
only each name and description are in context, the full `SKILL.md` is read when
a task matches, and referenced files or scripts load only if the work needs
them. That is what lets a large skill library cost almost nothing until it is
used.

### Where a skill stops, with a real example

Say you write a skill that teaches an agent how your team reviews pull requests:
what to look for, the tone of a review comment, when to block versus suggest.

That skill is genuinely useful, and it does exactly nothing until you open your
editor and ask. It has no GitHub credential of its own, no memory of yesterday,
and no reason to run.

The [Engineering Pulse](/kit/engineering-pulse) kit is the other half of that
problem. It connects GitHub, runs on a schedule, and delivers a morning digest
of pull requests needing review, stale branches, failing workflows and hot
issues. Nobody invokes it. The digest is simply there when you start.

Neither replaces the other. The skill improves the review you write; the kit
makes sure you knew there was one waiting.

### Three more pairings worth seeing

Each row is a technique you might encode as a skill, next to a real kit that
does the unattended half:

| A skill could teach | A kit that does the job |
| --- | --- |
| How to write a follow-up email in your voice | [Follow-Up Tracker](/kit/follow-up-tracker) tracks every thread you are waiting on and drafts the nudge |
| How to qualify a lead against your ICP | [Inbound Lead Qualifier](/kit/inbound-lead-qualifier) qualifies new leads, files them in the CRM and drafts the first reply |
| How to summarise a meeting properly | [Meeting Action Item Collector](/kit/meeting-action-item-collector) reads your notes each evening and files every action item |

Notice the pattern: the skill is about **quality**, the kit is about **it
happening at all**.

### Why an unattended job needs more than instructions

The moment something runs without you, three requirements appear that a
`SKILL.md` has no way to express.

**Somewhere to run.** A skill runs inside your session. A worker needs a
[managed runtime](/glossary/hosted-runtime): WorkerKit executes the run so a
schedule fires with no machine of yours left on.

**Restraint that is not a request.** A skill can say "never email the exec
team". That is a sentence in a prompt, evaluated against every other pressure in
context. A worker gets an [app firewall](/glossary/app-firewall) granting Read
or Write per app, [contact rules](/glossary/contact-rules) that filter reads and
refuse blocked recipients, and [redaction](/glossary/redaction) applied outside
the model's reach. A control is not an instruction.

**A record.** A skill leaves the session transcript. A worker leaves a receipt
per run showing what it read, what it did, what it cost and what it skipped.

### Can you use both?

Yes, and most people should. Skills encode how your team works, in the tools
your team drives by hand. Kits cover the jobs that should happen whether or not
anyone opens an editor.

They also sit at different layers from [MCP](/glossary/mcp) and
[plugins](/glossary/ai-plugin): MCP is the protocol for reaching a system, a
plugin is how skills and MCP config get installed into a client, a skill is the
technique, and a kit is the finished job.

### FAQ

#### What is an Agent Skill?

An Agent Skill is a folder of markdown instructions, led by a `SKILL.md` file
carrying a name and a description, that an AI agent loads on demand to learn one
technique while you are driving it. Skills are loaded by progressive disclosure,
so a large library costs almost nothing until a task matches one.

#### Is an Agent Skill the same as a WorkerKit kit?

No. A skill is markdown instructions that an agent loads while you are driving
it, with no credentials, no schedule and no way to start itself. A WorkerKit kit
is a ready-made worker with its own key, its own per-app permissions, memories
and a schedule, which runs unattended and leaves a receipt for every run.

#### Can a skill run on a schedule?

Not on its own. Nothing in the SKILL.md format wakes up: a skill is read into
context when an agent decides it is relevant to the task you asked for. If you
need something to happen at 7am on its own, you need a worker with a
[schedule](/glossary/worker-schedule) or a
[webhook trigger](/glossary/webhook-trigger).

#### Do I need to write skills to use WorkerKit?

No. A kit ships with its instruction already written and tested by its
publisher, which is the point of a kit. You connect the apps it asks for and
run it, with no prompt engineering and no glue code.

#### Can I turn a skill into a kit?

You can hand the skill to the AI assistant you already use, connected to the
[WorkerKit MCP server](/build/mcp), and have it rewrite the technique as a kit's
instruction, then validate and publish the kit. What you add on top of the
skill's text is the part a skill has no slot for: which apps, at what access
level, on what schedule.

#### Which is cheaper to run?

Skills and kits are metered differently. A skill costs whatever your client
charges for the tokens in your session. A WorkerKit worker costs your plan (Free is $0 with 5
workers and 500 [tool calls](/glossary/tool-call) a day) plus model tokens at
the provider list price with no markup, from a [wallet](/glossary/runtime-wallet)
or [your own key](/glossary/byok). See [/pricing](/pricing).


Published WorkerKit plans and prices apply to shared cloud.

## agentic workflow

URL: https://workerkit.ai/glossary/agentic-workflow
Also called: agent workflow, multi-step agent, autonomous workflow
Updated: 2026-08-14

**What is an agentic workflow?** An agentic workflow is a process an AI agent carries out over several steps, deciding what to do next at each one rather than following a fixed script.

"Agentic workflow" is the term teams reach for when automation stops being a
flowchart. It names the shift from *encoding every branch in advance* to *letting
a model decide the next step from what it just found*.

### Fixed automation vs agentic workflow

| | Fixed automation | Agentic workflow |
| --- | --- | --- |
| Path through the work | Decided at build time | Decided per run |
| Handles unexpected input | Fails, or ignores it | Reasons about it |
| Reading unstructured text | Needs a parser per format | Native |
| Predictability | Total | Bounded, not exact |
| Failure mode | Loud and deterministic | Plausible and quiet |
| Testing | Enumerate the branches | Sample runs and judge |

The last two rows are the trade. You gain the ability to handle input nobody
anticipated, and you lose the guarantee that identical input produces identical
output.

### What "agentic" actually adds

A traditional automation for triaging support mail needs a rule per case: this
subject line means billing, this sender domain means enterprise, this phrase
means urgent. Every case somebody did not think of falls through.

An agentic version reads the message and decides. It handles the ticket written
in the wrong tone, in a second language, describing a problem your rule list has
never seen. That is genuinely new, and it is why the category exists.

The cost is that "decides" is not "computes". Two runs on similar input can
reach different conclusions, which is fine for classification and unacceptable
for arithmetic. The judgement worth making is which parts of a job want a model
and which want code.

### Agentic workflow, or AI worker?

The two terms overlap heavily and are often used interchangeably. Where they
differ is what each one names:

- An **agentic workflow** names the *pattern*: multi-step, model-directed work.
- An [**AI worker**](/glossary/ai-worker) names the *configured thing* that does
  one such job unattended, with its own key, its own app permissions, a schedule
  and a receipt.

You can have an agentic workflow that you drive by hand in a chat window. You
cannot have a worker without the identity, the permissions and the trigger,
because those are what "unattended" requires.

WorkerKit's own documentation treats "agentic workflow" as the phrase some teams
use for what it calls a worker, which is fair: the same shape, named from the
process side rather than the object side.

### What one looks like in practice

[Meeting Prep Assistant](/kit/meeting-prep-assistant) is a clear multi-step
example. It reaches calendar, email, meeting notes and CRM, and a single run:

1. Lists the meetings on the day's calendar
2. For each one, works out who is attending and what matters about them
3. Searches email for the relevant recent history
4. Pulls the CRM record where there is one
5. Reads prior meeting notes for open items
6. Writes one prep sheet per meeting

Step 2 changes what steps 3 to 5 look for. That dependency, where the output of
one step shapes the next, is what makes it agentic rather than a pipeline. A
fixed script would need every branch enumerated in advance.

### What it costs to run one

Multi-step means multiple [tool calls](/glossary/tool-call), and the count scales
with what the run finds rather than with a fixed plan:

| Meetings that day | Rough tool calls | Notes |
| --- | --- | --- |
| 2 | ~10 | Two lookups per meeting plus the calendar read |
| 5 | ~22 | Roughly linear in meetings |
| 10 | ~42 | Still inside Free's 500 a day |

That variability is characteristic. A fixed automation costs the same every run;
an agentic one costs what the day contained. It is worth knowing before you set a
cadence, because a busy day is also the expensive day.

### The failure mode

Fixed automation fails loudly: a parser throws, a field is missing, the job
stops. You find out because something is red.

An agentic workflow fails **plausibly**. It produces a prep sheet that reads
perfectly and attributes a comment to the wrong person, or classifies a ticket
into a category that is defensible but wrong. Nothing is red. The work looks
done.

That is why the surrounding machinery matters more than it does for traditional
automation: a [receipt](/glossary/run-receipt) per run showing what it read and
did, hard caps so a confused run cannot loop expensively, and access limited to
what the job needs so a wrong decision has a small blast radius.

### The reasonable objection

"Non-determinism is disqualifying. I cannot put something in production that
gives different answers to the same question."

Right for some jobs, and the honest response is to keep those jobs deterministic.
Nobody should compute an invoice total with a model.

The jobs where it holds up are ones where a human was already the
non-deterministic component. Two support agents triage the same queue slightly
differently; two people summarising a meeting produce different notes. Replacing
a human judgement call with a model judgement call does not introduce variance,
it changes who is varying, and it makes the variance inspectable through
receipts in a way a person's reasoning never was.

### When not to reach for one

- **The rules are complete and stable.** If a flowchart covers every case, build
  the flowchart. It is cheaper, faster and exact.
- **The output must be exact.** Money, quantities, identifiers. Use code.
- **The job runs once.** The setup cost is not recovered.
- **Mistakes are unrecoverable.** Start where the downside is a nuisance.

The strongest pattern is usually a mix: a model for reading and deciding, code
for calculating and committing. A [kit](/glossary/worker-kit) is that mix already
assembled for one job.

### FAQ

#### What is the difference between an agentic workflow and an AI worker?

An agentic workflow and an AI worker describe the same shape from two angles.
"Agentic workflow" names the pattern of multi-step, model-directed work. An [AI worker](/glossary/ai-worker)
names the configured thing that performs one such job unattended, with its own
key, per-app permissions, a schedule or trigger, and a receipt for every run.

#### How is an agentic workflow different from normal automation?

Fixed automation follows a path decided at build time and fails on input nobody
anticipated. An agentic workflow decides the next step from what it just found,
so it handles unstructured and unexpected input, at the cost of exact
repeatability.

#### Are agentic workflows reliable enough for production?

For jobs where a human was already the judgement call, generally yes, provided
the surrounding controls exist: narrow access, hard caps, and a record of every
run. For jobs requiring exact output, such as calculations, use code.

#### How much does an agentic workflow cost to run?

The cost of an agentic workflow varies with what each run finds rather than
being fixed. A multi-step worker might use 10 [tool calls](/glossary/tool-call) on a quiet day and 40 on a busy
one. Free allows 500 a day, Pro 5,000, and Team 50,000 pooled, with model tokens
billed separately at provider list price with no markup.

#### Do I need to build an agentic workflow myself?

No. A [worker kit](/glossary/worker-kit) is one already built and tested for a
specific job, including the instruction, the app permissions and the schedule.
Browse [the directory](/kits) to see what exists before writing one.

## AI plugin

URL: https://workerkit.ai/glossary/ai-plugin
Also called: plugin, agent plugin, Claude Code plugin, AI agent plugin
Updated: 2026-10-08

**AI plugin vs AI worker: what is the difference?** An AI plugin is an installable bundle adding skills, subagents and MCP config to an AI client you drive. An AI worker runs one job unattended, on its own key.

A plugin is a **box**. An [AI worker](/glossary/ai-worker) is a **worker**. Both
are distributed from a marketplace and installed in one click, which is why they
get compared, and the resemblance stops at the install button.

The line in one sentence: **a plugin adds capability to a client you are
driving, and a worker does a job while nobody is driving anything.**

### AI plugin vs AI worker, side by side

| | AI plugin | [AI worker](/glossary/ai-worker) |
| --- | --- | --- |
| Installs into | An AI client you use | Your WorkerKit account |
| What you get | Skills, subagents, hooks, MCP config | A configured worker doing one job |
| Identity | None of its own | Its own, with only what the job needs |
| App access | Whatever the client already holds | Granted per app at Off, Read or Write |
| Starts | When you invoke it | A [schedule](/glossary/worker-schedule), a [webhook](/glossary/webhook-trigger), or on demand |
| Runs unattended | No | Yes |
| Memory | The session | Facts carried between runs |
| Audit trail | The session transcript | A [receipt](/glossary/run-receipt) per run |
| Model | The client's model | Claude, ChatGPT, Gemini or Grok, switchable |

The two rows that decide everything else are **starts** and **identity**. Once
something starts itself, it needs credentials that are not yours and a record of
what it did, and neither is a packaging concern.

### What an AI plugin actually bundles

The contents vary by client, but the pattern is consistent. In Claude Code a
single plugin can carry:

- **skills and slash commands**, the instructions an agent loads on demand
- **subagents**, specialised agents with their own context and token budget
- **hooks**, code that fires at points in the session lifecycle
- **MCP server configuration**, so the tools those skills assume are connected

Installing the plugin installs all of it together, which is the point: the
pieces in a good plugin depend on each other, and shipping them separately means
people assemble something half-wired and then report it as broken.

### Plugins are distribution, not capability

This is the sentence worth keeping. **A plugin does nothing a skill or an MCP
server could not do.** It solves packaging, versioning and installation.

Which makes "should I write a skill or a plugin?" the wrong question most of the
time. Write the [skill](/glossary/agent-skill). Reach for a plugin when several
pieces travel together, or when other people need to install them.

And a plugin installs into a client, and a client is a thing a person is using.
Whatever it adds is available while you are there.

### Where a plugin stops, with a real example

Suppose you build a plugin for your support team: a skill for your reply tone,
a subagent that checks the knowledge base, and MCP config for your helpdesk. It
is a genuinely good plugin. Every agent on the team now answers tickets in the
same voice.

It still only helps when somebody opens the client and starts working the queue.

The worker from the [Support Inbox Triager](/kit/support-inbox-triager) kit is
the other half: it connects email and tasks, and on its schedule it classifies
and prioritises the support inbox, drafts replies, and files tickets for real
issues. Nobody invokes it. The queue is already triaged when the team arrives.

Two more of the same shape:

| A plugin might give your team | A worker that runs without them |
| --- | --- |
| A CRM subagent and hygiene rules | [CRM Scribe](/kit/crm-scribe) logs meetings and email threads into the CRM so records stay current |
| Meeting-prep prompts and templates | [Meeting Prep Assistant](/kit/meeting-prep-assistant) builds a prep sheet for each meeting from calendar, email, notes and CRM |

### What changes when nobody is driving

Three problems appear the moment a thing runs on its own, and none of them is a
packaging problem, which is why a plugin format does not address them.

**Credentials of its own.** A plugin borrows the client's access. A worker holds
its own key with its own scope list, so it can be switched off without touching
anything else, and it cannot reach an account you never connected.

**Restraint the model cannot argue with.** [Contact rules](/glossary/contact-rules)
filter reads and refuse blocked recipients. [Redaction](/glossary/redaction)
strips sensitive values outside the model's reach. An instruction in a bundled
skill is a request; these are not.

**A record.** Every run leaves a receipt: what it read, what it did, what it
cost, what it skipped and why.

### Where a kit fits

You do not assemble a worker from nothing, any more than you assemble a plugin
from nothing. A [worker kit](/glossary/worker-kit) is the distribution format on
this side of the line: the instruction, the app permissions, the memories and
the schedule for one job, already written and tested by a publisher.

So the fair comparison is not plugin against worker but **plugin against kit as
packages**, and worker against client as things that run:

| | Package | What installing it gives you |
| --- | --- | --- |
| AI plugin | Skills, subagents, hooks, MCP config | Capability inside a client you drive |
| [Worker kit](/glossary/worker-kit) | Instruction, per-app access, memories, schedule | A worker in your account that runs itself |

### Use both

The layers compose, and a good setup uses all of them: [MCP](/glossary/mcp) to
reach your systems, skills to encode how your team works, plugins to distribute
those skills, and workers for the jobs that should happen whether or not anyone
opens an editor. The longer version of that argument is
[plugins, skills and kits](/blog/plugins-skills-and-kits).

### FAQ

#### What is an AI plugin?

An AI plugin is an installable bundle that adds capability to one AI client,
packaging skills, subagents, hooks and MCP server configuration into a single
unit. It solves distribution: everything a technique needs travels together and
installs in one step, into a client a person is using.

#### What is the difference between an AI plugin and an AI worker?

A plugin adds capability to a client **you** drive, using the access that client
already holds, and it does nothing until you invoke it. An
[AI worker](/glossary/ai-worker) is an agent set up to do one job unattended: it
has its own key, its own per-app permissions, a schedule or a trigger, memories
carried between runs, and a receipt for every run.

#### Is a WorkerKit kit a plugin?

No. A plugin installs capability into an AI client that you drive. A kit creates
an AI worker in your own account, with its own key, its own per-app permissions
and its own schedule, and that worker does its job unattended.

#### What is the difference between a plugin and a skill?

A skill is instructions that teach a technique. A plugin is a container that can
bundle several skills, plus subagents, hooks and MCP configuration, into one
installable unit. Plugins solve distribution; skills provide the capability.

#### Can a plugin give an agent access to my email or CRM?

Only through the client it is installed in, using the access that client already
holds. That is the practical difference from a worker, where you grant access
per app and per level (Off, Read or Write), can narrow or revoke it at any time,
and the worker keeps running with whatever is left.

#### Do I need to install anything to run an AI worker?

No. WorkerKit hosts the runs, so there is no agent to install and no machine to
keep alive. You connect the accounts the kit asks for and deploy it. Running a
worker on your own infrastructure is coming later.

#### Can I publish a kit the way I would publish a plugin?

Yes. You build it [with your AI assistant, the API or the CLI](/build), and a
published kit gets its own page and a permanent address for life, so updates
land on the same URL. Kits can also stay private, on every plan including Free.

## AI worker

URL: https://workerkit.ai/glossary/ai-worker
Also called: AI agent worker, autonomous agent, agentic worker
Updated: 2026-10-29

**What is an AI worker?** An AI worker is an AI agent configured for a defined job, with its own app permissions, spending limits, memory and run record retained between requests.

A worker gives a job a persistent home. Authorized people and agents can call
it, and schedules or supported events can start it. When the run ends, the
worker retains its method and controls for the next request.

### AI assistant vs AI worker

| Question | What to establish | In WorkerKit |
| --- | --- | --- |
| What starts it? | The job's response-time needs | An explicit request, a [schedule](/glossary/worker-schedule) or a supported [trigger](/glossary/webhook-trigger) |
| What does it do? | A defined result | Standing instructions or decision rules |
| What can it reach? | The access the job needs | Its own app grants and supported restrictions |
| What can it spend? | Execution ceilings | Limits per run, per day and per account |
| What does it retain? | Context useful to future runs | Configuration and enabled memory |
| What happened? | Evidence to inspect | A [receipt](/glossary/run-receipt) per run |

An assistant may also have memory, connected apps and scheduled work. Those
features alone do not separate the categories. The useful question is whether
the job has its own retained method, authority and record, independent of a
particular conversation. An assistant can be one way to operate that worker.

### What a real one looks like

[Executive Daily Briefing](/kit/executive-daily-briefing) connects calendar,
email and tasks, runs on a schedule, and delivers a prioritised morning brief:
meetings, urgent email, blockers, team chatter.

Set the schedule and delivery for when you need the brief. The kit also supports
on-demand runs. Its method and app grants remain in place between briefs;
scheduled execution is one way to use them.

Three more, each a different shape:

| Worker | Apps | How it starts |
| --- | --- | --- |
| [Inbound Lead Qualifier](/kit/inbound-lead-qualifier) | email, crm | On demand or a supported inbound event |
| [Engineering Pulse](/kit/engineering-pulse) | github | On demand or a schedule you configure |
| [Company Knowledge Concierge](/kit/company-knowledge-concierge) | drive, sharePoint | On demand, when asked |

### Why the job has to be specific

"Handle my email" is not a job a worker can do. "When a lead replies to the
outbound sequence, check the CRM for their stage, draft a reply in our voice,
and leave it in drafts for me" is.

A narrow job has a definition of done, a small set of apps and a small set of
ways to go wrong, so its results and permissions are easier to evaluate. A vague
job makes those decisions harder. Several workers can form an
[AI workforce](/glossary/ai-workforce), with each job retaining its own method,
authority and owner.

### The three things an unattended job needs

Before leaving a job to run unattended, establish its method, authority and
handling of uncertain results:

- **A written instruction** that holds on the four hundredth run, not a prompt
  you improvise.
- **Explicit app permissions**, because it touches a real inbox while you sleep.
  Access is granted per app and per level, and can be narrowed or revoked at any
  time with the worker still running on what is left.
- **Rules for what it may do**: which contacts it may reach
  ([contact rules](/glossary/contact-rules)), what must never leave
  through supported field restrictions, and where uncertain decisions go for
  human attention. Instructions and enforced access controls serve different
  purposes.

Set execution limits and review receipts as well. A recorded successful call
proves that the operation completed, not that its business result was correct.

### Where a worker comes from

Start from a [worker kit](/glossary/worker-kit), the reusable definition of a
worker's job, apps and run settings. Installing it creates a worker in your
account. Review its instructions, connect the required accounts, supply the
job's inputs and check its permissions and limits before the first run. Setup
effort depends on the job and the apps involved.

Browse [the directory](/kits), or [build a kit with an agent](/build) through
MCP, the API or the CLI. WorkerKit accounts open by invitation through
[Get started](/#start).

WorkerKit hosts the runs, so the worker follows its schedule with no machine of
yours left running, and model tokens bill at the provider list price with no
markup. See [pricing](/pricing) for current plans and usage terms.

Published WorkerKit plans and prices apply to shared cloud.

### When the answer is not a worker

Choose a worker when retaining the method, authority and record is useful.
Frequency is only one consideration: a one-off investigation can still need
narrow app access and an inspectable result. The job needs a defined outcome,
adequate inputs and a suitable response when the result is uncertain.

| The job | Fails on | Use instead |
| --- | --- | --- |
| An exploratory question with no retained method or app authority needed | Little value from persistent configuration | Your existing assistant |
| Calculating an invoice total | Requires exact arithmetic | Deterministic code or an app operation |
| Negotiating a renewal without explicit commercial limits | Unbounded commitments | A person, with a worker preparing the evidence |
| "Keep on top of my inbox" | Definable | Narrow it first, then reconsider |
| Anything sending money | Recoverable | A person, with a worker preparing it |

Start with a bounded result you can judge and recover from. The buyer's question
is how the job fits into [a company AI workforce](/blog/from-ai-tools-to-an-ai-workforce),
including its review and operating effort. You can keep using an assistant for
interactive exploration while a worker carries out the defined job.

### FAQ

#### What is the difference between an AI agent and an AI worker?

An AI agent is the general category: a model that uses tools to pursue a goal.
An AI worker is an agent configured for a defined job with retained method,
permissions, limits and run records. A worker can run on demand, on a schedule
or through a supported event; a workflow is the process workers carry out.

#### Do I need to know how to code or prompt to run one?

You can start from a [kit](/glossary/worker-kit) without writing the worker from
scratch. Review its method, connect the required apps, supply the job's inputs
and evaluate the first results. A kit is a starting configuration, not a
guarantee that its results meet your company's criteria.

#### What can an AI worker see in my accounts?

Only what you grant it. Every kit states the apps it uses and the exact access
it needs before you take it, you approve each connection yourself, and you can
narrow or switch any of it off afterwards. A kit cannot reach an account you
have not connected.

#### Where does an AI worker actually run?

On WorkerKit's [managed runtime](/glossary/hosted-runtime), so its authorized
on-demand, scheduled and event-driven runs need no machine of yours left on.
An enabled worker can remain ready between requests without executing
continuously.

#### How much does it cost to run an AI worker?

The Free plan runs 5 workers with 500 [tool calls](/glossary/tool-call) a day
and the complete safety layer, with no card and no expiry. Model tokens bill
separately at the provider list price with no markup, from a
[wallet](/glossary/runtime-wallet) or [your own key](/glossary/byok). See
[/pricing](/pricing).

## AI worker fleet orchestration

URL: https://workerkit.ai/glossary/ai-worker-fleet-orchestration
Also called: worker orchestration, AI worker orchestration, agent orchestration, multi-agent orchestration, fleet orchestration
Updated: 2026-08-17

**What is AI worker fleet orchestration?** AI worker fleet orchestration is one AI client splitting a task across purpose-built workers, then reading their results back to decide what happens next.

A [worker fleet](/glossary/worker-fleet) is usually described as something a
person configures and then leaves alone. **AI worker fleet orchestration** is
what happens when the thing driving it is not a person but another AI.

The client you already talk to connects to your fleet, sees every
[AI worker](/glossary/ai-worker) you have, and can run any of them with a prompt
written for that one run. It reads each [receipt](/glossary/run-receipt) back and
decides what to do with what it found. A request too big for one agent becomes a
plan across several, each step executed by a worker built for exactly that job,
and each step's result choosing the one after it.

### The chat agent alone, and the same agent orchestrating a fleet

| | One agent, all the tools | An agent orchestrating a worker fleet |
| --- | --- | --- |
| Holds the app access | Yes, the union of every job | No, each worker holds its own |
| Work happens | Inside one context window | Inside each worker's own run |
| Runs at the same time | One thing at a time | As many workers as you have |
| Knows a job's method | Whatever you paste in | Already in the worker's instruction |
| Evidence afterwards | A transcript | A receipt per run, per worker |
| Blast radius of a bad step | Everything it can reach | That one worker's grants |

The second column is not a smaller version of the first. It is a different shape:
the orchestrator holds the **plan**, and the workers hold the **access**.

### The three verbs of fleet orchestration

Orchestration is smaller than it sounds. It reduces to three moves, repeated:

1. **Read the fleet.** What workers exist, what each one is for, which are ready,
   which are running right now.
2. **Run one with a prompt.** Not the worker's standing instruction, but what to
   do on *this* run: one account, one repository, one day, one question.
3. **Read the receipt.** Status, the report the worker wrote, what it touched,
   what it cost. Then decide the next move from that.

The third verb is where the pattern earns its name, because the next move is
usually another run, with what the last one just found as its prompt.

Everything else, memory, schedules, instructions, starting and stopping, exists
so the orchestrator can also leave the fleet in a better state than it found it.

### Why the handoff needs an orchestrator

Workers deliberately share nothing. Each one has its own key, its own per-app
grants and its own memory, which is exactly what stops a wrong fact or an
over-broad permission from spreading across the [fleet](/glossary/worker-fleet).

The cost of that isolation is that a finding cannot walk from one worker to the
next on its own. The triage worker can conclude "these three are enterprise
escalations" and the account researcher will never hear about it, because there
is no channel between them and there should not be one.

An orchestrator is that channel, and it is a deliberately thin one: it reads a
finished receipt and writes the next worker's prompt. Nothing is shared, no
permission is pooled, and each worker still only ever sees the subject it was
handed.

### Why the prompt-per-run matters

A worker's standing instruction is its method: how to triage, how to research an
account, what "done" means. That part is stable and was tested when the worker
was built.

What changes is the subject. A per-run prompt supplies the subject without
touching the method, so the same worker can be pointed at forty different things
in an afternoon and each run still does the job the way it was written to. The
orchestrator never has to explain how to do the work, only what to do it to.

This is the whole reason the pattern scales. The alternative, pasting a method
into a general agent every time, means the quality of the work depends on how
well the prompt was written that morning.

### Use cases: one worker's result running the next

The shape worth learning is the **chain**. Run a worker, read what it found, and
use that finding as the prompt for a different worker, one that holds different
app access and knows a different job.

**Triage, then research, then draft.** The
[support triage worker](/kit/support-inbox-triager) runs over the last day's
inbox and its report names three tickets that look like enterprise escalations.
For each named account, the orchestrator runs the account research worker with
that account as the subject, and it comes back with the renewal date, the open
items and who owns the relationship. Those findings become the prompt for the
drafting worker, which writes a reply that knows things the triage worker never
had access to. Three workers, three permission sets, one line of work.

| Step | Worker | Its input | What it hands on |
| --- | --- | --- | --- |
| 1 | Triage | "the last 24 hours" | Three accounts, named |
| 2 | Research | One account from step 1 | Renewal date, open items, owner |
| 3 | Draft | Step 2's findings | A reply that cites them |

**Find the signal, then chase it.** [Engineering Pulse](/kit/engineering-pulse)
produces its digest and two pull requests in it have been stalled for a week.
The orchestrator takes those two, with their owners, and runs the
[follow-up worker](/kit/follow-up-tracker) with them named in the prompt. The
digest worker only reads GitHub; the follow-up worker is the one that can chase
a person. Neither could have done both.

**Look it up, then answer with it.** A support reply needs the real policy, not
a remembered one. The orchestrator runs
[Company Knowledge Concierge](/kit/company-knowledge-concierge) with the
question, gets an answer with citations out of the document store, and passes
that answer into the worker that writes the reply. The reply quotes the source
because the source came from the previous run, not from the model's memory.

**Narrow with a cheap worker, then spend on the survivors.** A fast, shallow
worker scans a wide surface and returns the fifteen items worth a closer look.
Only those fifteen go to the careful worker on the stronger model. The chain is
the cost control: the expensive step only ever sees a filtered list, which is
usually the difference between a sweep you can afford daily and one you run once.

**Check before you commit.** The research worker proposes a set of CRM updates
and writes them into its report rather than applying them, because it holds Read
on the CRM and nothing more. The orchestrator shows you the proposal, and only
what you approve gets handed to the worker that holds Write. The gate between
"decided" and "done" is a different worker with different grants, which is a far
stronger boundary than an instruction asking a single worker to be careful.

**Prep a day, meeting by meeting.** The briefing worker returns today's
meetings. Each one becomes a run of
[Meeting Prep Assistant](/kit/meeting-prep-assistant) with that meeting's
attendees as the subject, and the prep sheets come back one per meeting. Here
the first run does not just start the chain, it decides how many links it has.

**Catching up after an outage.** A provider was down and three workers skipped
their windows. The orchestrator reads the run history to find the gap, replays
the missed subjects one run at a time with the dates named in each prompt, and
each replayed run's outcome decides whether the next one is still needed.

Chaining is not the only shape. When steps do not depend on each other, the same
three verbs fan out instead: one worker run fifty times over fifty accounts, all
at once, with the orchestrator writing the summary at the end. The rule is simply
whether the next prompt needs the last result. If it does, chain. If it does not,
run them together.

### What the orchestrator is not allowed to do

This is the part that makes the pattern safe enough to leave connected.

The credential an orchestrator holds is a fleet credential. It can list, run,
schedule and configure workers. It **holds no app credentials**; workers reach
apps under their own grants. With `readRuns` or `invokeActions` it can read what
those workers return, including an Action worker's tool results.

So when an orchestrated worker touches an app, it does so under its own rules,
unchanged:

| Still enforced during an orchestrated run | Decides |
| --- | --- |
| [App firewall](/glossary/app-firewall) | Which apps, at Off, Read or Write |
| [Contact rules](/glossary/contact-rules) | Which people it may see and reach |
| [Redaction](/glossary/redaction) | What must never leave |
| Daily caps and usage windows | Whether the run happens at all |

A prompt cannot widen any of them. "Also email the customer" reaching a worker
with Read on email produces a run that could not do it, not a sent email. The
restraint lives with the worker, so it holds no matter who is asking.

### How to set up AI worker fleet orchestration

The connection is the remote [WorkerKit MCP server](https://mcp.workerkit.ai/workers).
Full detail is on [the WorkerKit MCP server](/glossary/workerkit-mcp-server) page;
the short version, in the order you do it:

1. **Add the workers endpoint to your client.** In any MCP client that supports
   remote servers, add `https://mcp.workerkit.ai/workers` as a connector. In
   Claude Code that is one line:

```
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers
```

2. **Authenticate from the client.** Prefer this over pasting a key. The client
   discovers the OAuth flow and sends you to the consent page at
   `workerkit.ai/mcpauth`, where you sign in, choose or create an access key, and
   approve. The client stores the result and you never handle a raw credential.
   Only an account admin can complete this step.

3. **Choose the reach on that page.** The key you approve with carries a set of
   scopes, and the client's reach is exactly those scopes. Start with
   `readWorkers` and `readRuns` so the first session can only look, then add
   `runWorkers`, and the manage scopes only when you want the orchestrator to
   change things.

4. **Say what you want in plain language.** Ask the client what workers you have
   before asking it to do anything with them. The first useful sentence is
   usually "list my workers and tell me what each one is for".

The WorkerKit connection also searches the kit catalog. To discover and read
published worker reports, add the separate Knowledge MCP with the same sign-in:

```
claude mcp add --transport http workerkit-knowledge https://mcp.workerkit.ai/knowledge
```

The same fleet scripts from a shell too: the open-source
[WorkerKit CLI](/glossary/workerkit-cli) binds the same tools to terminal
commands, which suits pipelines and CI, where the plan is fixed rather than
decided receipt by receipt.

### What an orchestration session actually looks like

Read the fleet, run the first worker, then let its report choose the next one.
This is the triage chain above, in the calls the client actually makes:

```
workers_list                                  -> triager #4, researcher #7, drafter #9
worker_run   tokenId=4  prompt="last 24h"     -> receipt: Running, runId A
run_events   runId=A    afterSeq=0            -> poll every 3-5s until settled
run_get      runId=A                          -> report: 3 escalations, accounts named

   (the client reads A's report and writes the next prompt from it)

worker_run   tokenId=7  prompt="<account 1>"  -> runId B
run_get      runId=B                          -> report: renewal in 3 weeks, 2 open items

worker_run   tokenId=9  prompt="<B's report>" -> runId C, the drafted reply
```

Nothing about worker 7 or worker 9 was decided in advance. The fleet was read,
the first run happened, and everything after it was chosen from a receipt.

Two manners to teach the client once, because they are the difference between a
session that works and one that gets throttled:

- **Wait between polls.** A run advances at the speed of a model taking turns,
  so poll its events every 3 to 5 seconds, not in a tight loop.
- **A skipped run is an answer, not an error.** A cap, a usage window or a
  missing app connection comes back as a normal receipt with a reason on it. The
  right response is to report the reason, not to retry the run.

### The reasonable objection

"This is a coordination layer over things that already run on their own. Why not
give one agent every tool and let it do the work directly?"

Because the two answers differ on everything except the first afternoon.

The single agent has to hold the method for every job in whatever context you
give it, hold the access for every job at once, do one thing at a time, and leave
a transcript rather than a record. It is also only as good as the last prompt
somebody wrote.

Fleet orchestration puts the method inside each worker, where it was tested;
keeps the access split, so a wrong step is contained; runs jobs at the same time
rather than in sequence; and leaves a receipt per run that can be read months
later. The orchestrator supplies the one thing a fleet genuinely lacks, which is
a plan for today.

### When not to orchestrate

- **One worker does it.** If the job fits inside a single worker's instruction,
  run the worker. A coordinator over one thing is a hop.
- **The job should be scheduled.** Something needed every morning wants a
  [schedule](/glossary/worker-schedule), not a person asking a client to trigger
  it.
- **You have no workers yet.** Orchestration is a multiplier on a fleet. Build
  the first two workers, then connect a client.
- **The steps must be exact.** A plan that must run identically every time is
  code, not a model deciding what to run next.

### FAQ

#### What is AI worker fleet orchestration?

AI worker fleet orchestration is one AI client breaking a large task into smaller
jobs, handing each to a purpose-built [AI worker](/glossary/ai-worker) in a
[fleet](/glossary/worker-fleet), and reading the results back to decide what
happens next. The client holds the plan; each worker holds its own app access,
its own tested instruction and its own receipt.

#### How does an AI client like Claude orchestrate my worker fleet?

Through the [WorkerKit MCP server](/glossary/workerkit-mcp-server) at
mcp.workerkit.ai. The client connects to the workers endpoint, authenticates over
OAuth, and gets tools for listing workers, triggering a run with a prompt written
for that run, watching it, and reading the report it produced.

#### Can an orchestrating client read my email or write to my CRM?

Only through workers you set up. The key it holds has no app credentials, but run
results (with `readRuns`) and an Action worker's tool results (with
`invokeActions`) can include data from the apps that worker was granted. Choose
the worker's app access and the key's scopes together. When a worker acts during
an orchestrated run it uses its own permissions,
and the [app firewall](/glossary/app-firewall),
[contact rules](/glossary/contact-rules) and [redaction](/glossary/redaction)
apply exactly as they do on a scheduled run. A prompt cannot widen them.

#### Can one AI worker's result be used to run another worker?

Yes, and that is the most common shape. The client reads the finished
[receipt](/glossary/run-receipt) from the first run and writes the next worker's
prompt out of what it found, so a triage worker's list of accounts becomes the
research worker's subject, and the research worker's findings become the drafting
worker's input. Workers share no memory and no permissions with each other, so
the orchestrator carrying a result across is what makes the handoff possible at
all.

#### Can I run several AI workers at once?

Yes, and that is most of the point. Each run happens inside its own worker rather
than in the client's context, so a sweep across many subjects runs in parallel
instead of one after another. Runs draw on the account's normal allowances, and
run triggers are limited to 30 a minute per account.

#### Do orchestrated runs cost more than scheduled ones?

No. A run triggered by a client is metered like any other run: its
[tool calls](/glossary/tool-call) count against the daily allowance and its model
tokens are billed at provider list price with no markup. What changes is how many
runs you choose to trigger.

#### Do I need to write code to orchestrate a worker fleet?

No. The orchestration happens in the conversation: you describe the outcome, and
the client decides which workers to run, with what prompt, in what order. Code is
an option, not a requirement.

## AI workforce

URL: https://workerkit.ai/glossary/ai-workforce
Also called: company AI workforce, enterprise AI workforce
Updated: 2026-11-13

**What is an AI workforce?** An AI workforce is the set of AI workers a company runs, with each job's method, permissions, limits and run record retained between requests.

A useful method becomes more valuable when the company can keep it, authorize
its use and inspect its results. In WorkerKit, an AI worker gives that method a
persistent home. The workforce is the collection of workers your company runs,
whether they work independently or hand work to one another.

The change is about who owns and operates the work. A worker can handle one
investigation on demand, respond to a supported event or run every morning.
Its usefulness does not depend on running continuously.

### Workforce, workflow, worker and kit

These words describe different parts of the system. A
[worker kit](/glossary/worker-kit) is what you install; the worker it creates
is what carries out the job.

| Term | What it means | What you decide |
| --- | --- | --- |
| Job | The work to be done | The required result and its acceptance criteria |
| Worker | The configured agent that carries out a job | Its instructions, app access, limits and owner |
| Workforce | The workers your company or team runs | Which jobs the company can perform and who supervises them |
| Workflow | The process workers carry out together | The sequence, handoffs and handling of uncertain results |
| Kit | The reusable definition you install | Whether its method and requested access fit your job |
| Run | One execution of a worker | The input for this request and whether the result was acceptable |

A coordinating kit can install with supporting kits as a connected group of
workers. The kit, the installed group and the process they carry out remain
distinct. Adding an independent reporting worker also expands the workforce;
it does not require connecting every worker into one workflow.

### How does a managed cloud support an AI workforce?

WorkerKit is built from the ground up for people, AI models and workers to
operate together. People set direction and decide what a good result looks
like. AI models reason and coordinate work. Workers carry out the jobs using
the apps, data and shared knowledge their permissions allow.

| Part of the workforce | Its role |
| --- | --- |
| People | Set goals, grant authority and review results and exceptions |
| AI models | Interpret requests, reason about the work and coordinate workers |
| Workers | Execute defined jobs with their own instructions, access and limits |
| Apps and databases | Provide the systems workers read, update or run |
| Shared knowledge | Make approved facts and published reports available to authorized readers |
| Company controls | Govern access, credentials, network connections, spending and activity records |

The cloud supplies a place for these parts to operate when a laptop or chat
is closed. A model can change while the worker's instructions, app grants and
limits remain in the company account. Changing the model still calls for
checking its results on the job.

WorkerKit's private managed cloud brings workers, hosted apps and databases
into an isolated company environment.
The published plans cover shared cloud. See the
[WorkerKit environment](/#controls) and the
[workforce operating guide](/blog/from-ai-tools-to-an-ai-workforce) for how
these parts fit together.

### What stays after an AI worker finishes?

The worker keeps its configured method, app access, limits and enabled
[memory](/glossary/worker-memory) between requests. Each run leaves a
[receipt](/glossary/run-receipt) that records execution and cost. The next
authorized request can use the worker without reconstructing that setup.

Persistence does not mean the model is continually thinking or the worker is
continually watching an inbox. A daily schedule starts daily runs. An on-demand
worker waits for a request. A supported event can start a run when the event
arrives. Choose the start condition for the job's actual response-time needs.

The receipt and the retained method serve different purposes. The method says
how future work should happen. The receipt helps explain what happened in one
execution. Neither proves that a business conclusion was correct; the job still
needs criteria for judging its result.

### What does an AI workforce look like in practice?

Start with [Inbound Lead Qualifier](/kit/inbound-lead-qualifier). Its published
job reads an inquiry, checks the CRM, creates or updates records, qualifies the
lead and prepares a reply draft. It supports on-demand and event-driven runs.
Its email permissions include reading and drafting; they do not include sending
the customer reply.

The sales team supplies the ideal customer profile and reviews the worker's
access and limits. A responsible person checks the qualification and draft.
After that inquiry is handled, the worker remains available for the next
authorized request with the same method and controls.

As more jobs prove useful, the team can install other kits or build its own
through [Build](/build). Reps can install the same kit with their own connected
accounts, or authorized callers can reach a shared worker through scoped
access. Neither arrangement grants everyone the same app permissions.

The [inbound sales guide](/guides/ai-workers-for-inbound-sales) covers the
setup and handoffs. The workforce idea is the broader ownership pattern:
the company retains the jobs and their methods as people and requests change.

### What does the company control?

Treat each job as something a person is responsible for operating. Installing
a kit supplies a starting method; it does not decide the company's business
rules for it.

| Decision | What to establish for the job |
| --- | --- |
| Ownership | Who reviews results, investigates failures and decides whether to keep running it |
| Method | The instructions or decision rules and what counts as an acceptable result |
| Authority | The connected apps, operations and supported field restrictions the worker needs |
| Spending | Execution limits per run, per day and for the account |
| Start condition | An explicit request, a schedule or a supported event |
| Review | Where drafts, uncertain decisions and failures go for attention |
| Improvement | Which changes are reviewed and which enabled learning mode may apply instruction changes |

WorkerKit holds app credentials and checks calls against the worker's granted
[app access](/glossary/app-firewall). The company can choose among supported
models while retaining the worker's job configuration. Model choice and
application authority answer separate questions: what intelligence the job
uses, and what it is allowed to do.

Spending limits govern execution usage. They are not a ceiling on the value of
a purchase, refund or other business commitment an allowed app action could
make. Design the job and its grants around those consequences too.

### How does an AI workforce improve over time?

Start by reviewing real results against the job's criteria. Where learning is
enabled, language workers can check results and test instruction changes
against reviewed runs. Depending on the configured mode, qualifying changes
wait for approval or apply within the selected limits.

Instruction improvement changes the method for future runs; it does not train
the underlying model. Memory has separate controls. Sharing a kit also differs
from sharing everything a worker remembers: reusable instructions do not imply
that every worker can read every other worker's data.

Measure progress through [cost per acceptable result](/blog/cost-per-acceptable-ai-result),
including review and correction effort. More runs or more workers alone do not
show that the workforce is helping.

### When does a separate workforce platform help?

A managed runtime is useful when valuable jobs need a persistent home with
consistent access, spending controls and records across callers and teams.
The [move from AI tools to a workforce](/blog/from-ai-tools-to-an-ai-workforce)
is a decision about operating those jobs, rather than a requirement to replace
the assistants people already use.

Assistants and automation platforms can already schedule work and connect
apps. If your current setup produces acceptable results with clear ownership
and manageable operating effort, adding another platform needs a specific
benefit. A one-off question that needs no retained method may be well served
by the assistant you already have.

For a job worth retaining, browse the [kit directory](/kits), choose its
smallest useful scope and identify its owner. To plan a private managed cloud
environment, [tell us about your work](/#request).

### FAQ

#### Does an AI workforce have to run all the time?

An AI workforce does not have to execute continuously. Its workers retain
their configuration between runs and start on explicit requests, schedules
or supported events, according to the job.

#### Is an AI workforce the same as an AI workflow?

An AI workforce is the collection of workers a company runs. A workflow is a
process those workers carry out together; the same workforce can include
independent jobs and several separate workflows.

#### Does installing a kit create the whole workforce?

Installing a kit creates a worker, or a connected group when the kit includes
supporting kits. The workforce grows as your company adds useful jobs and
assigns the access, limits and responsibility for each one.

#### Does a worker asking for review hold every app write?

A worker asking a person for an answer is different from a policy that holds
app writes for approval. Design the job to prepare drafts or route uncertain
decisions to a person, and review which write operations its grants actually
allow.

## app firewall

URL: https://workerkit.ai/glossary/app-firewall
Also called: agent permissions, per-app access control, agent access control
Updated: 2026-07-30

**What is an app firewall for AI workers?** An app firewall decides which connected apps an AI worker may reach and at what level, so it holds only the access you granted, never your whole account.

Connecting an app to an AI agent usually means handing over an entire account.
The app firewall exists so that is not the deal.

### What "connect your account" normally means

| | The usual deal | With an app firewall |
| --- | --- | --- |
| Scope granted | Everything the account can do | Per app, at Off, Read or Write |
| Who holds it | The assistant you are using | One worker, with its own key |
| Narrowing later | Disconnect and start over | Narrow it, the worker keeps running |
| Reach | Anything you can reach | Nothing you did not connect |
| Blast radius of a mistake | The whole account | One worker's granted level |

### Off, Read, Write

Access is granted **per app** and **per level**:

- **Off**: the worker cannot reach this app at all.
- **Read**: it can look, and cannot change anything.
- **Write**: it can act.

Granting only the level the job needs is the whole practice. Worked through three
real kits, the pattern is visible:

| Kit | Apps and level | Why |
| --- | --- | --- |
| [Engineering Pulse](/kit/engineering-pulse) | github: Read | A digest reads; it never pushes |
| [Executive Daily Briefing](/kit/executive-daily-briefing) | calendar, email, tasks: Read | It summarises three sources and writes nothing back |
| [Support Inbox Triager](/kit/support-inbox-triager) | email: Write, tasks: Write | Drafting a reply and filing a ticket are both writes |

Notice what each one does **not** have. The briefing worker touches three apps
and cannot change any of them. The triager has no calendar access, because
classifying a support message does not require your schedule.

This is why a [kit](/glossary/worker-kit) states the apps and the access it wants
**before** you take it. You approve a specific request rather than a blanket one.

### Narrow it later, and the worker keeps running

Permissions are not a one-time setup decision. You can narrow or switch off any
of it afterwards, and **the worker keeps running with whatever is left.**

That behaviour is deliberate and unusual. Most systems treat a revoked permission
as a fatal error, which teaches people never to revoke anything. Here the worker
degrades: it does the parts of its job it still has access for, and the
[receipt](/glossary/run-receipt) records what it could not do.

The practical effect is that you can start a worker at Read, watch a week of
receipts, and grant Write once you agree with its judgement. Reversible decisions
get made; irreversible ones get postponed forever.

### What it protects against

Three distinct risks, worth separating because they need different answers:

- **Blast radius.** One key per worker with its own scope list means a worker
  that misbehaves misbehaves narrowly, and can be switched off without touching
  any other worker in the fleet.
- **Scope creep.** An agent given broad access will eventually use it in a way
  nobody intended, not through malice but because a model with a tool reaches for
  it. Access it does not hold is access it cannot reach for.
- **Reachability.** A kit cannot reach an account you have not connected. The
  publisher of a kit never gains access to your data.

### What it does not do

Naming the limits is what makes the rest credible. The app firewall answers
"which apps, at what level" and nothing else:

| Question | Answered by |
| --- | --- |
| Which apps, and Off, Read or Write? | The app firewall |
| Which **people** may it read about or contact? | [Contact rules](/glossary/contact-rules) |
| What must never leave, whoever it goes to? | [Redaction](/glossary/redaction) |

Write on email means the worker may send mail. It does not say who to. A support
worker should be able to reply to customers and should not be able to email your
board because a customer mentioned them, and access levels cannot express that
difference: both are "send an email". That is why the three layers compose rather
than overlap.

### The failure mode it is designed around

The failure worth designing against is not a hostile model. It is a **helpful**
one.

An agent under pressure to complete a task will use whatever is in reach. Give a
triage worker Write on the CRM "just in case" and eventually a run will decide
that updating a record is the helpful thing to do, and it will be right about
half the time. Nobody wrote an instruction telling it to; it simply had the tool.

The mitigation is not a better prompt. It is not holding the tool.

### It is not an upsell

The complete safety layer, the app firewall, redaction, contact rules, and one
key with its own scope list per worker, ships on **every plan, Free included**,
and is never tier-gated.

Charging for the controls that make autonomy safe would mean selling the risky
configuration as the default and the safe one as an add-on. Manage connections on
[the Connected apps page](/apps), and see [/pricing](/pricing) for what each plan
does change.

Published WorkerKit plans and prices apply to shared cloud.

### FAQ

#### What access does an AI worker get to my accounts?

Only what you grant, per app and per level: Off, Read or Write. Every
[kit](/glossary/worker-kit) states the apps it uses and the access each needs
before you take it, you approve each connection yourself, and a kit cannot reach
an account you have not connected.

#### Can I take access away after deploying a worker?

Yes, at any time. Narrow a permission or switch one off and the worker keeps
running with whatever is left, recording on its receipt what it could not do. It
never quietly regains access you removed.

#### Does the publisher of a kit see my data?

No. Taking a kit creates a worker in your own account with its own key. The
publisher wrote the instruction and the access requirements; they gain no access
to the accounts you connect.

#### Is the app firewall included on the free plan?

Yes. The complete safety layer ships on every plan including Free and is never
tier-gated, alongside [contact rules](/glossary/contact-rules) and
[redaction](/glossary/redaction).

#### Why not just tell the agent what it may not do?

Because an instruction is a request evaluated by a model against every other
pressure in its context, and a helpful model under pressure can talk itself past
one. An access level is enforced outside the model, so there is nothing to
negotiate with.

## BYOK (bring your own key)

URL: https://workerkit.ai/glossary/byok
Also called: bring your own key, own model key, own API key
Updated: 2026-07-29

**What is BYOK (bring your own key)?** BYOK, bring your own key, is adding your own model provider API key so token usage bills straight to your provider account instead of the platform's balance.

BYOK answers a question that gets asked the moment an AI product starts metering
tokens: can I just use my own account?

On WorkerKit, yes. Add an Anthropic, OpenAI, Google or xAI key and tokens for
that provider bill straight to your provider account instead of drawing on the
[runtime wallet](/glossary/runtime-wallet).

### BYOK vs the wallet

| | The wallet | BYOK |
| --- | --- | --- |
| Who bills you for tokens | WorkerKit, from a prepaid balance | Your model provider, directly |
| Token price | Provider list price, no markup | Provider list price, whatever you negotiated |
| Platform fee | 5.5% on loading, $1 minimum | None on the first 1M tokens a month, then 5% of list |
| Setup | None | One key per provider |
| Runs out how | A run is skipped before it starts | Your provider's own limits apply |
| Best when | You want it simple | You have committed spend or want one bill |

### The fee, precisely

- **The first 1M tokens each month carry no platform fee at all.**
- Usage past that is **5% of list price**, settled from the wallet.
- Removing a key returns that provider to wallet billing, with nothing to
  migrate.

Keys are added per provider, so a mixed setup is normal and expected: your own
Anthropic key for the workers you run hardest, the wallet for everything else.
That also means BYOK does not force an all-or-nothing decision, which is what
makes it safe to try on one provider.

### Where the crossover actually is

The instinct is that BYOK is "the cheaper option". Under 1M tokens a month it
mostly is not, because both routes bill tokens at list price and neither charges
a platform fee in that range.

| Monthly tokens | Wallet | BYOK |
| --- | --- | --- |
| Under 1M | List price, plus 5.5% when you load | List price, no platform fee |
| Over 1M | List price, plus 5.5% when you load | List price, plus 5% of list past the first 1M |

Note what the two fees are charged **on**. The wallet's 5.5% is charged on money
you load, once. BYOK's 5% is charged on usage past the first million, every
month. Which is cheaper depends less on volume than on how steady your usage is:
lumpy usage suits the wallet, sustained heavy usage suits a negotiated provider
rate.

What BYOK buys at low volume is **control, not savings.**

### Why teams actually want it

Three real reasons, in the order they come up:

- **Existing commitments.** Negotiated rates or committed spend with a provider
  are wasted if usage routes through someone else's account.
- **One bill.** Finance already reconciles a provider invoice. BYOK keeps model
  spend there instead of adding a second vendor line.
- **Direct relationship.** Rate limits, quota increases and abuse questions are
  between you and the provider, with nobody in between.

Enterprise accounts can bring their own provider keys or commit to capacity
instead, which is the same argument at a larger size.

### What BYOK does not change

This is where the misunderstanding usually sits. BYOK changes **who bills you
for tokens** and nothing else:

- Runs still execute on WorkerKit's [managed runtime](/glossary/hosted-runtime).
  There is still no machine of yours to keep alive.
- Plan limits still apply: workers, [tool calls](/glossary/tool-call) a day,
  schedule granularity, log history.
- The safety layer still applies, and was never tier-gated:
  [app firewall](/glossary/app-firewall),
  [contact rules](/glossary/contact-rules),
  [redaction](/glossary/redaction).
- [Run receipts](/glossary/run-receipt) still record what each run consumed.

A worker like [Engineering Pulse](/kit/engineering-pulse), reaching GitHub on a
morning schedule, behaves identically either way. The only difference is which
invoice its tokens land on.

### The failure mode worth planning for

With the wallet, running out is a skipped run and a line on the receipt. With
BYOK, running out is **your provider's failure mode**, not WorkerKit's: an
exhausted quota, a rate limit, or a suspended key produces a failed run rather
than a tidy skip.

That is not a reason to avoid BYOK, but it does move the monitoring
responsibility to you. If your provider account has a hard spend cap, the fleet
inherits it.

### When not to use BYOK

- **You are under 1M tokens a month and want the simplest setup.** The wallet
  costs about the same and has nothing to configure.
- **You want the yearly runtime credit to do the work.** Pro yearly loads $50
  and Team yearly loads $500 into the wallet, drawn before your own money. BYOK
  routes around that credit for the providers it covers.
- **Nobody owns the provider account.** A key tied to one person's personal
  provider login is a fragile dependency for an unattended fleet.

### FAQ

#### Which providers can I bring a key for?

Anthropic, OpenAI, Google and xAI, matching the models WorkerKit runs: Claude,
ChatGPT, Gemini and Grok. Keys are added per provider, so you can use BYOK for
one and the wallet for the rest.

#### Is BYOK cheaper than the wallet?

Not automatically. Under 1M tokens a month both bill at provider list price with
no platform fee, so the difference is control rather than cost. Above 1M tokens
BYOK charges 5% of list, settled from the wallet, which is worth comparing
against the wallet's 5.5% load fee.

#### Does WorkerKit still take a cut of my tokens with BYOK?

Only past the first 1M tokens each month, at 5% of list price. Below that there
is no platform fee at all, and tokens bill directly to your provider account.

#### What happens if I remove my key?

Removing a model provider key returns that provider to wallet billing
immediately, with nothing to migrate. Workers keep running; only the billing route changes.

#### Does BYOK let me run workers on my own infrastructure?

No. BYOK changes who bills you for tokens, not where runs execute. WorkerKit
hosts every run today, and running a worker on your own machine or
infrastructure is coming later. Full pricing is on [/pricing](/pricing).


Published WorkerKit plans and prices apply to shared cloud.

## calibrated confidence

URL: https://workerkit.ai/glossary/calibrated-confidence
Also called: model calibration, calibrated probability, confidence score
Updated: 2026-09-16

**What is calibrated confidence?** Calibrated confidence is a model score that matches reality: of the answers it rates 0.8, about 80 percent turn out right, so the number can be acted on.

Calibration is a property of the score, not of the answer. A model can be sure
and wrong. Calibration is the thing that makes its certainty worth reading.

### The plain test for calibration

Take every answer the model scored around 0.8. Count how many turned out right.

If it is near 80 in 100, the score is calibrated and you can gate on it. If it
is 55 in 100, the model is overconfident and 0.8 means nothing. If it is 98 in
100, it is underconfident, and you are paying people to review work that did not
need them.

That is the entire idea, and almost nobody states it this simply. Calibration is
a frequency claim about a **bucket** of answers, not a feeling about any single
one. You cannot tell from a single answer. You need a set whose real outcome you
already know.

The check has a shape you can run on a spreadsheet:

| Score bucket | Answers | Turned out right | Calibrated would be | Read |
| --- | --- | --- | --- | --- |
| 0.9 to 1.0 | 240 | 231 (96%) | about 95% | close enough to act on |
| 0.7 to 0.9 | 180 | 139 (77%) | about 80% | usable, slightly optimistic |
| 0.5 to 0.7 | 120 | 71 (59%) | about 60% | honest, and too weak to act on |
| 0.3 to 0.5 | 60 | 22 (37%) | about 40% | honest: it is telling you it does not know |

Those numbers are illustrative, not measured. A model whose 0.9 bucket comes back
at 62 percent is not one you can automate against at 0.9, however good the
answers read.

Two practical notes on running it. Bucket edges come from where your scores
actually land rather than from round numbers, which is why the ladder above
stops at 0.3 instead of at zero. And a bucket needs enough answers to say
anything: fifty outcomes pin a bucket sitting near 80 percent to roughly plus or
minus 11 points, which is enough to tell 80 percent from 55 percent and never
enough to tell it from 85.

### Why asking a model how confident it is does not give you this

Ask a chat model "how confident are you?" and you get a sentence, produced the
same way the answer was: token by token, shaped by how you phrased the prompt and
by what confident writing looks like in the training data. It is a claim about
certainty rather than a measurement of one.

This is not a reason to sneer at the technique. Real signals exist: token log
probabilities are numbers the model actually produced, measuring how often
repeated answers agree is a genuine method, and so is training a small verifier
on your own labelled cases. A self-reported score can even turn out to be
calibrated, which is an empirical question the bucket test answers.

The narrow point is that the number inside the sentence has not been measured
against anything, and adding "be honest about your uncertainty" to the
instruction does not change that.

### Three different things get called confidence

| | A self-reported score | A distribution over declared options | A measured evaluation |
| --- | --- | --- | --- |
| What it is | Text the model generated | A statistic over the answer's own probabilities | Your accuracy on labelled cases |
| What it measures | How sure that sentence sounds | How concentrated the answer is | How often it was actually right |
| Where it comes from | The same pass that wrote the answer | The answer envelope | Your labelled set |
| Threshold on it? | Not until you have checked it | Yes, once you have checked it | It **is** the check |
| Cost to get it | Free | Free, when the API returns one | Labelling time |

Only the third column is calibration. The first two are inputs to it.

### The derived kind, and where it comes from

Some APIs hand you the middle column directly, computed rather than composed.
TypeSafe's documentation for its Jev model states the mechanism in one line:
choice and score answers "carry a `confidence` between 0 to 1, derived from the
answer's probability distribution". Their confidence page adds that the shape of
that distribution is what carries the meaning, concentrated on one outcome being
a confident answer and spread out an uncertain one. All of that is
vendor-published and early access, and it is the number a decision worker on
WorkerKit gates on. Their yes/no question type carries no confidence field at
all.

A derived score is a better starting point than a generated one, because it is a
statistic over something the model produced rather than prose about it. See
[system one model](/glossary/system-one-model) for the shape of model that
returns one, [structured output](/glossary/structured-output) for why a declared
schema makes the distribution possible, and
[Jev, TypeSafe's System One model](/blog/jev-and-decision-models) for what that
vendor does and does not publish about it.

It is still not calibration. Derived confidence says the mass was concentrated.
Calibration says that when it concentrates, the answer is right that often.

#### A spread answer is not always doubt

Spread means the model did not put its mass on one option. It does not say why,
and there are three reasons:

- The input is genuinely ambiguous, and hedging is correct.
- Two options are both acceptable. A support email fairly described as billing
  or as account splits the mass between them, and either route is fine.
- Your options overlap, so the model is being asked to separate things that are
  not separate. That is a defect in the question rather than doubt in the model,
  and it is fixed by writing options that exclude each other.

So a low score is a reason to stop and hand over, not evidence that the answer
was wrong.

### Calibration on their data is not calibration on yours

A vendor's calibration result is a claim about the vendor's distribution of
inputs. Your inbox is not their benchmark set. The same score can be honest on
generic English and badly optimistic on your invoices, your dialect of
shorthand, and the three edge cases your customers produce weekly.

TypeSafe's own documentation makes the same argument from the other end:
threshold values, it says, depend on your domain and on how the model performs
for your use case, and different actions in one system should be gated at
different levels depending on the consequences of being wrong. Its own bands are
prose rather than numbers, and the 0.9 and 0.5 in its worked code example are
illustrative rather than a published ladder: even at 0.9, that example confirms
with the user before acting on a high stakes decision.

Any number you gate on has to be re-derived against your own labels, which is
what a [confidence threshold](/glossary/confidence-threshold) is and how you set
one.

### When there is nothing to calibrate

Calibration is a measurement, and some setups cannot produce one. Four of them,
before you budget an afternoon for labelling:

- **The model returns no score.** A general chat model handed a classification
  task returns an answer and nothing to bucket, and a yes-or-no probability is
  the answer itself rather than a confidence in it. With no score there is
  nothing to calibrate, and the controls left are structural ones.
- **Nobody ever learns the outcome.** Calibration needs the truth to arrive
  later. If the worker files an item into a queue no one audits, its answers are
  never scored right or wrong at all, and no amount of volume produces a label.
  Fix the feedback path first; the measurement is downstream of it.
- **The interesting cases are rare, even at high volume.** Ten thousand items a
  month with eleven genuine escalations in them will fill the top bucket fast
  and never fill the bottom one, which is the bucket the whole decision turns
  on. Route the rare class to a person and measure the common one.
- **The setup changes weekly.** A calibration result belongs to one model, one
  instruction and one option list. Change any of the three and it expires. If
  you are still rewriting the question every few days, you are measuring
  something that will not exist next week.

### Why this matters for unattended work in particular

When a person is watching, a bad score costs a second of attention. An
[AI worker](/glossary/ai-worker) runs on a schedule at 3am and nobody reads the
borderline case. Where a score is what decides between acting and escalating,
that score is the entire review, which is why it has to mean something.

A decision worker returns a confidence with every judgment, and that is not
calibration: it is the model's read of one answer, where calibration is a hit
rate across a bucket of answers whose outcomes you already know. No platform can
compute calibration for you, because the labelled set it needs is yours. Every
run of a decision worker leaves a
[run receipt](/glossary/run-receipt), so you can read back a month of decisions
and mark which were right. That marked set is the data the bucket test needs.

Until you have it, gate on structure rather than on a number: hold each app one
step below the action you would regret, and write the uncertain tail into the
instruction as a handover. [Support Inbox Triager](/kit/support-inbox-triager) is
built that way. It classifies against a fixed rubric it fetches at run time,
drafts replies and lists anything abusive or legal for a human, and its email
permissions cover reading, labelling and creating a reply draft, with no send
operation granted at all. Its escalation does not depend on a threshold being
right. More of that pattern is in
[failing safely on an unattended fleet](/blog/fail-safely-unattended-fleet).

One limit no score removes: a calibrated number does not make an unsupervised
decision about a person acceptable. Hiring, credit, benefits and discipline carry
legal obligations whatever the confidence value. Sorting and surfacing for a
reviewer is fine. Deciding is not.

### FAQ

#### What does calibrated confidence mean?

It means the score matches the observed hit rate. Of all the answers a model
scores 0.8, about 80 percent should be correct; of those scored 0.6, about 60
percent. A number that does not hold to that is one you cannot act on, however
precise it looks.

#### Can I trust a model that says it is 95 percent sure?

Not on the strength of the sentence. A model asserting 95 percent in generated
text is writing, not measuring, and a confident wrong answer often scores itself
highest. Trust it after you have checked a bucket of such answers against known
outcomes on your own data.

#### How do I check whether a confidence score is calibrated?

Collect a few hundred answers with their scores, label which were actually right,
group them into score buckets, and compare each bucket's hit rate with its score.
Two hundred labelled cases is enough to see whether a threshold is plausible. It
takes a spreadsheet and honest labels, not a statistics team.

#### Does low confidence mean the answer is wrong?

No. It means the model's answer was spread across options. Sometimes the input
is genuinely ambiguous, sometimes two options are both acceptable, and sometimes
your option list overlaps and should be rewritten. Low confidence is a reason to
route to a person, not a verdict on correctness.

#### Is the confidence a worker returns already calibrated?

Not by itself. A decision worker returns a confidence with each judgment and
will not act below its confidence floor, but that score is the model's read of
one answer, not a hit rate measured on your outcomes. Only your own labelled
runs produce that. Until they do, what holds is structural: per-app permissions,
contact rules, redaction, and a receipt for every run you can label afterwards.

## confidence threshold

URL: https://workerkit.ai/glossary/confidence-threshold
Also called: confidence floor, confidence routing, escalation threshold
Updated: 2026-09-16

**What is a confidence threshold?** A confidence threshold is the score an automated decision must clear before it is acted on, sending anything below it to a person instead.

A confidence threshold turns a number into a policy. A model returns a score
between 0 and 1. The threshold is the line your code compares it against, and
the comparison decides what happens next: act on it, ask a person to confirm, or
hand the item over untouched.

The number belongs to the model. The line belongs to you.

### Three bands, not one line

One threshold gives two outcomes, which is usually too blunt. Two thresholds
give three bands, and the middle one carries most of the value:

- **Act.** Above the upper line the system does the thing and records it.
- **Confirm.** Between the lines it prepares the action and waits for a yes.
- **Escalate.** Below the lower line it does nothing and routes the item to a
  person, with whatever it worked out attached.

| Band | What the code does | Who sees it at the time | Cost of being wrong |
| --- | --- | --- | --- |
| Act | Performs the action | Nobody, until someone reviews | A wrong action, already taken |
| Confirm | Prepares it, waits for a yes | The person asked | A minute of somebody's attention |
| Escalate | Stops, routes the item | Whoever owns the queue | A delay, and a queue to clear |

The bands are not equal in weight. Moving an item from confirm to act saves
seconds. Moving one from escalate to act can cost you a customer. Size them by
consequence, not by volume.

### Where a published ladder fits

A vendor that returns a confidence number often publishes suggested bands beside
it. TypeSafe's documentation for its
[System One model](/glossary/system-one-model) describes three in words rather
than numbers: high confidence means a clear read you can proceed on without
human involvement, medium means proceed with caution, and low means do not act,
but route to a human or fall back to another system. Its worked example uses 0.9
and 0.5 as the lines, and the branch above 0.9 still confirms with the user
before executing, because that example's action is a high stakes one.

The vendor states both caveats itself: the right values depend on your domain
and on how the model performs there, and different actions inside one system
should be gated at different levels according to the consequences of getting
each wrong. A published ladder is a worked example to evaluate, not a setting to
copy.

### How to set one, as a procedure

A threshold is derived, not chosen, and deriving it takes an afternoon:

1. **Take a real sample.** One to three hundred items you actually received,
   awkward ones included. Invented examples are always easier than real ones.
2. **Label it by hand first.** Decide the right answer before you see any score.
   Labelling afterwards quietly turns into agreeing.
3. **Run the sample** and keep each score beside its item and your label.
4. **Sort by score, highest first.**
5. **Find the disagreement line**, the point walking down that list where the
   model's answer starts differing from your label.
6. **Set the act floor above it, with room to spare**, and the escalate floor
   where disagreement stops being occasional.
7. **Keep the sample** and re-run it after a model or prompt change. A threshold
   is only valid for the setup it was measured on.

If disagreement is spread evenly through the sorted list instead of clustering
at the bottom, the score is not separating easy items from hard ones and no
threshold will fix that. The property being tested there has a name,
[calibrated confidence](/glossary/calibrated-confidence).

### Both directions cost something

| Floor set | What you buy | What it costs | How you find out |
| --- | --- | --- | --- |
| Too low | Volume handled automatically | Wrong actions taken unattended | A complaint, or a receipt someone reads |
| Too high | Almost no wrong actions | A queue nobody clears | Slowly, or never |

Only one of those failures is visible. A wrong send arrives in somebody's inbox
and gets reported. A queue growing faster than it is cleared just sits there,
and the usual ending is people approving in batches without reading, which is
having no threshold, with paperwork on top.

### A probability is not a severity score

This is the commonest mistake, and easy to make because the numbers look alike.

For a yes-or-no question the returned probability **is** the answer, not a
measure of how much. A 0.55 on "is this request fraudulent" means yes and no are
close to equally likely, not "mildly fraudulent". Thresholded as an intensity it
gives you a system that treats its most uncertain items as its moderate ones.
TypeSafe's wire makes the distinction structural: choice and score answers carry
a confidence derived from the shape of the answer's probability distribution,
and yes-or-no answers carry no confidence field at all.

When you want intensity, ask for intensity, which the vendor's own advice puts
as using a score question measuring along defined levels. One reason
[structured output](/glossary/structured-output) is worth having is that it
forces you to say which of the two you are asking for.

### Escalation has to land somewhere a person looks

A threshold routing low scores into a queue nobody owns is decoration. The path
needs four things before the line means anything: a named owner rather than a
team alias, a place they already work such as an inbox or a helpdesk view, a
time limit, and a stated default for when that limit passes, because "it sat
there" is also a decision, just not one anybody made.

### When a threshold is the wrong tool

A floor is a way of spending a number you already trust. Five situations where
there is no such number, and adding a line to your code only hides that:

- **The score does not separate.** If the disagreement in your sorted sample is
  spread through it rather than piled at the bottom, every floor you pick splits
  the pile at random. Fix the question or the model, or read
  [calibrated confidence](/glossary/calibrated-confidence) for what to measure
  first.
- **Ordinary code already knows.** Amount over a figure, sender on a list, date
  in the past, two fields equal. Arithmetic and lookups are exact, free and
  reviewable by anyone. A model score is a probabilistic instrument for
  questions arithmetic cannot answer, and it is strictly worse for the ones it
  can.
- **The volume is too low to measure on.** A floor is derived from a sample. If
  you see twenty of these a month, you cannot find the disagreement line, and a
  number copied off a vendor page is a guess with a decimal point on it. Have
  the person do the twenty.
- **Being wrong is unacceptable and nobody is downstream.** A threshold makes
  uncertainty visible. It does not make the model right, and it cannot invent a
  reviewer. Where there is no acceptable error rate, the honest answer is not a
  higher floor, it is not running that step unattended.
- **The decision has legal consequences for a person.** Hiring, credit,
  benefits, discipline. These are not gated by a number at any value. Sorting
  and surfacing the case for a human reviewer is fine. Letting the floor decide
  is not, however well calibrated the score behind it is.

### What this looks like on WorkerKit today

WorkerKit runs two shapes of worker, and only one has a number to threshold on.

A **decision worker** judges each item with typed questions and routes on the
answer in code, with [no agent loop](/blog/decision-models-vs-agents) in
between. A confidence floor is required, and below it the worker does not act:
the item escalates to a person.

An **agent worker** returns work rather than a calibrated number, so its three
bands are built out of controls instead of a score.

| Band | How it is built on an agent worker | Where it surfaces |
| --- | --- | --- |
| Act | Instruction says do it, app held at Write | A [run receipt](/glossary/run-receipt) |
| Confirm | Instruction says draft and stop, app held at Read | A draft waiting in your own account |
| Escalate | Instruction says ask, [contact rules](/glossary/contact-rules) cap who it may reach | A message to you, item untouched |

The load-bearing row is the middle one. Holding an app at Read in the
[app firewall](/glossary/app-firewall) makes the worst case a wrong draft
instead of a wrong send, and unlike a line in an instruction it is enforced
outside the model, which is the subject of
[an instruction is not a control](/blog/instruction-is-not-a-control). A
decision worker's reads and actions go through that same door, one tool call on
its own key.

[Support Inbox Triager](/kit/support-inbox-triager) is the shape in practice: it
reads, sorts and drafts on its schedule, and a person sends. Receipts make each
run reviewable, which is how you learn whether your floor sits near right, and
the order to roll that out in is in
[rolling out an AI worker safely](/blog/rolling-out-an-ai-worker-safely).

### FAQ

#### What is a good confidence threshold to start with?

There is no portable number. A threshold is a property of your items and your
model together, so it has to be measured: label a sample of your own real items
by hand, score them, sort by score, and find where the model starts disagreeing
with you. Set the floor above that point. A vendor's published ladder is an
example to evaluate against that sample, not a setting to copy.

#### Can I use one confidence threshold for everything a system does?

You should not. Different actions carry different consequences and deserve
different floors: reading a record can be gated far lower than sending a message
or moving money. One global threshold is either too loose for the risky actions
or too tight for the cheap ones, usually both at once.

#### Does a high confidence score mean the answer is correct?

No. A confidence score is derived from the shape of the model's own probability
distribution, so it says the answer is concentrated rather than spread. That is
agreement with itself, not with the world. A confident model can be confidently
wrong, which is why the escalation path still matters.

#### What does a 0.5 mean on a yes-or-no question?

It means yes and no are close to equally likely, not that the thing is half
true. A yes-or-no probability is not a severity score, and reading it as an
intensity is the commonest error with these systems. If you want to know how
much rather than whether, ask a question that measures along defined levels
instead.

#### How does a confidence threshold work on a WorkerKit worker?

A decision worker declares a required confidence floor and does not act below
it: the item escalates to a person. An agent worker returns work rather than a
score, so its equivalents are structural: the instruction telling it when to
stop and ask, the app firewall holding an app at Read so the worst case is a
wrong draft, contact rules limiting who it can reach, and a receipt per run.

## connected app

URL: https://workerkit.ai/glossary/connected-app
Also called: app connection, integration, connected account
Updated: 2026-08-13

**What is a connected app for an AI worker?** A connected app is an account you have signed in to WorkerKit once, which workers can then be granted access to per app and per level.

Connecting an app happens once, at the account level. Granting a worker access to
it happens per worker, per app, per level. Keeping those two steps separate is
what makes a fleet safe to run.

### Connecting is not granting

| | Connecting an app | Granting a worker access |
| --- | --- | --- |
| Happens | Once, on [the Connected apps page](/apps) | Per worker |
| Scope | The account | One worker's key |
| Choice you make | Which account to sign in as | Off, Read or Write for this worker |
| Undo | Disconnect the account | Narrow or revoke, worker keeps running |
| Effect of skipping it | No worker can reach the app | The worker cannot reach it |

The important consequence: **connecting Gmail does not give every worker your
inbox.** It makes the inbox available to be granted. A worker holds only what you
gave it, which is the whole point of the
[app firewall](/glossary/app-firewall).

### What counts as one connection

An **email account** is one Google or Microsoft account a worker signs in as,
Gmail or Outlook, and it brings the calendar, files and tasks that come with that
account. So one Google sign-in can serve four app surfaces.

That matters for the plan limits, which count accounts rather than surfaces:

| Plan | Email accounts |
| --- | --- |
| Free | 1 |
| Pro | 5 |
| Team | 10 |
| Enterprise | Custom |

One connected Google account on Free covers Gmail, Google Calendar, Drive and
Tasks. The limit binds when you need a *second identity*: a shared support inbox
alongside your own, or a second Microsoft tenant.

### How apps are connected

Three shapes, and they behave differently enough to be worth knowing:

- **Granted by sign-in.** Google and Microsoft accounts. You sign in and approve
  the scopes; there is no credential to paste.
- **Installed.** The GitHub App, where you choose which repositories it can see
  at install time, so the narrowing happens in GitHub as well as here.
- **Pasted.** Most other vendors, where you supply a key or token from that
  product.

You can also register a **custom MCP gateway** so a worker reaches a system
WorkerKit ships no integration for. That is [MCP](/glossary/mcp) used as the
wiring, with the same per-worker access model on top.

### Which apps a kit needs, before you take it

Every [kit](/glossary/worker-kit) states the apps it uses and the exact access
each one needs while you are still deciding. Three real examples:

| Kit | Connections it needs | Levels |
| --- | --- | --- |
| [Engineering Pulse](/kit/engineering-pulse) | GitHub | Read |
| [Executive Daily Briefing](/kit/executive-daily-briefing) | One Google or Microsoft account | Read on calendar, email, tasks |
| [Company Knowledge Concierge](/kit/company-knowledge-concierge) | Drive and SharePoint | Read |

The middle row is the useful one: it looks like three connections and is one
account. That is why counting apps overestimates what a fleet actually needs
connected.

Some kits leave an **app slot open** rather than pinning a vendor, so the same
kit works whether your mail is Gmail or Outlook.
[School Email to Calendar](/kit/school-email-to-calendar) is built that way: it
names the surfaces and you fill them when you take it.

### The failure mode: the connection that expires

A connection is a credential, and credentials lapse. A password changes, an
admin revokes an OAuth grant, a token expires, a tenant policy tightens.

What goes wrong is not the error, it is the **timing**. The connection breaks at
some point, and the next scheduled run of every worker depending on it fails or
degrades. Nobody typed anything, so nobody is watching, and the first signal is
usually a digest that did not arrive or a queue that stopped being triaged.

Two things make it survivable. A worker with a broken connection degrades rather
than dying, doing the parts of its job it still has access for, and the
[receipt](/glossary/run-receipt) records what it could not do. And an account
needing attention is shown as such on the Connected apps page rather than being
hidden, so reconnecting is a visible task rather than an archaeology exercise.

### The reasonable objection

"Connecting my email to a third party is the risk. Everything downstream is
detail."

That is the right thing to worry about, and the answer is what happens after the
connection rather than a promise about it. Access is granted per worker and per
level, so a connected inbox is not an inbox every worker can write to.
[Contact rules](/glossary/contact-rules) decide which people a worker may see and
reach, [redaction](/glossary/redaction) decides what may leave, every run is on a
receipt, and any of it can be narrowed later with the worker still running.

The honest part: you are still trusting the platform with a credential. The
mitigations reduce blast radius; they do not eliminate the trust decision, and
anyone claiming otherwise is selling something.

### When not to connect an app

- **No kit you run needs it.** A connection nothing uses is standing risk for no
  benefit.
- **You would have to over-grant.** If the only available account is an admin
  identity with far more reach than the job needs, connect a narrower one
  instead.
- **The data should not leave the source system.** Some material belongs where it
  is, and the right answer is not a worker.
- **You are evaluating.** Connect what the one kit you are testing asks for, not
  everything you might eventually want.

### FAQ

#### What is a connected app in WorkerKit?

An account you have signed in to once at the account level, which workers can
then be granted access to individually, per app and per level. Connecting makes
an app available; it does not give any worker access by itself.

#### Does connecting Gmail give every worker access to my inbox?

No. Connecting makes the account available; each worker is then granted Off, Read
or Write for that app separately. A worker holds only what you gave it, and a kit
cannot reach an account you have not connected.

#### How many accounts can I connect?

Email accounts are limited by plan: 1 on Free, 5 on Pro, 10 on Team, custom on
Enterprise. One Google or Microsoft account covers the calendar, files and tasks
that come with it, so a single sign-in usually serves several app surfaces. See
[/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

#### What happens if a connection expires or is revoked?

Workers depending on it degrade rather than dying: they do the parts of their job
they still have access for and record what they could not do on the
[receipt](/glossary/run-receipt). The account is shown as needing attention on
[the Connected apps page](/apps) so reconnecting is a visible task.

#### Can I connect a system WorkerKit does not integrate with?

Yes, by registering a custom MCP gateway, which lets a worker reach that system
through the [Model Context Protocol](/glossary/mcp) with the same per-worker
access model applied on top.

## contact rules

URL: https://workerkit.ai/glossary/contact-rules
Also called: contact policy, recipient rules, allowlist
Updated: 2026-07-28

**What are contact rules for AI workers?** Contact rules decide which people an AI worker may read about or contact, applied above app permissions so inbox access does not mean reaching everyone in it.

The [app firewall](/glossary/app-firewall) answers "which apps, at what level".
Contact rules answer the question underneath it: **which people**.

### Why app-level access is not enough

Grant a worker Write on email and you have said it may send mail. You have not
said who to, and for most jobs those are very different permissions.

| The worker | Should be able to email | Should not |
| --- | --- | --- |
| [Support Inbox Triager](/kit/support-inbox-triager) | Customers who wrote in | The exec team a customer mentioned |
| [Appointment Reminder Texter](/kit/appointment-reminder-texter) | Clients with a booking tomorrow | Anyone else in the address book |
| [Invoice Follow-up Assistant](/kit/invoice-follow-up-assistant) | The billing contact on an overdue invoice | That contact's whole company |

Access levels cannot express any row in that table, because both sides are just
"send an email". Contact rules can.

### What the rules do, in both directions

**Reads are filtered.** Results exclude restricted contacts, so a worker
summarising a mailbox simply does not see the threads it has no business seeing.
It is not asked to ignore them; they are not in what it receives.

**Sends are refused.** A blocked recipient is rejected rather than quietly
dropped, and the refusal lands on the [run receipt](/glossary/run-receipt) so you
can see it happened.

Filtering reads rather than instructing the model to skip them is the important
half, and it is worth being precise about why.

| | An instruction | A filter |
| --- | --- | --- |
| Where it lives | In the prompt | In the platform |
| Enforced by | The model's judgement | Code the model cannot reach |
| Under a confusing input | May be talked past | Unaffected |
| If the model is prompt-injected | Compromised | Still holds |
| Evidence it worked | The output looks right | Data never arrived |

A model asked to ignore a thread has, by definition, read the thread. If that
thread contains text engineered to redirect it, the instruction is now competing
with the attack. Data that never arrives cannot be reasoned around, which is why
the filter sits before the model rather than inside its prompt.

### The worked case: a reminder texter

[Appointment Reminder Texter](/kit/appointment-reminder-texter) reaches calendar
and messaging to text clients a day-before reminder. It is the sharpest example
because every run sends an outbound message to a real person.

The access grant says: calendar Read, messaging Write. Contact rules say: the
attendees on tomorrow's bookings, and nobody else. Without the second, a calendar
event with a stray attendee, an internal colleague, a vendor, an ex-client whose
record was never cleaned up, is a person who receives a text they did not expect.

The failure is not dramatic. It is one confused recipient, repeated quietly at
scale, and it is the kind of thing you discover from a complaint rather than from
a dashboard.

### Where they fit in the safety layer

Three layers, each doing a job the others cannot:

| Layer | Question it answers |
| --- | --- |
| [App firewall](/glossary/app-firewall) | Which apps, and Off, Read or Write? |
| Contact rules | Which people may it see and reach? |
| [Redaction](/glossary/redaction) | What must never leave, whoever it goes to? |

They compose rather than overlap. A worker can hold Write on email, be barred
from the finance team's threads, and still have an account number stripped from
the one reply it does send.

### The reasonable objection

"An allowlist of contacts is unmaintainable. People join, leave and change roles
every week."

True where the rule is a hand-kept list of individuals, which is why that is the
wrong shape for most jobs. The rules that survive are ones expressed against
something already maintained: the attendees on this booking, the sender of this
thread, the billing contact on this record. Those track reality because somebody
else is already keeping them current.

Reach for an explicit list when the set is small, stable and high-stakes, which
in practice means the block side rather than the allow side: the handful of
people a worker must never contact is short and changes rarely.

### When contact rules are not the right tool

- **The worker sends nothing and reads nothing about people.**
  [Engineering Pulse](/kit/engineering-pulse) reads repository activity; there is
  no contact policy to write.
- **The concern is content, not audience.** If the worry is an account number
  leaking, that is [redaction](/glossary/redaction), and it applies whoever the
  recipient is.
- **The concern is the app, not the people.** If a worker should not touch the
  CRM at all, set that app to Off rather than writing rules about who is in it.

### On every plan

Contact rules ship on **every plan, Free included**, as part of the complete
safety layer, and are never tier-gated.

They also apply when a worker is driven from outside over [MCP](/glossary/mcp):
the tools an external client can see reflect exactly that worker's permissions,
and restricted contacts stay excluded there too. The restraint lives with the
worker rather than with the caller, which is what stops "drive it over MCP" from
being a way around the policy.

### FAQ

#### What are contact rules on an AI worker?

Contact rules are the policy layer deciding which people a worker may read about and
contact. Reads are filtered so restricted contacts never reach the model, and
sends to blocked recipients are refused outright, with the refusal recorded on
the run receipt.

#### Why not just tell the AI not to email certain people?

Because an instruction is a request the model evaluates against everything else
in its context, and a model that has read a thread in order to ignore it is a
model that can be redirected by what the thread says. A filter applied before the
model cannot be argued with.

#### Can a worker email anyone in my address book?

Not unless your rules allow it. Write access on email says a worker may send
mail; contact rules say who to. Both have to permit a recipient before anything
is sent.

#### Do contact rules apply if I drive a worker over MCP?

Yes. The tools an external client can see reflect that worker's permissions, and
restricted contacts remain excluded, because the restraint belongs to the worker
rather than to whatever is calling it.

#### Are contact rules a paid feature?

No. They ship on every plan including Free alongside the
[app firewall](/glossary/app-firewall) and
[redaction](/glossary/redaction). The complete safety layer is never tier-gated.
See [/pricing](/pricing).


Published WorkerKit plans and prices apply to shared cloud.

## kit publisher

URL: https://workerkit.ai/glossary/kit-publisher
Also called: publisher, kit author, kit creator
Updated: 2026-10-08

**What is a kit publisher?** A kit publisher is whoever authored and published a worker kit to the directory, and whose page carries every kit they maintain.

Every [kit](/glossary/worker-kit) in the directory has a publisher, and every
publisher has a page listing what they maintain. The relationship is worth
understanding before you install anything, because it decides what you are
trusting and what you are not.

### What you are trusting, and what you are not

| | The publisher provides | They do NOT get |
| --- | --- | --- |
| The instruction for the job | Access to your accounts |
| The list of apps and the level each needs | Your data |
| Memories and defaults | Any ability to change your worker later |
| The schedule or trigger shape | Visibility into your runs |
| Recommended model | A key of any kind |

This is the load-bearing distinction. Taking a kit **creates a worker in your own
account**, with its own key and only the access you granted. The publisher wrote
a recipe; you cook it in your kitchen with your ingredients. A kit cannot reach
an account you have not connected.

So what you are trusting a publisher for is **judgement**, not access: that the
instruction is well written, that the access it requests is the minimum the job
needs, and that any performance claims are honest.

### Reading a kit's access request

The one thing genuinely worth scrutinising is the loadout, because that is where
a careless publisher shows up. Every kit states the apps it uses and the exact
access each needs, in plain words, before you take it.

Compare two real kits:

| Kit | Requests | Reasonable? |
| --- | --- | --- |
| [Engineering Pulse](/kit/engineering-pulse) | github | Yes, a digest reads one source |
| [Support Inbox Triager](/kit/support-inbox-triager) | email, tasks | Yes, drafting and filing both need write |
| [Company Knowledge Concierge](/kit/company-knowledge-concierge) | drive, sharePoint | Yes, it answers from those two |

The pattern to look for is a kit asking for an app its job sentence does not
mention. A triage kit requesting calendar access should prompt the question of
why, and the [app firewall](/glossary/app-firewall) lets you refuse it and see
whether the worker still does the job.

That check is yours to make and it takes about ten seconds, which is a better use
of scepticism than worrying about the publisher generally.

### Anyone can publish

Describe the job to the AI assistant you already use, connected to the
[WorkerKit MCP server](/build/mcp), and it writes the kit: it picks the apps and
the access each one gets, writes the instruction, validates and publishes. The
[API and the CLI](/build) take the same steps.

Publishing gives a kit its own page and a **permanent address for life**, which
has a specific consequence: an update lands on the same URL rather than a new
one, so every link to it keeps working and the page accumulates history rather
than being replaced. Each kit page shows when it was first published and when it
was last updated.

You can also keep a kit [private](/glossary/private-kit) instead, on every plan
including Free.

### Why grades carry provenance

A publisher declares things about their own kit, which is exactly the situation
where a reader should know the difference between a claim and a measurement.

Per-model grades are not currently displayed on kit pages. Publishers can describe
their testing in the kit description, distinguishing results **measured** from real
runs from expectations **declared** by the author. The former tells you what
happened; the latter tells you what the author expects.

Publishing that distinction rather than presenting one number is the mechanism
that makes an open publishing model workable. See
[model grade](/glossary/model-grade) for how to read them.

### The failure mode: a kit that stops being maintained

The realistic risk is not a malicious publisher. It is a **stale** one.

An app changes its behaviour, a model's characteristics shift, an assumption in
the instruction quietly stops holding. The kit still installs, still runs, and
starts producing slightly worse output. Nothing announces it, because there is no
error: this is the same plausible-failure shape that makes
[receipts](/glossary/run-receipt) matter throughout.

Two things help. A kit page shows its last-updated date, which is a signal worth
reading. And your worker is yours: you can edit its instruction after installing,
so a good-but-dated kit is a starting point rather than a dependency you are
stuck with.

### The reasonable objection

"Installing an instruction written by a stranger, which then acts in my inbox,
is a supply chain risk."

It is a fair frame, and the honest answer is that the mitigation is structural
rather than reputational. You are not running the publisher's code; you are
running your own worker under permissions you granted, inside an
[app firewall](/glossary/app-firewall) you control, with
[contact rules](/glossary/contact-rules) and
[redaction](/glossary/redaction) applied by the platform rather than by the kit.
The worst a badly written kit can do is bounded by access you approved and can
revoke, and every run is on the receipt.

That is a materially different risk profile from installing a package that
executes arbitrary code. It is not zero, and the ten seconds spent reading the
loadout is where you spend your scepticism.

### When to publish rather than keep it private

- **The job generalises.** If it only makes sense with your CRM field names, it
  is a private kit.
- **You want the address to be permanent and citable.** A published kit keeps
  its URL for life.
- **You are willing to maintain it.** A published kit with a two-year-old
  last-updated date is worse for your reputation than no kit.

### FAQ

#### Does a kit publisher get access to my accounts?

No. Taking a kit creates a worker in your own account with its own key and only the
access you granted. The publisher supplied the instruction and the access
requirements; they gain no access to your data, no visibility into your runs and
no ability to change your worker afterwards.

#### Can anyone publish a kit to the WorkerKit directory?

Yes. Build it [with your AI assistant, the API or the CLI](/build) and publish
it private first. Once a run proves it, make it public: a security scan checks
it, and it gets its own page and a permanent address for life. Kits can also
stay private on every plan including Free.

#### How do I know whether to trust a kit?

Read its loadout, which every kit states before you take it: the apps it uses and
the exact access each needs. A kit requesting an app its job does not mention is
the signal worth acting on. Also check the last-updated date and any testing
notes in the description, then run your own examples.

#### What happens when a publisher updates a kit I installed?

A kit keeps its address for life, so updates land on the same page. Your existing
worker is yours: it runs on the instruction you installed, and you can edit that
instruction yourself at any time.

#### Can I edit a kit's instruction after installing it?

Yes. Taking a kit creates your worker, and the instruction is then yours to
adjust. That is what makes a dated but well-built kit a useful starting point
rather than a dependency.

## managed runtime

URL: https://workerkit.ai/glossary/hosted-runtime
Also called: hosted runtime, hosted runs, managed agent runtime, serverless agent runtime
Updated: 2026-08-29

**What is a managed runtime for AI workers?** A managed runtime is the platform that operates an AI worker for you: it holds app access, runs it on schedule, enforces limits and records what happened.

An [AI worker](/glossary/ai-worker) that only runs while your laptop is open is
not unattended, it is a script with extra steps. The runtime is what removes
your laptop from the picture.

### Managed and hosted are two different claims

The two words get used interchangeably and they answer different questions.
**Hosted** says where a run executes: on WorkerKit's infrastructure rather than
on a machine you keep alive. **Managed** says who operates it: the access, the
schedule, the limits, the retries, the receipts and the failure behaviour are
the platform's responsibility rather than yours.

Hosting alone is the smaller half. A runtime that executes your agent and
leaves you to hold the credentials, enforce the permissions, catch the failures
and reconstruct what happened has moved a server off your desk and left the
work where it was. This page describes the larger claim, which is why the
canonical term is managed runtime and "hosted runtime" is the same thing said
from the infrastructure side.

### Managed vs running it yourself

| | WorkerKit managed runtime | Rolling your own |
| --- | --- | --- |
| Machine to keep alive | None | A server that never sleeps |
| Credential storage | Managed, per worker, scoped | Your own secret store |
| Scheduler | Wall clock, your time zone | Cron, plus DST bugs twice a year |
| Rate and cap enforcement | Built in, hard caps | You build it |
| Retries and recovery | Built in | You build it |
| Audit trail | A [receipt](/glossary/run-receipt) per run | Your log pipeline |
| Token billing | Provider list price, no markup | Direct to provider |

That table is the honest argument for a managed runtime. Nothing in it is
impossible to build; all of it is work you have to keep doing.

### What the runtime is actually responsible for

Executing a run sounds like one thing and is six:

- **Waking up** at the scheduled minute, or when a
  [webhook](/glossary/webhook-trigger) fires
- **Holding credentials** for connected apps, using only the access that worker
  was granted
- **Calling the model** the worker is deployed on, and metering what it costs
- **Enforcing limits**: the daily [tool call](/glossary/tool-call) cap, the rate
  shaping, the per-app access levels
- **Recovering** when an app is down or a run overruns
- **Writing the receipt**, so an unattended run is still inspectable

[Engineering Pulse](/kit/engineering-pulse) is the shape in practice: it reaches
GitHub on a morning schedule and delivers a digest of pull requests needing
review, stale branches and failing workflows. Nobody starts it, and nothing of
yours is running overnight to make it happen.

### Where WorkerKit runs today

WorkerKit hosts every run. There is no agent to install and no server to keep
alive.

Running a worker on **your own machine or infrastructure is not available yet
and is coming later.** Worth stating plainly, because self-hosting is a
reasonable requirement and today the honest answer is not yet.

### What a run costs

Two costs, kept deliberately separate:

| | What it buys | Price |
| --- | --- | --- |
| The plan | Capacity: workers, tool calls, schedule granularity, log history | $0 Free, $29 Pro, $299 Team flat for up to 10 users |
| Model tokens | The thinking | Provider list price, to the cent, no markup |

Published WorkerKit plans and prices apply to shared cloud.

The separation is the point. WorkerKit does not profit from your worker being
chatty, so nothing in the pricing pushes you toward a bigger model than the job
needs. Tokens come from the [wallet](/glossary/runtime-wallet) or
[your own provider key](/glossary/byok).

### Failing predictably

Two behaviours matter more than raw uptime once a fleet is unattended.

**Reserve before run.** A run reserves its token budget *before* it starts. A
balance that will not cover the reserve skips the run and says so on the
receipt. Top up and the next due run goes ahead. Nothing is half-completed.

**Hard caps.** At the daily tool-call cap a worker stops until the counter
resets, then picks its schedule back up. Nothing is deleted and no setting
changes. A runaway loop on a soft cap is an invoice; on a hard cap it is a
paused worker and a receipt explaining why.

### When a managed runtime is the wrong fit

The comparison table above is the case for it. The case against is narrower but
real, and worth stating plainly rather than leaving for you to discover.

| Requirement | Why hosting does not meet it |
| --- | --- |
| Data must not leave your infrastructure | Runs execute on WorkerKit's. Self-hosting is coming later, not available now |
| A system reachable only from inside your network | A hosted run cannot route to it without you exposing it |
| You already operate this | If you run infrastructure, hold secrets and carry a pager, you may fit it better yourself |
| Regulatory placement of processing | Where a run executes is sometimes the compliance question |

The first row is the one that decides most conversations, and there is no
workaround to offer: if data residency inside your own boundary is a hard
requirement today, this is not the right time to adopt.

The others are trade-offs rather than blocks. Building it yourself means building
the six responsibilities listed above, and the honest position is that a team
with existing infrastructure can do that well, while a team without one is
choosing to become an infrastructure team in order to run a worker.

### FAQ

#### What is the difference between a hosted runtime and a managed runtime?

Hosted describes where runs execute, on the platform's infrastructure instead
of a machine you keep alive. Managed describes who operates them: credentials,
permissions, schedules, limits, retries, receipts and failure behaviour. A
runtime can be hosted without being managed, in which case the operating work
is still yours. WorkerKit is both, and "managed runtime" is the term used
throughout this site.

#### Can I run a WorkerKit worker on my own server?

Not yet. WorkerKit hosts every run today, and running a worker on your own
machine or infrastructure is coming later. Everything else about a worker, the
instruction, the per-app permissions, the schedule, works the same way now.

#### Do I need to install anything to run a worker?

No. There is no agent, no daemon and no machine to keep alive. You connect the
accounts a [kit](/glossary/worker-kit) asks for and deploy it, and the runtime
takes it from there.

#### What happens if my wallet runs out mid-schedule?

Nothing runs half way. Each run reserves its budget before starting, so a
balance that will not cover it causes the run to be skipped with the reason on
the [receipt](/glossary/run-receipt). Top up and the next due run proceeds
normally.

#### Does WorkerKit mark up model tokens?

No. Tokens bill at the provider's list price to the cent. WorkerKit's own fees
are the plan price and the wallet top-up fee of 5.5% with a $1 minimum, both
stated in the open. See [/pricing](/pricing).

#### What happens when a worker hits its daily tool-call limit?

The worker stops until the counter resets, then resumes its schedule. Free allows 500
[tool calls](/glossary/tool-call) a day, Pro 5,000, and Team 50,000 pooled
across the account. Nothing is deleted and no configuration changes.

## MCP (Model Context Protocol)

URL: https://workerkit.ai/glossary/mcp
Also called: Model Context Protocol, MCP server, MCP gateway
Updated: 2026-07-24

**What is MCP (Model Context Protocol)?** MCP, the Model Context Protocol, is an open standard that lets an AI agent reach external tools and data through one common interface.

MCP is the plumbing. It answers exactly one question: how does a model reach
something that is not in its context window?

### MCP and a WorkerKit kit are not alternatives

| | MCP | [WorkerKit kit](/glossary/worker-kit) |
| --- | --- | --- |
| What it is | A protocol for reaching a system | A configured worker for one job |
| Decides what may be called | No | Yes, per app at Off, Read or Write |
| Decides who may be contacted | No | Yes, via [contact rules](/glossary/contact-rules) |
| Has a schedule | No | Yes |
| Leaves a receipt | No | Yes, every run |
| Uses the other | It is the wiring | A kit's apps are reached this way |

A kit **uses** MCP-style connections to do its job. Asking whether to pick MCP
or a kit is like asking whether to pick HTTP or a website.

### What an MCP server exposes

Three kinds of thing, and the distinction matters when designing one:

- **Tools**: actions the model can call, like `email_search` or
  `calendar_get_event`. Each invocation is one [tool call](/glossary/tool-call),
  which is also the unit WorkerKit meters capacity in.
- **Resources**: data the client can read into context, addressed by URI.
- **Prompts**: reusable templates a user can invoke.

### What MCP deliberately does not do

MCP connects. It does not decide, and it does not restrain.

The protocol has no opinion about which of a server's twelve tools a given agent
should be allowed to call, which contacts it may email, or whether a draft may be
sent rather than saved. Those are policy, and policy sits above the protocol.

That gap is the whole reason the safety layer exists. On WorkerKit it is three
things, and all three ship on **every plan including Free**:

| Layer | Question it answers |
| --- | --- |
| [App firewall](/glossary/app-firewall) | Which apps, and Off, Read or Write? |
| [Contact rules](/glossary/contact-rules) | Which people may it see and reach? |
| [Redaction](/glossary/redaction) | What must never leave, whoever it goes to? |

MCP also has no schedule. A server sits there until something calls it, which is
what a [worker schedule](/glossary/worker-schedule) or a
[webhook trigger](/glossary/webhook-trigger) provides.

### Both directions on WorkerKit

Worth keeping apart, because "MCP" gets used for both:

**Workers use connected apps.** [Company Knowledge Concierge](/kit/company-knowledge-concierge)
reaches Drive and SharePoint to answer questions with citations.
[Engineering Pulse](/kit/engineering-pulse) reaches GitHub for its morning
digest. You can also register a **custom MCP gateway** so a worker reaches a
system WorkerKit ships no integration for.

**A worker can be driven over MCP.** An external client can connect to a worker,
and the tools it sees reflect exactly that worker's permissions. Narrowing an
app to Read narrows what the external client can do too, because the restraint
lives with the worker rather than with the caller.

Connect what you already use on [the Connected apps page](/apps).

### When MCP is the wrong tool to reach for

The section above is about what MCP declines to do once you are using it. This is
about whether to use it at all, which is a different question and the one people
skip.

MCP solves an **N by M** problem: N clients needing M tools. Its value scales
with that product, and at the bottom of the range it is overhead:

| Clients | Tools | Bespoke integrations | With MCP |
| --- | --- | --- | --- |
| 1 | 1 | 1 | 1 server, plus protocol |
| 1 | 5 | 5 | 5 servers, plus protocol |
| 5 | 20 | 100 | 25 pieces |

The top row is the case to be honest about. If you control both ends and need one
tool for one client, a direct call is simpler, easier to debug, and has fewer
moving parts than standing up a server that speaks a protocol so that one caller
can use it.

Three other cases where something else fits better:

- **The vendor already ships a good SDK and you are one consumer.** Wrapping it
  in MCP adds a hop for a portability you are not using.
- **It is data, not an action.** Something a run could simply read once does not
  need a tool call per access.
- **The thing you actually lack is a schedule.** MCP will not start anything, so
  if the gap is that nothing runs, the answer is a
  [worker](/glossary/ai-worker) with a [schedule](/glossary/worker-schedule) or
  a [trigger](/glossary/webhook-trigger).

The last one is the common confusion. Teams reach for MCP when the missing piece
is autonomy rather than connectivity, and connect a system beautifully to
something that still waits to be asked.

### FAQ

#### Is MCP the same as a WorkerKit kit?

No. MCP is an open protocol for connecting an agent to tools and data. A
[kit](/glossary/worker-kit) is a ready-made [worker](/glossary/ai-worker) with an
instruction, per-app permissions, memories and a schedule, which runs unattended.
A kit uses connections; it is not itself a connection.

#### Do I need to set up MCP servers to use WorkerKit?

No. The apps a kit needs are connected by signing in to them on the Connected
apps page. Custom MCP gateways exist for the case where you want a worker to
reach a system WorkerKit does not already integrate.

#### Does MCP control what an AI agent is allowed to do?

No, and this is the most common misunderstanding. MCP exposes tools; it has no
permission model for deciding which agent may call which tool, or which contacts
it may reach. WorkerKit adds that layer on top with per-app access levels,
contact rules and redaction.

#### How does MCP relate to skills and plugins?

They stack. MCP is how an agent reaches a system, a
[skill](/glossary/agent-skill) is how it should use it, a
[plugin](/glossary/ai-plugin) is how both get installed into a client, and a kit
is a finished job done unattended.

#### Are MCP tool calls counted against my plan?

Yes. Every action a worker takes in a connected app is one
[tool call](/glossary/tool-call), and plans cap them daily: 500 a day on Free,
5,000 on Pro, 50,000 pooled on Team. At the cap a worker pauses until the
counter resets, then picks its schedule back up.

## model agnostic

URL: https://workerkit.ai/glossary/model-agnostic
Also called: model independent, multi-model, model portable
Updated: 2026-07-23

**What does model agnostic mean?** Model agnostic means the same AI worker runs on any supported model, so you pick at deploy time and can switch later without rewriting the worker.

A [kit](/glossary/worker-kit) brings the instructions, not the model. That one
sentence is the whole idea, and its consequences are worth spelling out because
most of them are commercial rather than technical.

### Tied to a model vs model agnostic

| | Tied to one provider | Model agnostic |
| --- | --- | --- |
| Switching model | A rewrite | A dropdown |
| Provider outage | Your worker is down | Redeploy on another model |
| A cheaper model ships | Migration project | Change and measure |
| Price rise | You absorb it | You move |
| Comparing two models | Two implementations | One run, sent to each |

### What it means in practice

Claude, ChatGPT, Gemini and Grok all drive the same kits. You choose the model
when you deploy an [AI worker](/glossary/ai-worker), switch whenever you like,
and can send a **single run** to a different model to compare the two on the same
job with the same inputs.

That last one is the useful trick. Model comparisons in the abstract are
marketing. A comparison on *your* job, with *your* instruction and *your* data,
is evidence. [Meeting Prep Assistant](/kit/meeting-prep-assistant) reaching
calendar, email, meeting notes and CRM is a genuinely hard test: four sources,
one synthesised document. Run it twice on two models and read both prep sheets.
You will know within a morning.

### Why it matters more than it sounds

Model choice is the fastest-moving variable in this category. A model that is
best for a job in March may be second by June and cheaper by September.

If a worker is welded to one provider, every one of those changes is a rewrite.
If it is not, they are a dropdown. Being model agnostic is a bet that the
frontier keeps moving, which so far has been safe.

It also removes a quiet dependency. A worker tied to one provider inherits that
provider's outages, rate limits and pricing decisions with no recourse. When a
fleet runs unattended, "the provider is having an incident" turns into "nothing
ran this morning and nobody noticed", which is a much worse sentence.

### Per-model grades, and their provenance

Model agnostic does not mean every model is equally good at every job. Some jobs
need careful long-context reasoning; some need speed and low cost.

Per-model grades are not currently displayed on kit pages. Compare models on
your own examples. When a publisher describes performance, distinguish between
measured results and declared expectations:

| Provenance | What it means | How to weigh it |
| --- | --- | --- |
| Measured | Taken from real runs of this kit | Evidence |
| Declared | Stated by the kit's publisher | A claim, useful until runs measure it |

That mark is not decoration. A measured grade and a declared one deserve
different confidence before you put a worker on a job that touches customers.
You can also filter [the directory](/kits) by model to see only the kits that fit
the one you already use.

### The pricing consequence

Model tokens bill at the **provider list price with no markup**, from the
[wallet](/glossary/runtime-wallet) or [your own key](/glossary/byok).

This is what makes model agnosticism real rather than nominal. If a platform
took a cut of tokens, it would earn more when you chose the bigger model, and
"switch any time" would sit in tension with its own revenue. With no markup
there is nothing to steer: switching to a cheaper model saves you money and
costs WorkerKit nothing.

Watch for this when comparing platforms. A vendor that marks up tokens and also
offers model choice has an interest in which one you pick, whatever the docs say.

### The reasonable objection

"Model agnostic means lowest-common-denominator. You cannot use any provider's
best features."

There is something in it. A kit written to run anywhere cannot depend on one
provider's proprietary extension, and a prompt tuned for one model is rarely
optimal on another.

The answer is that the constraint sits at the right level for this kind of work.
A kit's value is in the instruction, the access rules and the wiring, none of
which are provider-specific. The provider-specific tuning that does matter is
mostly about phrasing. Test the same inputs on different models to find where
each one is weaker; model choice does not promise identical performance.

### When to pin a model instead

Being able to switch is not a reason to switch constantly.

- **A job you have measured.** If a model has proven itself on a worker touching
  customers, leave it. Novelty is not a reason to re-qualify.
- **Compliance constraints.** If a provider is approved and others are not, that
  decision is not yours to optimise.
- **Cost stability.** Switching to a cheaper model mid-quarter changes your
  token spend profile, which someone may be forecasting.

The value is in being *able* to move, cheaply, when there is a reason. That is
different from moving often.

### FAQ

#### Which AI models can run WorkerKit kits?

Claude, ChatGPT, Gemini and Grok all drive the same kits, because a kit brings
the instructions rather than the model. You pick the model when you deploy a
worker and can change it at any time.

#### Can I switch a worker to a different model later?

Yes, at any time, with no rewrite. You can also send a single run to a different
model to compare the two on the same job with the same inputs, which is a much
better test than a benchmark on somebody else's task.

#### What does a per-model grade on a kit page mean?

Per-model grades are not currently displayed on kit pages. The term describes a
score for one kit on one model. Weigh a measured result from real runs as evidence
and a declared score from a publisher as a claim.

#### Does WorkerKit charge more for a more expensive model?

No. Model tokens bill at the provider's list price to the cent with no markup,
whether paid from the [wallet](/glossary/runtime-wallet) or
[your own key](/glossary/byok). WorkerKit earns the plan price and the wallet
top-up fee, so nothing in the pricing steers your model choice. See
[/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

#### Can I use my own provider account?

Yes. Add an Anthropic, OpenAI, Google or xAI key and those tokens bill straight
to your provider account, with the first 1M tokens each month carrying no
platform fee. See [BYOK](/glossary/byok).

## model grade

URL: https://workerkit.ai/glossary/model-grade
Also called: per-model grade, kit grade, model score
Updated: 2026-08-11

**What is a per-model grade?** A per-model grade scores how well one kit performs on one AI model, marked with whether it was measured from real runs or declared by the publisher.

Because a [kit](/glossary/worker-kit) brings the instructions rather than the
model, the same kit runs on Claude, ChatGPT, Gemini and Grok. That immediately
raises the question a grade exists to answer: **does it run equally well on all
of them?**

Usually not, and the honest thing is to say so per model rather than to claim
uniform performance.

Per-model grades are not currently displayed on WorkerKit kit pages. This page
explains the concept; use your own test runs and receipts to compare models today.

### Measured or declared

A useful grade states its provenance, and this is the part that matters most:

| | Measured | Declared |
| --- | --- | --- |
| Where it comes from | Real runs of this kit | The publisher's assessment |
| What it tells you | What happened | What the author expects |
| Weight it deserves | Evidence | A claim worth checking |
| Evidence needed | Recorded runs and an evaluation rubric | An explicitly stated publisher assessment |

Both are useful and they are not equivalent. Publishing the distinction rather
than one blended number is what makes an open publishing model workable: a new
kit can say what its author believes without that being dressed up as data.

The practical rule: **a declared grade is a starting hypothesis, a measured grade
is a result.** Weigh them differently before putting a worker on a job that
reaches customers.

### Why a kit performs differently across models

The differences that show up in unattended work are narrower than general
benchmarks suggest, and mostly about consistency rather than raw capability:

- **Instruction adherence over long context.** Does the rule still hold on run
  four hundred, on an oddly shaped input?
- **Restraint.** Does it stop when information is missing, or produce a plausible
  answer to fill the gap?
- **Format stability.** A worker whose output another system reads needs the
  same shape every time.
- **Synthesis across sources.** Combining four apps is a different skill from
  extracting from one.

That last one is why grades diverge most on multi-app kits.
[Meeting Prep Assistant](/kit/meeting-prep-assistant) reaches calendar, email,
meeting notes and CRM and has to produce one coherent document from all four.
[Engineering Pulse](/kit/engineering-pulse) reads GitHub and summarises it.
The first discriminates between models far more than the second, which is worth
knowing when you read a grade that looks surprisingly flat.

### How to use a grade

A grade narrows the field. It does not make the decision.

| Situation | What to do |
| --- | --- |
| Grades are close | Pick on cost or on the model you already use |
| One is clearly ahead, measured | Start there |
| One is clearly ahead, declared | Start there, then verify on your own data |
| The job touches customers | Run your own comparison regardless |

The verification step is cheap: send the **same run** to two models and read both
outputs. Same instruction, same inputs, same day. Two runs of a four-app worker
cost roughly 40 [tool calls](/glossary/tool-call), about 8% of Free's daily 500.

You can use the Language model filter in [the directory](/kits) to narrow its
compatibility listings. That filter is not a measured performance grade; test
the job with your own inputs.

### The failure mode: treating a grade as a guarantee

A grade is an aggregate over runs that were not your runs, on data that was not
your data.

A kit graded highly for meeting prep was graded against whatever meetings the
measurement covered. If your team writes notes in a house shorthand, or your CRM
uses custom fields, the thing that will actually go wrong is specific to you and
appears in no grade.

That is not a criticism of grades; it is the limit of what any aggregate can
carry. Grades are for narrowing from four models to one or two. Your own
comparison is for choosing between those.

### The reasonable objection

"Publishers grade their own kits. Why would anyone declare a low grade?"

That is why a useful grading scheme must distinguish a publisher's assessment
from results backed by recorded runs and an evaluation rubric. A declared grade
is a claim to check; a measured grade is evidence with a defined scope.

WorkerKit does not currently display either kind on kit pages. Compare the
models on your own inputs and inspect the [run receipts](/glossary/run-receipt)
rather than looking for a grade badge or an adjacent measured score.

### When a grade should not drive the decision

- **The job is trivial.** Classifying into four buckets rarely discriminates
  between frontier models; pick on cost.
- **Compliance already decided.** If one provider is approved, a grade is
  information, not a choice.
- **You have your own measurements.** Yours beat aggregates, always.
- **Output feeds another system.** Format stability may matter more than the
  quality the grade reflects.

### FAQ

#### What does a per-model grade on a kit page mean?

Per-model grades are not currently displayed on kit pages. The term describes a
score for one kit on one model, with its source identified as measured from real
runs or declared by the publisher. Such a score can narrow a choice; it cannot
replace testing on your own data.

#### What is the difference between a measured and a declared grade?

A measured grade comes from recorded runs of that kit against an evaluation
rubric. A declared grade is the publisher's own assessment. The distinction
helps a reader weigh evidence separately from a claim; WorkerKit does not
currently display these grades on kit pages.

#### Why does the same kit perform differently on different models?

Mostly through consistency rather than raw capability: instruction adherence over
long context, restraint when information is missing, format stability, and the
ability to synthesise across several apps. Multi-app kits discriminate between
models much more than single-source ones.

#### Should I trust a declared grade?

Treat it as a starting hypothesis rather than a result. It tells you what the
author expects, which is genuinely useful for narrowing the field, and then a
comparison on your own data is what settles it, especially if the worker reaches
customers.

#### How do I test a model on my own job?

Send the same run to a different model and read both outputs, so the instruction,
the inputs and the day are identical and the model is the only variable. It costs
roughly one extra run, and model tokens bill at provider list price with no
markup. See [/pricing](/pricing).


Published WorkerKit plans and prices apply to shared cloud.

## open app slot

URL: https://workerkit.ai/glossary/open-app-slot
Also called: app slot, capability slot, open slot
Updated: 2026-08-10

**What is an open app slot in a kit?** An open app slot is a kit naming the app surface a job needs, such as email, and letting you choose which provider fills it when you install.

Some kits pin a vendor. Others name the **surface** and let you supply the
vendor. That second shape is an open app slot, and it is one of the more
consequential decisions a [kit publisher](/glossary/kit-publisher) makes.

### Pinned app vs open slot

| | Pinned app | Open slot |
| --- | --- | --- |
| The kit says | "This uses Gmail" | "This needs email" |
| You choose | Nothing | Which provider fills it |
| Works if you use Outlook | No | Yes |
| Instruction can assume | That vendor's specifics | Only what the surface guarantees |
| Best for | Jobs genuinely tied to one product | Jobs about the work, not the tool |

### What it looks like in the catalog

Three real kits, all with slots left open:

| Kit | Pinned | Open slot | Effect |
| --- | --- | --- | --- |
| [School Email to Calendar](/kit/school-email-to-calendar) | none | email, calendar | Works on Google or Microsoft |
| [Subscription Cleaner](/kit/subscription-cleaner) | none | email | Any supported mail provider |
| [Influencer Client Email to Slack Monitor](/kit/influencer-client-email-to-slack-monitor) | slack | email | Slack is the point; the mailbox is not |

That last row is the pattern worth copying. Slack is **named** because posting to
Slack is what the job does. Email is a **slot** because the job is "watch a
mailbox" and it genuinely does not matter whose.

Compare [Engineering Pulse](/kit/engineering-pulse), which pins GitHub and
should: a kit that reads pull requests, stale branches and failing workflows is
about GitHub specifically, and pretending otherwise would produce an instruction
too vague to be useful.

### Why a slot roughly doubles a kit's audience

The arithmetic is blunt. A kit pinned to Gmail is unusable by anyone on Outlook,
which in most markets is not a small fraction. Leaving the slot open costs the
publisher nothing at authoring time and removes the whole exclusion.

It also survives your own changes. A team that migrates from Google Workspace to
Microsoft 365 keeps every slot-shaped kit working and loses every pinned one.

The cost is real but narrow: the instruction can only assume what the **surface**
guarantees, not what one vendor offers. A kit relying on a Gmail-specific label
behaviour cannot be slot-shaped without losing the thing it relies on.

### How a slot interacts with access

A slot decides **which product** fills a surface. It does not decide **what the
worker may do there**, which is still granted per app and per level through the
[app firewall](/glossary/app-firewall).

Filling a slot with Gmail and granting Read is a different thing from filling it
with Gmail and granting Write, and the kit states which level the job needs
before you take it. Slots widen compatibility; they do not widen permissions.

You fill a slot from your [connected apps](/glossary/connected-app), so the
provider has to be connected first. A slot cannot conjure access to an account
you never signed in to.

### The failure mode: a slot that should have been pinned

Slots are not free of judgement, and the way they go wrong is subtle.

A publisher, wanting maximum reach, leaves a slot open for a surface the
instruction actually depends on the specifics of. The kit installs happily on
either provider and produces good output on the one it was built against and
mediocre output on the other. Nothing errors, because the surface really does
support both; the instruction was simply tuned for one.

The signal is a [per-model style](/glossary/model-grade) gap that is not about
models at all: two installers reporting different quality, correlating with
provider rather than anything else. The fix is either to pin, or to write the
instruction against what the surface guarantees rather than what one product
happens to do.

### The reasonable objection

"If a slot means the instruction can only assume the lowest common denominator,
slot-shaped kits are worse kits."

Sometimes, and it is the right trade-off to weigh rather than assume. The
question is whether the job is about the **work** or about the **tool**.

"Scan school emails and create calendar events organised by child name" is about
the work. Nothing in it needs Gmail rather than Outlook, and pinning would
exclude half the parents who want it for no gain.

"Read pull requests, stale branches and failing workflows" is about the tool, and
a version abstracted over "code hosts" would be worse at all of them. Pin it.

Most jobs about correspondence, scheduling and tasks are the first kind. Most
jobs about a specific product's internals are the second.

### When to pin instead

- **The instruction depends on vendor specifics.** Labels, custom fields, a
  particular API behaviour.
- **The job is named after the product.** A GitHub digest is a GitHub digest.
- **Only one supported provider exists** for that surface anyway.
- **The output shape is vendor-determined**, and abstracting it would make the
  instruction vague.

### FAQ

#### What is an open app slot in a WorkerKit kit?

It is a kit naming the app surface a job needs, such as email or calendar,
without pinning a specific provider. You choose which of your
[connected apps](/glossary/connected-app) fills it when you install, so the same
kit works on Google or Microsoft.

#### Does an open slot mean the kit gets more access?

No. A slot decides which product fills a surface; access is still granted per app
and per level, Off, Read or Write, through the
[app firewall](/glossary/app-firewall). The kit states the level it needs before
you take it.

#### Can I fill a slot with a provider I have not connected?

No. Slots are filled from accounts you have already connected, so the provider
has to be signed in first on [the Connected apps page](/apps).

#### Should my kit use slots or pin a provider?

Ask whether the job is about the work or about the tool. Correspondence,
scheduling and task jobs are usually slot-shaped and reach roughly twice the
audience. Jobs about one product's internals, like a GitHub digest, should pin,
because abstracting them makes the instruction too vague to be good.

#### What happens to a slot-shaped kit if I change email providers?

It keeps working: you fill the slot with the new provider. Kits pinned to the old
vendor would need replacing, which is one of the quieter arguments for slots when
you author a kit.

## private kit

URL: https://workerkit.ai/glossary/private-kit
Also called: unlisted kit, internal kit, team kit
Updated: 2026-10-08

**What is a private AI worker kit?** A private kit is a worker kit kept out of the public directory, available to you or your team rather than published for anyone to install.

Not every [kit](/glossary/worker-kit) should be public. A private kit is the same
object, built the same way [with your AI assistant, the API or the CLI](/build),
simply not listed in the directory.

Private kits are included on **every plan, Free included.** Keeping work to
yourself is not a paid feature.

### Public and private, compared

| | Published kit | Private kit |
| --- | --- | --- |
| Listed in [the directory](/kits) | Yes | No |
| Who can install it | Anyone | You, or your team on Team plans |
| Has a permanent public page | Yes | No |
| Carries your name as [publisher](/glossary/kit-publisher) | Yes | Not publicly |
| Maintenance expectation | Real, others depend on it | Yours alone |
| Good for | Jobs that generalise | Jobs shaped by your specifics |

### When private is the right call

The test is whether the kit makes sense to somebody who does not work at your
company.

- **It encodes your specifics.** Your CRM's custom field names, your internal
  escalation ladder, the shorthand your team writes meeting notes in. A stranger
  installing it gets something that references things they do not have.
- **The instruction reveals something.** How you qualify leads, what your renewal
  playbook is, which accounts get special handling. That is strategy written
  down, and publishing it publishes the strategy.
- **You do not want the maintenance.** A published kit that others install is a
  commitment. A private one can be half-finished and improved on Tuesday.
- **It is still an experiment.** Most kits should start private and be published
  only once they have run enough to be worth someone else's trust.

That last one is the common path rather than the exception. Publishing a kit
nobody has run is how a directory fills with things that do not work.

The line is easiest to see against a published kit.
[Support Inbox Triager](/kit/support-inbox-triager) reaches email and tasks to
classify, prioritise, draft and file: every support team on earth has that job,
and the instruction needs none of your specifics to work. Now imagine the same
kit rewritten to route by your five internal team names, apply your bespoke SLA
tiers, and use your ticket taxonomy. That version is strictly more useful to you
and useless to anyone else, which is exactly the shape that should stay private.

### Team sharing

Team plans can share private kits **across the team without publishing them**,
which is the case the tier exists for: an internal kit that six colleagues should
be able to install, and nobody outside should see.

That sits alongside Team's other shared machinery: one pooled
[wallet](/glossary/runtime-wallet) with spend controls, central worker admin, and
member on and offboarding. The pattern is the same throughout, which is that
Team treats the account as the unit rather than the seat.

On Free and Pro a private kit is yours. On Team it can be the team's.

### What private does not mean

Worth being precise, because "private" carries more weight than it should here.

Private describes **listing**, not isolation. It is not a security boundary
around your data, because that boundary already exists elsewhere and does not
depend on whether a kit is listed:

| Concern | What actually protects it |
| --- | --- |
| Which apps a worker can reach | [App firewall](/glossary/app-firewall), per app at Off, Read or Write |
| Which people it can contact | [Contact rules](/glossary/contact-rules) |
| What must never leave | [Redaction](/glossary/redaction) |
| Whether others can install this kit | Private listing |

A published kit does not leak your data either, because taking a kit creates a
worker in the installer's own account with their own key and their own
connections. Publishing shares the *recipe*, never the *kitchen*. So the reason
to keep a kit private is that the recipe itself is yours, not that publishing
would expose anything you have.

### The failure mode: the fleet nobody can explain

Private kits accumulate quietly, and the thing that goes wrong is
organisational rather than technical.

Six months in, a team has eleven private kits, four of which do nearly the same
job, two of which were built by someone who has left, and one of which everyone
is slightly afraid to switch off because nobody remembers what depends on it.
Nothing failed. There is simply no directory page, no description written for a
stranger, and no reason anyone ever had to explain the thing.

The discipline that prevents it is cheap: write the job sentence as if a stranger
were reading it, even when nobody will. If you cannot state the job in one
sentence, the kit is probably two kits.

### The reasonable objection

"If private kits are free on every plan, what stops everyone keeping everything
private and the directory staying empty?"

Nothing, and that is the correct arrangement. A directory filled by obligation is
a directory of kits nobody wanted to publish, which is worse than a smaller one.

The incentive to publish is real but narrow: a permanent public page, an address
that keeps working, and the reputation that accrues to a
[publisher](/glossary/kit-publisher) whose kits get installed and measured. That
is worth something to people building kits that generalise, and worth nothing to
someone automating their own CRM's custom fields. Both behaviours are fine.

### When to publish instead

- **The job generalises.** Strip the specifics and it still does something
  useful.
- **You will maintain it.** A stale published kit is worse for your name than no
  kit.
- **You want the permanent address.** A published kit keeps its URL for life, so
  updates land on the same page.

### FAQ

#### Are private kits available on the free plan?

Yes. Private kits are included on every plan, Free included. Keeping a kit
unlisted is not a paid feature; what Team adds is sharing private kits across the
team without publishing them.

#### Can my team share a private kit?

On Team plans, yes: private kits can be shared across the team without being
published to the directory. On Free and Pro a private kit belongs to your own
account.

#### Is a private kit more secure than a published one?

No, and the distinction is worth being clear about. Private describes listing,
not isolation. What protects your data is the
[app firewall](/glossary/app-firewall),
[contact rules](/glossary/contact-rules) and
[redaction](/glossary/redaction), and those apply identically either way.
Publishing shares the recipe, never access to your accounts.

#### Can I publish a private kit later?

Yes, and starting private is the recommended path: build it, run it enough to
know it works, then publish once it is worth someone else's trust. Publishing a
kit nobody has run is how a directory fills with things that do not work.

#### Should I keep a kit private or publish it?

Keep it private if it encodes your CRM field names, your internal process or
anything you would not want stated publicly, or if you do not want the
maintenance. Publish it if the job generalises, you will keep it current, and you
want the permanent public page.

## redaction

URL: https://workerkit.ai/glossary/redaction
Also called: PII redaction, masking, data minimisation
Updated: 2026-07-22

**What is redaction in AI workers?** Redaction strips or masks sensitive values out of what an AI worker sends to a model or writes into an app, so the information never leaves at all.

Redaction is the last of the three safety layers, and the only one that acts on
**content** rather than on access.

### Why access control cannot cover this

A worker can be correctly scoped and still handle text you would rather not send
anywhere.

[Invoice Follow-up Assistant](/kit/invoice-follow-up-assistant) reaches email and
Drive to chase overdue invoices from your AR sheet and inbox. Its access is
exactly right: it needs those two apps to do the job. And the material it handles
is bank details, account numbers, and occasionally a card number somebody pasted
into a thread years ago.

No access rule helps here. The worker is supposed to read that thread; that is
the job. What has to change is what survives the trip.

| Concern | The layer that answers it |
| --- | --- |
| Should it touch Drive at all? | [App firewall](/glossary/app-firewall) |
| May it email this person? | [Contact rules](/glossary/contact-rules) |
| Should this account number leave? | Redaction |

### Why it beats asking the model nicely

The obvious alternative is an instruction: "never include account numbers in your
reply". This fails, and the reason is worth internalising rather than
memorising.

| | An instruction | Redaction |
| --- | --- | --- |
| Evaluated by | The model, against everything else in context | The platform, before the model sees it |
| Competing pressure | Being helpful, complete, responsive | None |
| If the input is adversarial | Can be redirected | Unaffected |
| Failure mode | Silent, occasional, plausible-looking | The value simply is not there |
| Auditable | Only by reading every output | By what was sent |

An instruction holds most of the time. **Most of the time is not a control.** A
policy that fails one run in two hundred, unattended, across a fleet, is a policy
that will fail this month and you will hear about it from somebody else.

Redaction is applied outside the model's reach. It is not something the worker
can be argued, confused or injected past, because the worker is not the one
enforcing it.

That distinction, **policy the model cannot negotiate with**, is what separates a
safety layer from a prompt convention. It is the same argument that puts contact
filtering before the model rather than inside its instructions.

### Where it applies

Both directions matter, and people usually think of only one:

- **Outbound to the model.** What a run sends to Claude, ChatGPT, Gemini or Grok
  for reasoning. This is the direction most people mean, and it is the one that
  determines what leaves your infrastructure.
- **Outbound to apps.** What the worker writes back into a draft, a ticket or a
  CRM note. A summary that helpfully quotes a card number has moved it somewhere
  new, even though the model was never the leak.

### The failure mode it is designed around

The realistic leak is not exfiltration. It is **a summary**.

A worker reads a support thread containing a customer's card number, and writes a
ticket that faithfully summarises the conversation, including the number. Nobody
attacked anything. The model did exactly what it was asked. The number is now in
a ticketing system with a different access model, a different retention policy
and a different set of people who can read it.

That is the everyday version, and it is why redaction acts on content in both
directions rather than only on the request to the model.

### The reasonable objection

"If you strip values before the model sees them, the model loses context and
the output gets worse."

Sometimes, and the honest answer is that this is a real trade rather than a free
win. A worker that cannot see an amount cannot reason about whether it is large.

Two things make it manageable. Redaction is about **identifiers**, not meaning:
masking a card number rarely changes what a support reply should say, where
masking the invoice total might. And it is configured per rule rather than as a
blanket setting, so you strip what should never leave and keep what the job needs
to work.

If a job genuinely requires reasoning over the sensitive value itself, redaction
is the wrong tool and the right conversation is whether that job should be
unattended at all.

### When it is not the answer

- **The worry is which app.** Set the app to Off. Redaction is for content that
  legitimately passes through.
- **The worry is who receives it.** That is
  [contact rules](/glossary/contact-rules), and it applies regardless of what the
  message contains.
- **The data should not be in the source system either.** Redaction stops it
  spreading; it does not clean up where it already lives.

### On every plan

Redaction ships on **every plan, Free included**, alongside the app firewall,
contact rules, and one key with its own scope list per worker. The complete
safety layer is never tier-gated.

The reasoning is the same one that keeps the [receipt](/glossary/run-receipt) on
every plan: the controls that make autonomy safe cannot be the paid tier, or the
free product is the dangerous one by design. What plans change is capacity and
retention, not safety. See [/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

### FAQ

#### What is redaction in the context of AI agents?

It is a platform layer that strips or masks sensitive values out of what a worker
sends to a model and what it writes back into your apps, so the value never
leaves rather than being trusted not to be repeated.

#### Why not just instruct the model not to reveal sensitive data?

Because an instruction is evaluated by the model against every other pressure in
its context, including a strong pull toward being helpful and complete. It holds
most of the time, and most of the time is not a control. Redaction is enforced
outside the model, so there is nothing to negotiate with.

#### Does redaction protect against prompt injection?

For the values it covers, yes, in the sense that matters: text engineered to make
a worker reveal a redacted value cannot succeed, because the value was never in
the model's context to reveal. It is not a complete answer to injection, but it
removes the class of attack that targets specific sensitive fields.

#### Does redacting data make the worker less useful?

It can, which is why it is configured per rule rather than as a blanket switch.
Masking identifiers such as account or card numbers rarely changes what a reply
should say. If a job genuinely needs to reason over the sensitive value, that is
a sign the job may not be a good unattended candidate.

#### Is redaction included on the free plan?

Yes. It ships on every plan including Free as part of the complete safety layer,
alongside the [app firewall](/glossary/app-firewall) and
[contact rules](/glossary/contact-rules), and is never tier-gated.

## run receipt

URL: https://workerkit.ai/glossary/run-receipt
Also called: run log, activity receipt, agent audit trail
Updated: 2026-07-21

**What is an AI worker run receipt?** A run receipt is the record an AI worker leaves after every run showing what it read, what it did, what it cost and what it skipped.

Unattended does not mean unwatched. A [worker](/glossary/ai-worker) you cannot
inspect is one you will eventually switch off, because the first time it does
something surprising you have no way to find out why.

### What a receipt carries, and why each part matters

| Recorded | Answers |
| --- | --- |
| What it read, and from which app | "Where did it get that from?" |
| Each [tool call](/glossary/tool-call) it made | "What did it actually touch?" |
| Model tokens consumed | "What did this run cost?" |
| What it skipped, and why | "Why is there no output today?" |
| The run context and webhook payload | "What was it sent?" |

Every run writes one, whether it came from a
[schedule](/glossary/worker-schedule), a
[webhook trigger](/glossary/webhook-trigger), or an on-demand run.

### Skips are recorded, not swallowed

The skip cases deserve their own paragraph, because they are where unattended
systems normally go quiet.

If a balance will not cover a run's reserve, the run does not half-happen: it is
skipped and the receipt says so. If the daily tool-call cap is reached, the
worker stops and picks its schedule back up after the reset, and that is on the
receipt too. Same for a model that was unavailable.

A silent skip is the worst outcome available. It looks exactly like success
until somebody notices a week of missing work.

### Why this is a safety feature, not a logging feature

Consider [Invoice Follow-up Assistant](/kit/invoice-follow-up-assistant), which
reaches email and Drive to chase overdue invoices with escalating reminder
drafts. It touches money and customers.

The honest way to manage that risk is not to promise the worker will never be
wrong. It is three things:

1. Grant narrow access in the first place, per app at Off, Read or Write
   ([app firewall](/glossary/app-firewall)).
2. Keep the ability to revoke without stopping the worker.
3. Be able to reconstruct, afterwards, exactly what it did.

The receipt is the third. It turns "the worker sent something odd" from a
mystery into a diagnosis, which is why it exists on every plan rather than as an
audit upsell.

[Support Inbox Triager](/kit/support-inbox-triager) makes the same case at
volume: it classifies, prioritises, drafts and files all day, and the receipt is
how you check its judgement without reading every ticket yourself.

### What a receipt cannot tell you

Naming the limits is what makes the rest worth trusting.

A receipt records **what happened**, not **whether it was right**. It will show
you that a support worker classified eleven threads and drafted four replies. It
cannot tell you that two of those classifications were wrong, because that
judgement is the thing you are checking. In the first weeks of a worker's life
the receipt is a reading list, not a verdict.

It is also a record rather than an alarm. Nothing in a receipt pages you at 3am;
it is there when you go looking. For a worker whose failure would be expensive
within the hour, the receipt is the wrong instrument on its own, and the right
design is a job whose mistakes are recoverable rather than urgent.

### How long receipts are kept

| Plan | Log history |
| --- | --- |
| Free | 1 day |
| Pro | 30 days |
| Team | 365 days |
| Enterprise | 365 days |

Free's single day is enough to debug a worker you are actively setting up, which
is what it is for. Thirty days on Pro covers "what happened last month", which is
the question that actually gets asked.

### FAQ

#### Does every AI worker run leave a receipt?

Yes. Scheduled, triggered and on-demand runs all write one, on every plan
including Free. The difference between plans is how long the history is kept,
not whether it is recorded.

#### How do I find out why a worker did not run?

The receipt states the reason. The common ones are a wallet balance that would
not cover the run's reserve, the daily [tool call](/glossary/tool-call) cap being
reached, or a model being unavailable. In each case the run is skipped rather
than half-completed, and nothing is deleted.

#### Can I see what a worker read, not just what it changed?

Yes. Reads are recorded alongside writes, which is what makes it possible to
answer "where did it get that from" rather than only "what did it send".

#### Is the audit trail a paid feature?

No. Receipts ship on every plan including Free, alongside the rest of the safety
layer ([app firewall](/glossary/app-firewall),
[contact rules](/glossary/contact-rules),
[redaction](/glossary/redaction)). Only the retention window varies by plan.

#### Do receipts show what a run cost?

Yes, the model tokens the run consumed. Those bill at the provider list price
with no markup, from the [wallet](/glossary/runtime-wallet) or
[your own key](/glossary/byok). See [/pricing](/pricing).


Published WorkerKit plans and prices apply to shared cloud.

## runtime wallet

URL: https://workerkit.ai/glossary/runtime-wallet
Also called: prepaid runtime credit, wallet, token balance
Updated: 2026-07-20

**What is a runtime wallet for AI workers?** A runtime wallet is a prepaid balance that hosted AI worker runs draw on to pay for model tokens, kept separate from the subscription price.

Two different things get called "the cost of an AI worker": the software, and
the model tokens it burns. WorkerKit prices them separately, and the wallet is
where the second one lives.

### Wallet vs plan: two meters, one bill each

| | The plan | The wallet |
| --- | --- | --- |
| Pays for | Capacity: workers, [tool calls](/glossary/tool-call), schedules, log history | Model tokens |
| Charged | Monthly or yearly, fixed | When you choose to load it |
| Price | $0 Free, $29 Pro, $299 Team flat for up to 10 users | Provider list price, no markup |
| Runs out how | You hit a cap and the worker pauses | A run is skipped before it starts |
| WorkerKit's fee | The plan price | 5.5% on loading, $1 minimum |

Published WorkerKit plans and prices apply to shared cloud.

Keeping them apart is what lets the plan be a predictable line item while usage
stays honest. A month where your workers did little costs the plan price and
almost no tokens.

### What loading actually costs

Loading the wallet costs **5.5%, with a $1 minimum**, charged on top. The
credited balance is exactly what you loaded, so nothing is skimmed off the
balance itself.

Percentages plus minimums confuse everybody, so worked out:

| You load | You are charged | Credited | Effective fee |
| --- | --- | --- | --- |
| $5 (the minimum) | $6.00 | $5.00 | 20% |
| $20 | $21.10 | $20.00 | 5.5% |
| $50 | $52.75 | $50.00 | 5.5% |
| $500 | $527.50 | $500.00 | 5.5% |

The $1 minimum dominates small loads and the percentage takes over above about
$18. The practical read: **topping up in $5 increments is the expensive way to
use the wallet.** If you are going to spend $50 over a quarter, load it once.

### Reserve before run, and why it is the right failure

A run reserves its token budget **before** it starts, rather than discovering
mid-flight that the balance ran out.

A balance that will not cover the reserve **skips** the run and says so on the
[receipt](/glossary/run-receipt). Top up, and the next due run goes ahead.
Nothing is deleted, no setting changes, and no worker is left half-finished.

That last part is the whole argument. Consider
[Support Inbox Triager](/kit/support-inbox-triager), which reaches email and
tasks to classify, prioritise, draft replies and file tickets. A run that died
partway through would leave some tickets filed, some drafts written and no
record of where it stopped. Somebody would have to reconstruct it by hand. A
skipped run leaves the inbox exactly as it was, with one line explaining why.

Predictable refusal beats partial success for anything unattended.

### The yearly runtime credit

Paying yearly loads the wallet on day one: **$50 on Pro, $500 on Team**.

The detail worth knowing is that yearly is **twelve times the monthly price**.
The yearly incentive is the wallet load, not a lower rate. That credit:

- spends on hosted runs and [BYOK](/glossary/byok) platform fees alike
- is drawn **before** money you loaded yourself
- stays good for 12 months
- buys tokens at list price with no markup, like everything else

Drawing the credit first matters more than it sounds: it means the free money
goes first and your own balance is what survives to next month.

### Team wallets

Team pools **one wallet across the account**, with spend controls, rather than
making ten people each top up their own. That matches how the plan's other
limits work, since Team's 50,000 daily tool calls are pooled too.

Enterprise can bring its own provider keys or commit to capacity instead.

### When the wallet is the wrong choice

Worth naming, because the wallet is not automatically the right route.

- **You already have committed provider spend.** If you negotiated rates with
  Anthropic or OpenAI, routing through a prepaid balance wastes them. Use
  [BYOK](/glossary/byok).
- **Finance wants one vendor line.** BYOK keeps model spend on the provider bill
  you already reconcile.
- **You are running high volume.** Above 1M tokens a month the BYOK platform fee
  is 5% of list, which is worth comparing against the wallet's 5.5% load fee.

Under about 1M tokens a month the two land close together, and the honest
summary is that the wallet is simpler and BYOK gives you control.

### The reasonable objection

"Prepaid balances are how companies keep money they have not earned."

Fair, and the design answers it in three specific ways. The credited balance is
exactly what you loaded, so the fee is visible at the door rather than buried in
a rate. Tokens draw at the provider's list price to the cent, so the balance
depletes at a rate you can verify against your provider's own pricing page. And
every [run receipt](/glossary/run-receipt) states what that run consumed, so the
balance is auditable run by run rather than as one monthly number.

### FAQ

#### Does WorkerKit mark up model tokens bought with the wallet?

No. Tokens bill at the provider's list price to the cent. WorkerKit's fees are
the plan price and the 5.5% wallet top-up fee with a $1 minimum, both stated in
the open. The credited balance is exactly the amount you loaded.

#### What happens if my wallet runs out mid-schedule?

Nothing runs half way. Each run reserves its budget before starting, so a
balance that will not cover it causes that run to be skipped with the reason on
the receipt. Top up and the next due run proceeds normally, with no settings
changed and nothing deleted.

#### What is the minimum I can load?

$5, which is charged as $6 because of the $1 minimum fee and credits $5 of
tokens at list price. Larger loads pay the flat 5.5%, so frequent small top-ups
are the expensive way to use it.

#### Does the yearly runtime credit expire?

It stays good for 12 months and is drawn before money you loaded yourself, so
the credit is spent first. Pro yearly loads $50 and Team yearly loads $500, both
on day one.

#### Can a team share one wallet?

Yes. Team pools a single wallet across the account with spend controls, matching
how its 50,000 daily [tool calls](/glossary/tool-call) are pooled rather than
divided per seat. See [/pricing](/pricing).

#### Can I use my own provider key instead?

Yes. Adding an Anthropic, OpenAI, Google or xAI key bills those tokens straight
to your provider account, with the first 1M tokens each month carrying no
platform fee. See [BYOK](/glossary/byok).

## structured output

URL: https://workerkit.ai/glossary/structured-output
Also called: typed output, constrained decoding, JSON mode, schema-constrained output, structured outputs
Updated: 2026-09-16

**What is structured output?** Structured output is a model answer constrained to a schema the caller declared, so the result parses reliably instead of being read out of prose.

Every system that puts a model in the middle of a pipeline meets the same wall.
The model answers in sentences. The next step needs a value.

Structured output is the fix. You declare the shape before you ask, and the
answer arrives in it: a JSON object against a schema, one option from a named
set, a number on a scale you defined, a function call with typed arguments. The
caller owns the shape. The model fills it in.

### What it solves: parsing prose is the oldest bug in AI plumbing

Without it, connecting a model to code means reading English with a regular
expression. That works for a week. Then it stops, in three ways worth naming
because each one is silent:

- **The wrapper.** "Sure, here is the JSON you asked for:" and your
  `JSON.parse` throws on the first character.
- **The drift.** The model said "billing" for a month, then a version change had
  it say "invoice query". Your keyword match now falls through to the default
  branch, and the default branch is a queue nobody watches.
- **The hedge.** "Probably a billing question, though it also mentions the
  outage." Both words are in the string. Whichever one your matcher checks first
  wins, and it has no idea it just flipped a coin.

None of these raise an alert. Each produces a plausible run, a written record and
a wrong outcome. A schema removes the category, because the shape of the answer
is something you decided rather than something you have to discover.

### Three ways it gets done, in increasing order of guarantee

| Approach | Who enforces the shape | What still goes wrong |
| --- | --- | --- |
| Ask in the prompt: "reply as JSON with these keys" | Nobody. It is a request | Prose around the block, a missing key, an invented key, a trailing comma |
| Constrain the decoder to a grammar or schema (JSON mode, function calling) | The sampler, which can only emit tokens the grammar permits | Nothing at the parse layer. A required field can still be filled with something plausible and empty |
| A model whose entire output surface is a schema | The model has no free-text channel to leave the schema through | The pick can be wrong, and with no no-match option it must pick something |

The first row enforces nothing. The second is what most teams use on a general
purpose model. The third is a different class of model:
[System One models](/glossary/system-one-model) such as TypeSafe's Jev, which
TypeSafe put into public early access on 2026-09-15, answer only in declared
types and, on the vendor's own account, cannot write a sentence at all. Their
documentation describes the mechanism as returning "a full probability
distribution over those options rather than inventing a value outside the
schema". Vendor-published, and a description of the mechanism rather than a
measurement.

### The guarantee, and exactly where it stops

Here is the sentence the rest of this page hangs off: **a schema guarantees the
interface, not the truth.**

Constrained decoding makes one class of failure impossible. The answer parses,
the enum value is one of yours, the number is in range. It says nothing about
whether the answer is right, and a model will return a perfectly valid, perfectly
typed, completely wrong one.

That is worse than a parse error, not better, and the reason is downstream. A
parse error is loud: it throws, you catch it, something logs, a person looks. A
well formed wrong answer looks exactly like a right one to every line of code
after it. It gets branched on, written into the record, and the ticket sits in
the wrong queue until a customer complains.

So structured output does not reduce your risk. It moves it from the parser to
the judgement, which is where it always was. Three things put a handle on what is
left:

- **A confidence number**, where the model gives one. TypeSafe's API reference
  says Jev's Choice and Score answers "carry a `confidence` between 0 to 1,
  derived from the answer's probability distribution"; their confidence page adds
  that noul answers, the yes-or-no ones, carry none at all. See
  [calibrated confidence](/glossary/calibrated-confidence).
- **A floor you act on**, so low scoring answers stop instead of proceeding. See
  [confidence threshold](/glossary/confidence-threshold).
- **A human downstream** for anything where being wrong is not recoverable.

### What a typed answer buys you when nobody is watching

| What comes back | What your code does with it | What prose cost you |
| --- | --- | --- |
| One option from a declared set | Branch straight to the queue, owner or label it names | Matching wording that changes between model versions |
| A number on a declared scale | Compare against a threshold, sort the pile by it | Turning "fairly urgent" into an order |
| A confidence between 0 and 1 | Hold anything under your floor for a person | Nothing. Prose has no uncertainty field to read |
| A declared no-match option | Detect the refusal and stop rather than guess | Spotting "I am not sure" in forty phrasings |
| The same shape on every run | A [run receipt](/glossary/run-receipt) whose fields line up week over week | Diffing paragraphs |

The last row is the quiet one. Unattended work is only reviewable if two runs can
be compared, and comparing typed fields is arithmetic while comparing paragraphs
is reading.

### Always declare a no-match option

A closed set is the guarantee, and it is also the trap. The model cannot answer
outside your options, so when the right answer is not in the list it returns the
closest wrong one, with no signal that it did.

TypeSafe's documentation gives the rule for its Choice question: add an `other`
or `none of the above` option when the list might not cover every input. That
page also caps a Choice at 255 options. The advice generalises to any schema:
every enum needs an escape hatch, and every escape hatch needs a branch in your
code that does something other than carry on.

### Where this touches a worker

A [tool call](/glossary/tool-call) is structured output. When a worker files a
ticket or updates a CRM field, the model did not describe an API request in
English. It emitted a named tool with typed arguments, validated against what
that app exposes over [MCP](/glossary/mcp).

That is what makes permission enforceable. Because the intended action is a typed
value before it is an action, the [app firewall](/glossary/app-firewall) can
check it against the level you granted, Off, Read or Write, and refuse it. Prose
cannot be checked that way, which is why access control on
[the Connected apps page](/apps) sits at the call, not in the instruction.

Most real jobs are both halves at once. [Support Inbox
Triager](/kit/support-inbox-triager) classifies each thread by urgency and topic,
which is typed, then drafts a reply, which is prose. [Inbox Triage
Assistant](/kit/inbox-triage-assistant) sorts every thread into one of three
buckets before it drafts anything. Kits ship the instruction, not the model, so
you pick which model runs both halves at deploy time and compare results on your
own examples. Tokens bill at provider list price with no markup.

Where a job is only the typed half, with no reply to write, WorkerKit runs it as
a [decision worker](/blog/decision-models-vs-agents). A model with no free-text
channel cannot drive an agent loop, so a decision worker has none: items
fetched, each judged with typed questions, the routing done in code. Every read
and every action goes through the same firewall door an agent worker uses. That
is a different class of worker rather than a model option, which is why Jev is
not in the deploy-time model picker.

### When structured output is the wrong tool

- **The answer genuinely is prose.** The reply, the summary, the brief. A schema
  around a sentence is a sentence with extra steps.
- **You want the reasoning.** A constrained answer has nowhere to put one.
  TypeSafe is blunt about their own class of model: "System One models do not
  write replies, produce code, or generate explanations of their reasoning."
- **The option set cannot be known in advance.** If you cannot enumerate it you
  cannot constrain it, and a forced pick from a wrong list is worse than free
  text you at least know to read.
- **Ordinary code already has the value.** Arithmetic, exact matches and lookups
  on fields you already hold are cheaper, exact and free.
- **The decision is legally consequential for a person.** Hiring, credit,
  benefits, discipline. Sorting and surfacing for a human reviewer is fine.
  Deciding unsupervised is not, however tidy the output shape looks.

### FAQ

#### What is structured output in AI?

It is a model answer constrained to a shape the caller declared in advance: a
JSON schema, a set of allowed options, a number on a defined scale, or a function
call with typed arguments. Code can branch on the result directly instead of
reading it out of a paragraph with string matching.

#### Does structured output stop hallucination?

No. It removes one kind, since a value outside the schema cannot be expressed, so
an option you never declared cannot appear. It does nothing about the answer
being wrong. A valid, typed, confidently returned answer can still be incorrect,
and that is harder to catch than a parse error because nothing downstream
notices.

#### Is JSON mode the same as structured output?

JSON mode is one implementation: the decoder is constrained so the output is
always valid JSON, sometimes against a schema you supply. Structured output is
the broader idea, covering function and tool calling, enum-only answers, and
models whose entire answer surface is typed.

#### Are tool calls structured output?

Yes. A tool call is a named function with typed arguments, validated against the
tool's declared schema before anything runs. That is why permissions can be
enforced at all: the intended action exists as a checkable value before it
becomes an action, so a firewall can compare it to the access level granted and
refuse it.

#### What happens if the right answer is not one of the options?

The model returns the nearest option anyway, because the schema leaves it no
other move, and nothing in the response marks it as a stretch. The fix is a
no-match option such as `other` or `none of the above` in every closed set, with
its own branch that stops and asks rather than proceeding.

## System One model

URL: https://workerkit.ai/glossary/system-one-model
Also called: System 1 model, decision model, Jev, TypeSafe Jev
Updated: 2026-09-16

**What is a System One model?** A System One model is an AI model that answers typed questions about data you supply with a pick, a score or a probability, never generated text.

A System One model does one job. You hand it some state, whatever text you
already have, plus a list of typed questions, and it hands back one typed answer
per question. No prose, no tool call, no next step. The answer is a value your
code can switch on.

Most of what people spend a chat model on is not writing, it is judging: is
this spam, which queue does it belong in, how urgent is it. Each has a small
fixed set of possible answers.

One caution up front, because the marketing around
[structured output](/glossary/structured-output) blurs it: the type guarantees
the **interface**, not the truth. A model that cannot return an option outside
your list will still sometimes return the wrong option from inside it.

### Where the name comes from

Daniel Kahneman described two modes of thinking: System 1, fast and intuitive,
and System 2, slow and deliberate. A chat model imitates System 2 by thinking
out loud, and those tokens are where most of its time and bill go. A System One
model is named for the other half, the immediate read with nothing shown. That
is a convention about the output, not a claim about cognition.

### System One model, chat model, ordinary code

| | System One model | Chat model | Ordinary code |
| --- | --- | --- | --- |
| What it returns | A pick, a score or a probability | Generated text, optionally a tool call | Exactly what you wrote |
| Can call tools | No | Yes | It is the caller |
| Latency | Vendor-published at about 100 ms | Seconds, more when it reasons aloud | Microseconds |
| Cost shape | Per token read, once per batched call | Per token in and per token out | Free once written |
| Good at | Judging messy input against declared options | Writing, reasoning, multi-step work | Arithmetic, lookups, exact matching |

The last row decides most architectures: the middle column can do the outer
columns' work, badly and expensively.

### The three question types

TypeSafe's documentation defines three, and their shapes are the whole API.

| Type | The question | What you declare | What comes back |
| --- | --- | --- | --- |
| Choice | Which of these options? | Up to 255 options, each described | The pick, a probability per option, a confidence |
| Score | Where on this ordered ladder? | Between 2 and 10 levels, in order | A mean between the rungs, the distribution, a confidence |
| Noul | Is this true? | The statement | One probability from 0 to 1, no confidence field |

Three details matter more than they look:

- **Option names and descriptions both go to the model; question ids do not.**
  The docs say to "write descriptions that separate the options from each
  other", and "Question IDs are for your code." Your meaning lives in the
  criteria.
- **A score comes back between the rungs**, as a probability-weighted mean (1.30
  in the docs' example), not as one of the levels you declared.
- **A noul near 0.5 means yes and no are equally likely, not medium intensity.**
  That reading is ours, not a line in the docs. For intensity, the docs route
  you to a score along defined levels.

### Jev, the first one in public early access

Jev, from TypeSafe, reached public early access on 2026-09-15 and is the first
System One model we know of to get there. Everything below is vendor-published
rather than measured here, and the two halves of their site do not say the same
things, so it matters which half a fact comes from. Their launch post calls the
access waitlisted; their quickstart just tells you to get an API key from the
dashboard and mentions no gate at all.

**From the docs:** questions ride one request and are evaluated independently,
so "adding more questions does not create context-rot"; a budget of about
32,000 tokens, or "roughly 150,000 characters of English text". Their
parallel-questions cookbook puts 13 questions to a 54,000 character Wikipedia
article, five repeats each way on `jev-1.12`, and reports the batched call at
12.2x cheaper and 10.0x faster than 13 separate calls. Another vendor page
reports that same experiment as 11.5x and 9.6x. Batching did not change the
answers, which is the weaker and more useful claim than identical answers: a
couple of the 13 do move between repeats, by the same amount whichever way
they are called, which the page reads as noise belonging to the question
rather than to the batching. One article, one model, one run set. The shape
underneath needs no multiple: N separate calls pay to read the document N
times, the batched call pays once.

**From the launch post:** $0.042 per million input tokens, output tokens
reported on the response but not billed, most queries completing in about
100 ms, and a note that the rate may be subsidised. The docs carry no price list
at all; the nearest thing is the cost table in that cookbook, which pins its
rate to a dated version, `jev-1.12` "as of 2026-09". Read it as a per-version
early-access rate rather than a standing price. A general-purpose model such
as GPT-5.6 Luna is $0.20 per million input tokens and $1.20 out, so the
published Jev rate is a little under five times cheaper on input. Our rates
are on [/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

No rate limit, quota, concurrency ceiling or uptime commitment is published
anywhere. Their API reference covers the 429 and 529 responses only in terms of
what to do about them, "retry the request with exponential backoff instead of
retrying immediately", which tells you throttling exists without telling you
where it sits. The DPA, retention and training-use policies were unpublished as
of 2026-09-16. Settle both before you send anyone's data.

### Why one is not an AI worker on its own

| What an unattended worker needs | What a System One model gives you |
| --- | --- |
| Reach an app and act in it | No tool calls at all |
| Take a turn, read the result, take another | One request, one set of answers |
| Write the reply, the summary, the message | No generated text |
| Start itself on a schedule or a trigger | Nothing starts it |

An [AI worker](/glossary/ai-worker) is an agent set up to do one job unattended:
it starts on a schedule or an event, reaches real accounts with its own scoped
key, and leaves a receipt. A System One model supplies none of that by
construction. TypeSafe's concepts page says "System One models do not write
replies, produce code, or generate explanations of their reasoning", and their
how-to page adds that "every loop introduces another opportunity to go off the
rails."

Judgment and work are two halves of one job, the subject of
[Jev and decision models](/blog/jev-and-decision-models). An agent worker runs
on a general model because it has to write the reply and make the
[tool call](/glossary/tool-call). A decision worker is the other shape: no agent
loop, so the judging is the run, and the acting happens in code through the same
firewall door an agent run uses. WorkerKit runs both, which is why a System One
model is a worker class here rather than an entry in the model picker.
[Support Inbox Triager](/kit/support-inbox-triager) sorts a support inbox and
drafts the answer: sorting suits a decision model, drafting does not.

### Where the judgment still needs restraints

A typed answer with a number on it feels safer than a paragraph, and that is the
hazard. A [calibrated confidence](/glossary/calibrated-confidence) is derived
from the shape of the returned distribution, concentrated for a confident answer
and spread for an uncertain one. It is a statistic about that distribution, not
the model reporting how sure it feels, and it says nothing about correctness.

TypeSafe describe three bands in prose: act automatically on high confidence,
proceed with caution in the middle, and on low confidence route to a human. The
numbers people quote, 0.9 and 0.5, come from one worked example whose above-0.9
branch still confirms with the user, because that action is high stakes. The
governing sentence there is about stakes rather than a number: "Different
actions within the same system should be gated at different levels depending on
the consequences of getting it wrong." Their own example gates a balance check
lower than a transfer approval. A
[confidence threshold](/glossary/confidence-threshold) is your number, derived
for your domain, and one number for a whole system is already the wrong shape.

A threshold is not a permission. It decides whether to act, and says nothing
about what the acting may touch. That is an
[app firewall](/glossary/app-firewall), with
[contact rules](/glossary/contact-rules) and
[redaction](/glossary/redaction) beside it, and on WorkerKit all three ship on
every plan including Free.

### When you do not want one

- **Anything that has to produce prose.** That needs a model that writes.
- **Open-ended or multi-step work.** There is no loop, by design.
- **Arithmetic, lookups, exact matching, thresholds on numbers you hold.**
  Ordinary code is cheaper, exact and free.
- **Retrieval.** It judges candidates you already found. Finding them is search.
- **Any option set you cannot know in advance.** A choice cannot express an
  answer outside its list, so always carry a no-match option.
- **Legally consequential decisions about people, unsupervised:** hiring,
  firing, credit, benefits, discipline. Sorting for a human reviewer is fine.
  Deciding is not, however well calibrated the number looks.
- **Anything where being wrong sometimes is unacceptable and nobody is
  downstream.** A floor makes uncertainty visible, not the model right.

### FAQ

#### What is Jev?

Jev is a System One model from TypeSafe, in public early access since
2026-09-15. You send it text plus a list of typed questions and it returns one
typed answer per question: a pick from options you declared, a score on a ladder
you declared, or a probability that a statement is true. It writes no prose and
calls no tools.

#### Is a System One model just a small language model?

No. A small language model still generates text token by token, and you still
parse what comes out. A System One model returns a value from a set you
declared, with a distribution over it, and no free-text field to parse. The
difference is the output contract, not the size.

#### What has to sit around a System One model for it to do a job?

The parts it leaves out, which together are an
[AI worker](/glossary/ai-worker): something to start it on a schedule or a
trigger, reach the connected apps, act, and write whatever a person reads. It
can decide which queue an email belongs in; something else still has to move it
and answer it.

#### How do you run a System One model on WorkerKit?

As a decision worker, not as a model choice. The deploy-time picker chooses
which general model does the writing work, and a decision worker has no agent
loop to write in, so it is a separate worker class instead of an entry in that
list. It judges each item with typed questions, routes on the answer in code,
and acts on the worker's own key under the same per-app Off, Read or Write
grants, contact rules and redaction an agent run gets.

#### What does the confidence number on an answer mean?

It is derived from the shape of the probability distribution the model returned:
concentrated on one outcome means a confident answer, spread across several
means an uncertain one. In Jev's case, choice and score answers carry one
between 0 and 1 and noul answers carry none. It measures agreement, not
correctness.

#### What does a System One model cost to run?

TypeSafe's launch post prices Jev at $0.042 per million input tokens, with
output tokens reported but not billed, and says the rate may be subsidised.
That is vendor-published, tied to a dated model version, and not measured here.
A general-purpose model such as GPT-5.6 Luna is $0.20 per million input tokens
and $1.20 out, billed at provider list price with no markup. On WorkerKit a
decision worker meters the item judged, not the token. See
[/pricing](/pricing).

## tool call

URL: https://workerkit.ai/glossary/tool-call
Also called: tool invocation, agent action, API action
Updated: 2026-07-17

**What is a tool call for an AI worker?** A tool call is one action an AI worker takes in a connected app, such as reading a thread or adding a calendar event, and it is the unit plans meter.

Tokens measure how much an agent **thought**. Tool calls measure how much it
**did**. They are different costs, metered differently, and confusing them is
the most common surprise on a first invoice.

### Tokens vs tool calls

| | Model tokens | Tool calls |
| --- | --- | --- |
| Measures | Reading and writing text | Actions in connected apps |
| Billed by | Your model provider, at list price | Included in your plan |
| Runs out how | A balance empties, the run is skipped | A daily cap is hit, the worker pauses |
| Controlled by | The [wallet](/glossary/runtime-wallet) or [your key](/glossary/byok) | Your plan tier |
| Grows with | How much context a run reads | How many actions a run takes |

Running out of one does not affect the other. A worker can have plenty of wallet
balance and still pause at its daily cap, and vice versa.

### What counts as one

One thing done in one connected app:

- reading an email thread
- sending a reply
- adding a calendar event
- looking up a CRM record
- creating a task

Each is one invocation of a tool the app exposes, which is also the unit
[MCP](/glossary/mcp) speaks in.

A single run makes several. [Meeting Prep Assistant](/kit/meeting-prep-assistant)
reaches calendar, email, meeting notes and CRM to build a prep sheet: it might
list the day's meetings, read two threads per meeting, pull a CRM record and
write one document. That is easily a dozen calls for one meeting-heavy morning.

### The daily caps

| Plan | Tool calls a day | Rate shaping |
| --- | --- | --- |
| Free | 500 | 60 an hour |
| Pro | 5,000 | Daily cap |
| Team | 50,000, pooled | Daily cap, burst headroom |
| Enterprise | Custom | Priority lanes |

Two details worth pulling out. Free carries an **hourly** shape of 60 as well as
the daily 500, so a burst is smoothed rather than spending the day's allowance
before lunch. Team's allowance is **pooled across the account** rather than
divided per user, so one heavy worker does not starve the rest by design.

### Estimating a worker before you deploy it

Multiply calls per run by runs per day. That is the whole model, and it is worth
doing before adding a schedule rather than after.

| Pattern | Runs a day | At 8 calls a run | Fits |
| --- | --- | --- | --- |
| Once each morning | 1 | 8 | Free |
| Hourly, 10 hour day | 10 | 80 | Free |
| Every 15 minutes, all day | 96 | 768 | Pro |
| Every minute | 1,440 | 11,520 | Over Pro's cap |

Frequency is the multiplier on everything. This is the concrete reason to pick a
[schedule](/glossary/worker-schedule) that matches the job rather than the
fastest one available: the last row is not merely expensive, it is impossible on
Pro.

And a minute-by-minute schedule is usually a
[webhook trigger](/glossary/webhook-trigger) nobody has wired yet. A trigger runs
only when something actually happened, so it typically costs less than an hourly
schedule while reacting in seconds.

### Hard caps are the right failure

At the cap a worker **stops until the counter resets, then picks its schedule
back up.** Nothing is deleted. No setting changes. No overage appears on a bill
you did not agree to.

For unattended work a hard cap is a better failure mode than a soft one. A
runaway loop on a soft cap is an invoice you discover later; on a hard cap it is
a paused worker and a [receipt](/glossary/run-receipt) explaining why. You lose
some work and learn immediately, instead of losing money and learning at the end
of the month.

The reasonable objection is that a hard cap can stop real work at a bad moment.
True, and the mitigations are in your hands: the receipt names the cause, caps
reset daily, and Team pools its allowance so a spike in one worker draws on the
whole account rather than one seat's share.

### When the cap is the wrong thing to optimise

Not every high-call worker is a problem to solve.

- **A once-daily sweep that reads a lot** is fine. It is one run; the calls are
  the job.
- **A worker close to its cap on Free** may simply belong on Pro. $29 a month
  against the time spent re-tuning a schedule is usually not a close call.
- **A worker that is genuinely event-shaped** should move to a trigger rather
  than have its polling interval tuned.

Published WorkerKit plans and prices apply to shared cloud.

The thing actually worth optimising is a worker that makes many calls to
discover that nothing happened.

### FAQ

#### What counts as a tool call on WorkerKit?

One action a worker takes in a connected app: reading an email thread, sending a
reply, adding a calendar event, looking up a CRM record, creating a task. A
single run usually makes several.

#### How many tool calls do I get?

500 a day on Free with 60 an hour of rate shaping, 5,000 a day on Pro, and
50,000 a day on Team pooled across the whole account. Enterprise is custom with
priority lanes.

#### What happens when a worker hits the daily limit?

It stops until the counter resets, then resumes its schedule. Nothing is deleted
and no configuration changes. The caps are hard by design so an unattended fleet
cannot run up an overage.

#### Are tool calls the same as model tokens?

No. Tool calls are actions in your apps, included in your plan and capped daily.
Model tokens are what the model reads and writes, billed separately at provider
list price with no markup from the [wallet](/glossary/runtime-wallet) or
[your own key](/glossary/byok). See [/pricing](/pricing).

#### How do I reduce a worker's tool calls?

Lower the frequency first, since runs per day multiplies everything else. If the
job is really a reaction to an event, move it to a
[webhook trigger](/glossary/webhook-trigger), which does not run at all on a
quiet day.

## webhook trigger

URL: https://workerkit.ai/glossary/webhook-trigger
Also called: event trigger, inbound webhook, event-driven agent
Updated: 2026-07-16

**What is a webhook trigger?** A webhook trigger is an inbound HTTP call that starts an AI worker the moment something happens in another system, instead of waiting for its next run.

A [schedule](/glossary/worker-schedule) asks "is there anything to do?" on a
clock. A trigger is told. For work that must happen *when* something happens,
being told is both faster and cheaper.

### Trigger vs schedule

| | Webhook trigger | [Schedule](/glossary/worker-schedule) |
| --- | --- | --- |
| Starts on | An event in another system | A clock, in your time zone |
| Latency | Seconds | Up to one interval |
| Cost when nothing happened | Nothing, it never fired | A run's worth of [tool calls](/glossary/tool-call) |
| Survives a missed event | No | Yes, the next run sweeps |
| Needs the sender configured | Yes, with a secret | No |
| Real kit | [Inbound Lead Qualifier](/kit/inbound-lead-qualifier) | [Executive Daily Briefing](/kit/executive-daily-briefing) |

### When a trigger is the right answer

The test is latency, not importance.

[Inbound Lead Qualifier](/kit/inbound-lead-qualifier) is the clearest case: it
connects email and CRM, and it runs on an **event**. A new inbound lead is
qualified, filed in the CRM, and answered with a drafted first reply within
minutes. On an hourly schedule the same kit would be up to an hour late, and in
inbound sales an hour is the difference between first and forgotten.

[Dynamic Focus-Time Optimizer](/kit/dynamic-focus-time-optimizer) shows the
hybrid: it runs on demand, on a schedule **and** on events, so a calendar change
can rearrange your focus blocks immediately while the schedule still does the
14-day sweep.

Use a schedule instead when the job has a natural rhythm: a morning brief, an
end-of-day digest, an hourly queue sweep. Polling is fine when "within the hour"
is fine.

### What polling costs that a trigger does not

The cost argument is usually stronger than the latency one, and it is easy to
work out. Take a worker that spends 6 [tool calls](/glossary/tool-call) checking
for new work, on a day when 4 real events actually arrive:

| Approach | Runs a day | Tool calls a day | Worst-case latency |
| --- | --- | --- | --- |
| Every minute | 1,440 | 8,640, over every plan's cap | 60 seconds |
| Every 15 minutes | 96 | 576, over Free's 500 | 15 minutes |
| Hourly | 24 | 144 | 60 minutes |
| Webhook trigger | 4 | ~24 | Seconds |

The trigger does less work than the hourly schedule **and** reacts faster than
the minute-by-minute one. That is unusual: normally latency is bought with cost.
It happens here because polling spends its budget discovering that nothing
happened, and an event-driven worker never runs on a quiet day at all.

Free allows 500 tool calls a day, Pro 5,000, and Team 50,000 pooled, so the top
two rows are not only wasteful, they are unaffordable.

### Use both, and not for redundancy

Most real workers want the pair, and the two jobs are genuinely different:

- The **trigger** handles events as they arrive.
- The **schedule** is the safety net for whatever the trigger missed, because
  the sending system was down, the payload was malformed, or the run errored.

Triggers travel over a network, and networks drop things. A worker with only a
trigger has no way to notice it was never called. That is the failure mode a
schedule quietly covers.

### The trigger secret

A webhook URL is reachable by anyone who learns it, so each trigger is signed
with a secret the calling system includes, and WorkerKit verifies it before
running anything.

Two consequences worth planning for:

- The secret can be **rotated**, and the sending system must be updated when it
  is. A stale secret shows up as refused calls, not as silent success.
- The wire format is disclosed rather than magic, so you can configure a sender
  that has never heard of WorkerKit.

### Every trigger leaves a receipt

A triggered run writes the same [receipt](/glossary/run-receipt) as a scheduled
one, and the receipt carries the payload the run was started with.

That matters more for triggers than for schedules. When a triggered run does
something surprising, the first question is always "what was it actually sent?",
and the receipt is the answer.

### FAQ

#### What is the difference between a webhook trigger and a schedule?

A schedule starts a worker on a clock in your own time zone. A webhook trigger
starts it when another system sends an HTTP call, so the worker reacts within
seconds instead of waiting for its next interval. Many workers use both, with the
schedule acting as a safety net for missed events.

#### Can one worker have both a trigger and a schedule?

Yes, and it is the usual setup for anything time-sensitive.
[Dynamic Focus-Time Optimizer](/kit/dynamic-focus-time-optimizer) runs on demand,
on a schedule and on events at once.

#### How is a webhook trigger secured?

Each trigger is signed with a secret that the calling system includes, verified
before anything runs. Secrets can be rotated, and a stale secret produces refused
calls rather than silent failures.

#### Do triggered runs count against my tool call limit?

Yes. A run costs the same [tool calls](/glossary/tool-call) however it started.
The saving from a trigger is that it does not fire at all when nothing happened,
where a frequent schedule spends calls checking.

#### Can I see what payload started a run?

Yes. The [run receipt](/glossary/run-receipt) carries the run context including
the payload the webhook delivered, which is what makes a surprising triggered run
diagnosable rather than a mystery.

## worker fleet

URL: https://workerkit.ai/glossary/worker-fleet
Also called: agent fleet, worker team, agent estate
Updated: 2026-08-06

**What is an AI worker fleet?** A worker fleet is the set of AI workers running in one account, each doing one narrow job with its own key and its own app permissions.

The instinct with a capable model is to build one assistant that does everything.
The pattern that survives contact with production is the opposite: **several
narrow [workers](/glossary/ai-worker), one job each.**

### One broad worker vs a fleet of narrow ones

| | One worker, many jobs | A fleet of narrow workers |
| --- | --- | --- |
| Access it holds | The union of every job's needs | Only what its one job needs |
| A bad run affects | Everything it touches | One job |
| Switching it off | Loses all the jobs | Loses one |
| Debugging a mistake | Which of nine jobs was it doing? | The receipt is about one job |
| Instruction | Long, conditional, brittle | Short, testable |
| Cost of adding a job | Rewrite and re-test the whole thing | Add a worker |

The access row is the one that decides it. A worker doing nine jobs needs the
union of nine permission sets, so every job runs with the reach of all the
others. The triage job holds CRM write access it never needs, because the CRM job
does.

### What the plans allow

| Plan | Workers | Tool calls a day |
| --- | --- | --- |
| Free | 5 | 500 |
| Pro | 50 | 5,000 |
| Team | 500 | 50,000, pooled |
| Enterprise | Custom | Custom |

Free allowing **five** workers rather than one is deliberate and is the whole
argument in a number: a single-worker free tier would push you toward the broad
worker on day one and teach the wrong pattern.

Team's [tool calls](/glossary/tool-call) are **pooled across the account** rather
than divided per seat, so a busy worker draws on the whole allowance instead of
starving on its own share.

### A real fleet, costed

Four kits from the directory, each doing one job:

| Worker | Apps | Starts on | Tool calls a day |
| --- | --- | --- | --- |
| [Executive Daily Briefing](/kit/executive-daily-briefing) | calendar, email, tasks | Daily | ~15 |
| [Engineering Pulse](/kit/engineering-pulse) | github | Daily | ~20 |
| [Support Inbox Triager](/kit/support-inbox-triager) | email, tasks | Hourly | ~120 |
| [Follow-Up Tracker](/kit/follow-up-tracker) | email, tasks | Daily | ~25 |

That is about **180 tool calls a day**, four of Free's five worker slots, and
comfortably inside Free's 500. A real working fleet fits on the free plan, which
is worth knowing before assuming a fleet implies a bill.

What pushes an account to Pro is usually **frequency and log retention** rather
than headcount: moving triage to every 15 minutes roughly quadruples its share,
and Free keeps only 1 day of [receipts](/glossary/run-receipt) against Pro's 30.

### Why narrow jobs are easier to trust

Each worker in that table has its own key and its own grants. Three consequences
follow, and they compound:

- **Blast radius is bounded by design.** The briefing worker holds Read on three
  apps and can change nothing. If its instruction drifts, the worst case is a
  bad summary.
- **Switching one off is cheap.** Suspicion about the triager does not cost you
  the morning brief, so you actually act on the suspicion.
- **Receipts are legible.** A [receipt](/glossary/run-receipt) for a worker with
  one job answers "did it do the job". A receipt for a worker with nine answers
  "here is a list of things that happened".

### The failure mode: fleet sprawl

The problem with fleets is not technical, it is that they accumulate.

Eighteen months in, an account has twenty-two workers. Four do nearly the same
thing because three people each built one. Two were built by someone who has
left. One is switched off and nobody remembers why, and nobody will switch it
back on in case that reason mattered.

Nothing failed. There was simply never a moment that forced anyone to describe
the estate. This is the same shape as [private kit](/glossary/private-kit) sprawl
and has the same cheap discipline: **every worker states its one job in a
sentence, and if it needs two sentences it is two workers.**

The other half is a periodic read of what exists. A fleet is infrastructure, and
infrastructure nobody inventories is infrastructure nobody can reason about.

### The reasonable objection

"Five narrow workers mean five instructions to maintain and five sets of
permissions. One worker is less work."

True on day one and false by month three. The maintenance argument assumes the
instructions stay independent, which is exactly what narrowness buys: changing
the triage rules touches one short instruction, where in the broad worker it
means editing a long conditional document and re-testing the eight jobs you did
not intend to change.

The permissions point inverts too. Five grants of two apps each is more clicks
than one grant of six apps, and it is the version where you can answer "what can
this thing reach" without reading a spec.

### When one worker is genuinely right

- **The steps are one job.** A multi-step sequence with a single definition of
  done is one worker, not four. Splitting by *step* rather than by *job* is the
  opposite mistake.
- **The jobs share all their state.** If two jobs only make sense reading each
  other's working memory, they are one job.
- **You are prototyping.** Prove the job is real, then split it.

The test is the sentence: if you can state what it does without "and", it is one
worker.

### FAQ

#### How many AI workers can I run?

Five on Free, 50 on Pro, 500 on Team, and custom on Enterprise. Free's five is
deliberate: a real fleet of four narrow workers fits inside the free plan with
room to spare.

#### Should I build one AI agent or several?

Several, each doing one job. A single broad agent needs the union of every job's
permissions, so every job runs with the reach of all the others, and one bad run
affects everything it touches. Narrow workers bound the blast radius and make
receipts legible.

#### Does a fleet of workers cost more than one?

Not necessarily, because cost tracks work rather than headcount. Four workers
doing about 180 [tool calls](/glossary/tool-call) a day fit inside Free's 500.
What pushes an account up a tier is usually run frequency and log retention. See
[/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

#### Do workers in a fleet share access or memory?

No. Each worker has its own key, its own per-app grants and its own memory. A
fact relevant to several workers has to be given to each, which is what stops a
wrong fact or an over-broad permission from spreading across the fleet.

#### How do I stop a fleet becoming unmanageable?

Make every worker state its one job in a sentence, and treat a worker needing two
sentences as two workers. Then read the estate periodically: sprawl is an
inventory problem rather than a technical one, and it accumulates silently
because nothing ever fails.

## worker kit

URL: https://workerkit.ai/glossary/worker-kit
Also called: kit, AI worker kit, agent template
Updated: 2026-10-08

**What is a worker kit?** A worker kit is a ready-made AI worker packaging instructions or decision rules, app permissions, and setup for one job, ready to run with your own accounts.

A kit is to an [AI worker](/glossary/ai-worker) what a recipe is to a meal: the
whole method, written down by someone who already cooked it, so you do not have
to work it out yourself.

The directory includes [language model kits](/kits/language-models), which follow
instructions to research, write, and act, and [decision model kits](/kits/decision-models),
which return typed judgments and route work through defined rules. An agent can use
a decision worker's results to complete the next step. [Browse both types](/kits).

### What is inside a kit

A kit is not a prompt. It carries every part of a worker that had to be decided:

- **The instructions or decision rules.** The standing brief for the job, written and tested
  against real runs rather than drafted once and hoped for.
- **The app permissions.** Which apps the job needs, and the exact access level
  each one gets. A kit states this before you take it, so you know what you are
  agreeing to.
- **The memories.** The facts and rules the worker should carry between runs.
- **The schedule or trigger.** When the job should happen.

### Why a package and not a prompt

The hard part of an unattended agent is never the model. It is the instruction,
the access rules and the wiring, and all three take real work to get right.

Someone has to discover that the job breaks when the CRM field is empty. Someone
has to decide the agent gets Read on the calendar and Write on drafts only.
Someone has to write the sentence that keeps it from replying to the wrong
thread. A kit is that work, already done, by a publisher who ran it.

So the value of a kit is not that it saves you typing. It is that it saves you
the four hundred runs it takes to learn what the instruction should have said.

### Taking a kit

Taking a kit creates a worker in **your own account**, with its own key and only
the access you granted. The kit is a template; the worker is yours. Two things
follow:

- The publisher never gains access to your accounts. A kit cannot reach an
  account you have not connected.
- You can narrow or revoke any permission afterwards, and the worker keeps
  running with whatever is left.

### Public, private, and permanent

A published kit gets its own page and a permanent address for life, so an update
lands on the same URL rather than a new one and every link to it keeps working.
Kits can also stay private, on every plan including Free.

Anyone can publish one. Describe the job to the AI assistant you already use,
connected to the [WorkerKit MCP server](/build/mcp), and it writes the kit: it
picks the apps and the access each gets, writes the instruction, validates and
publishes. The [API and the CLI](/build) take the same steps.

### Worker kit vs Agent Skill vs AI plugin

This is the comparison most people arrive with, and the short version is that
they answer different questions:

| | What it is | What it needs to work |
| --- | --- | --- |
| [Agent Skill](/glossary/agent-skill) | Instructions that teach an agent a technique | An agent, and you, driving it |
| [AI plugin](/glossary/ai-plugin) | A bundle that installs capability into a client | That client, and you, driving it |
| Worker kit | A whole configured worker for one job | Your connected accounts. It runs itself |

A skill and a plugin extend an assistant **you** are using. A kit is a worker
that runs when you are not there. Each comparison has its own page:
[Agent Skill vs worker kit](/glossary/agent-skill) and
[AI plugin vs AI worker](/glossary/ai-plugin).

### Four real kits, and what each one shows

| Kit | Apps it uses | What the shape teaches |
| --- | --- | --- |
| [Support Inbox Triager](/kit/support-inbox-triager) | email, tasks | Write access earned by a narrow job: classify, prioritise, draft, file |
| [Meeting Prep Assistant](/kit/meeting-prep-assistant) | calendar, email, meetingNotes, crm | A four-app loadout, all reads, one output |
| [Appointment Reminder Texter](/kit/appointment-reminder-texter) | calendar, messaging | Outbound to real people, which is what [contact rules](/glossary/contact-rules) govern |
| [School Email to Calendar](/kit/school-email-to-calendar) | email, calendar | Open app slots: the kit names the surface, you pick the provider |

That last row is worth pausing on. A kit can leave an app **slot** open rather
than pinning a vendor, so the same kit works whether your mail is Gmail or
Outlook. You fill the slot when you take it.

### When a kit is not the right starting point

A kit is a shortcut to a **tested** instruction, and the shortcut stops paying in
four situations worth recognising early.

| Situation | Better move |
| --- | --- |
| The job is specific to your company | [Build your own](/build) as a [private kit](/glossary/private-kit) |
| You would edit most of the instruction | Write your own; a rewrite is slower than a draft |
| Its access request exceeds what you will grant | Narrow it, or pick another kit. Never grant to make a kit work |
| Nothing close exists | The job may not be repeatable enough yet |

The third row is the one to hold firmly. A kit asking for more access than your
version of the job needs is not a reason to widen the grant; the
[app firewall](/glossary/app-firewall) lets you refuse and see what the worker
still produces, and a kit that only works with sweeping access was probably built
for a broader job than yours.

A kit is also not the answer when the work itself should not be unattended: a
one-off task, an exact calculation, or anything whose mistakes are not
recoverable. Those are properties of the job rather than of the catalog, and no
kit fixes them.

When a kit is close but not exact, which is the common case, the answer is
usually neither of the extremes above. See
[when a kit is 80% of what you need](/blog/when-a-kit-is-eighty-percent-right).

### FAQ

#### Is a worker kit the same as a prompt template?

No. A prompt template is text you paste into a chat. A kit carries the
instruction plus the app permissions, the memories and the schedule,
and taking it creates a real [worker](/glossary/ai-worker) in
your account with its own key. Nothing about a prompt template runs on Tuesday
at 7am.

#### Does the kit's publisher get access to my accounts?

No. Taking a kit creates a worker in your own account, with its own key and only
the access you granted. A kit cannot reach an account you have not connected,
and you can narrow or revoke any permission afterwards with the worker still
running on what is left.

#### What happens when a publisher updates a kit?

A kit keeps its address for life, so an update lands on the same page rather
than a new URL and every link to it keeps working. Each kit page shows when it
was first published and when it was last updated.

#### Can I keep a kit private?

Yes, on every plan including Free. Private kits are not published to the
directory. Team plans can also share private kits across the team without
publishing them.

#### Can I build my own kit without code?

Yes. Describe the job in plain words to the AI assistant you already use,
connected to the [WorkerKit MCP server](/build/mcp), and it picks the apps and
the access each one gets, writes the instruction, then validates and publishes.
You write no code. Published kits get their own page and a permanent address.

#### Which models can run a kit?

Claude, ChatGPT, Gemini and Grok, because a kit brings the instructions rather
than the model. Per-model grades are not currently displayed on kit pages;
compare models on your own examples. See
[model agnostic](/glossary/model-agnostic).

## worker memory

URL: https://workerkit.ai/glossary/worker-memory
Also called: agent memory, persistent context, long-term memory
Updated: 2026-08-05

**What is AI worker memory?** Worker memory is the facts and rules an AI worker carries between runs, so it does not start every run knowing nothing about your business.

A chat assistant forgets when you close the tab. That is fine, because you are
there to re-explain. An [AI worker](/glossary/ai-worker) runs unattended, so
anything it needs to know has to survive between runs without you.

### Memory vs context vs the instruction

The three get conflated constantly, and they are different things:

| | What it is | Lifetime | Who writes it |
| --- | --- | --- | --- |
| The instruction | The standing brief for the job | The worker's life | The kit's publisher, then you |
| Context | What one run reads from your apps | One run | The run itself |
| Memory | Facts and rules carried forward | Across runs | You, and the worker |

The instruction says *what the job is*. Context is *today's material*. Memory is
*what this worker has learned about your particular situation* and is the only
one of the three that accumulates.

### What actually belongs in memory

The useful test: would a competent new hire need to be told this once, and then
remember it?

- **Your vocabulary.** That "the Q3 deck" means a specific document, that
  "escalate" means a particular Slack channel.
- **Standing exceptions.** This customer is on a bespoke SLA. This sender is
  always urgent despite the tone.
- **Decisions already made.** We do not offer refunds past 60 days. Legal
  reviews anything mentioning a competitor.
- **Corrections.** The thing you told it last month when it got something wrong.

What does not belong: anything that changes every run. The day's calendar is
context, not memory. Storing it as memory means a worker reasoning from a stale
copy of something it could simply have read.

### What each plan carries

| Plan | Memory |
| --- | --- |
| Free | Basic |
| Pro | Advanced |
| Team | Advanced |
| Enterprise | Advanced |

Basic memory is the rules and facts you give a worker. Advanced adds long-term
rules, facts and run history, which is the part that lets a worker refer back to
what it did previously rather than only to what it was told.

That distinction matters most for jobs with continuity across runs.
[Follow-Up Tracker](/kit/follow-up-tracker) reaches email and tasks to track
every thread you are waiting on and nudge when one goes quiet: knowing which
threads it already nudged, and when, is the difference between a useful worker
and one that sends a third reminder on Thursday.

### Memory is scoped to the worker

Each worker has its own key and its own access, and its memory is its own too.
That is a deliberate boundary rather than a limitation.

A support worker learning that a customer is difficult should not silently change
how a sales worker writes to them. Keeping memory per worker keeps the blast
radius of a wrong fact the same size as the blast radius of everything else about
that worker, which is what makes a fleet reasonable to run: one worker, one job,
one set of permissions, one set of beliefs.

The cost is that a fact relevant to three workers has to be told to three
workers. That is the right trade for the same reason narrow access is.

### The failure mode: a wrong fact, quietly

Memory's failure is not forgetting. It is **remembering something that stopped
being true.**

A worker told in March that a particular contact handles billing will still
believe it in September, after that person changed roles. Nothing errors. The
worker confidently routes to the wrong person, and it looks exactly like correct
behaviour, because from the worker's point of view it is.

This is the same plausible-failure shape that makes
[receipts](/glossary/run-receipt) matter elsewhere. A receipt showing what a run
did is how a stale belief becomes visible, since the output looks fine and only
the pattern across runs gives it away.

The practical mitigation is to treat memory as something with a review cadence
rather than an append-only log. Facts about people and process rot faster than
anyone expects.

### The reasonable objection

"Persistent memory across runs sounds like a privacy problem waiting to happen."

Reasonable, and it is why memory sits inside the same boundary as everything else
about the worker. It is scoped to one worker in your account, it is subject to
the same [app firewall](/glossary/app-firewall) that decides what the worker
could read in the first place, and [contact rules](/glossary/contact-rules) still
filter what reaches it. Memory does not widen access; it retains what the worker
was already permitted to see.

The sharper version of the objection stands though: anything a worker remembers
is something you have chosen to keep. Reviewing memory is a real operational
task, and a worker whose memory nobody reads is carrying assumptions nobody has
checked.

### When not to use memory

- **The fact is available from an app.** Read it. A CRM record is authoritative;
  a remembered copy is a fork that will drift.
- **The fact changes weekly.** That is context, and memory will be wrong more
  often than right.
- **It is genuinely sensitive and not needed.** The safest fact is the one not
  retained.
- **You are still evaluating the worker.** Add memory once the job is stable,
  or you will be debugging the instruction and the memory at once.

### FAQ

#### What is memory in an AI worker?

The facts and rules a worker keeps between runs, so it does not start each run
knowing nothing. It is distinct from the instruction, which is the standing brief
for the job, and from context, which is what a single run reads from your apps.

#### What is the difference between basic and advanced memory?

Basic memory is the rules and facts you give a worker. Advanced adds long-term
rules, facts and run history, so a worker can refer to what it did previously.
Free carries basic; Pro, Team and Enterprise carry advanced. See
[/pricing](/pricing).

Published WorkerKit plans and prices apply to shared cloud.

#### Do workers share memory with each other?

No. Memory is scoped to one worker, like its key and its app permissions. A fact
relevant to several workers has to be given to each, which keeps a wrong fact
from spreading across a fleet.

#### Can a worker remember something it should not?

It can only retain what it was permitted to read, since the
[app firewall](/glossary/app-firewall) and
[contact rules](/glossary/contact-rules) apply before anything reaches it.
Memory does not widen access, but it does retain, which is why reviewing it
periodically is a real operational task.

#### What should I not put in worker memory?

Anything authoritative in one of your apps, and anything that changes every run.
A CRM record should be read rather than remembered, because a remembered copy is
a fork that drifts and fails silently when it goes stale.

## worker schedule

URL: https://workerkit.ai/glossary/worker-schedule
Also called: agent schedule, cron for AI agents, recurring run
Updated: 2026-07-14

**What is an AI worker schedule?** A worker schedule is a standing instruction that runs an AI worker on a cadence in your own time zone, without anyone asking it to.

A schedule is the smallest thing separating an assistant from a
[worker](/glossary/ai-worker). Everything else can be identical; if nobody has
to start it, it is a worker.

### Schedule or trigger?

The two ways a worker starts, and the test is latency, not importance:

| | [Schedule](/glossary/worker-schedule) | [Webhook trigger](/glossary/webhook-trigger) |
| --- | --- | --- |
| Starts on | A clock | An event in another system |
| Good for | Digests, sweeps, reports, reviews | Reactions that must be fast |
| Latency | Up to one interval | Seconds |
| Cost when nothing happened | A run's worth of [tool calls](/glossary/tool-call) | Nothing, it never fired |
| Notices it was never called | Yes, it ran anyway | No |
| Real kit | [Engineering Pulse](/kit/engineering-pulse), a morning GitHub digest | [Inbound Lead Qualifier](/kit/inbound-lead-qualifier), fires when a lead lands |

Most serious workers want both: the trigger for speed, the schedule as the
safety net that catches whatever the trigger missed.

### Wall clock, not UTC drift

Schedules run in **your own time zone**, and that is a contract rather than a
convenience. A worker set for 8am runs at 8am after the clocks change, not at 7
or 9.

Systems that store schedules in UTC and convert on read get this wrong twice a
year, in a way nobody notices until a daily report starts landing an hour late
in March.

### What the plans allow

| Plan | Schedules per worker |
| --- | --- |
| Free | 1, hourly or daily |
| Pro | Unlimited, to the minute |
| Team | Unlimited, to the minute |
| Enterprise | Unlimited |

Two things worth pulling out. Free is genuinely useful rather than a demo: one
daily schedule is exactly what a first job needs. And **one-time "run once at"
schedules are not capped on any plan**, including Free, so scheduling a single
future run is never rationed.

### Choosing a cadence

The instinct is to run things often. Resist it: every run costs tool calls and
model tokens, and most jobs have a slower natural rhythm than they feel like
they do.

| Cadence | Fits | Real kit |
| --- | --- | --- |
| Weekly | Reports, hygiene passes, audits | [Weekly Ops Reporter](/kit/weekly-ops-reporter), [SEO Watchtower](/kit/seo-watchtower) |
| Daily | Digests, morning briefs, overnight triage | [Executive Daily Briefing](/kit/executive-daily-briefing) |
| Hourly | Queues needing attention within the working day | [Support Inbox Triager](/kit/support-inbox-triager) |
| To the minute | Alignment, not frequency: land output before a 9:00 standup | Pro and Team only |

Frequency is the multiplier on everything. A worker doing 8 tool calls once a
day is 8 a day; the same worker every minute is 4,800. If a job must react
within seconds of something happening, it does not want a schedule at all.

### Unattended is not unwatched

Every scheduled run leaves a [receipt](/glossary/run-receipt) showing what it
read, what it did, what it cost and what it skipped. Log history is 1 day on
Free, 30 days on Pro, 365 on Team.

A worker you cannot inspect is one you will eventually switch off. The receipt is
what makes a schedule something you can leave running.

### When a schedule is the wrong trigger

A clock is the default and it is not always the right one. Four cases where
something else fits better:

| The job | Why a schedule fits badly | Use instead |
| --- | --- | --- |
| React to an event within seconds | Any interval is too slow, and polling spends its budget finding nothing | A [webhook trigger](/glossary/webhook-trigger) |
| Answer a question when someone asks | There is nothing to check on a cadence | On demand, like [Company Knowledge Concierge](/kit/company-knowledge-concierge) |
| Do one thing at one future time | A standing cadence is the wrong shape | A one-time "run once at" schedule, uncapped on every plan |
| Poll faster than the cap allows | Every 15 minutes is 576 [tool calls](/glossary/tool-call) a day against Free's 500 | A trigger, or accept slower |

The last row is where the decision usually gets forced. Wanting lower latency
leads people to shorten the interval until it stops fitting the plan, at which
point the honest options are to find the event or to accept that the job runs
hourly.

There is also a case where nothing helps: if you cannot say what a run should do,
the cadence is not the problem. Fix the instruction first, because a schedule
only decides how often an unclear job runs unclearly.

### FAQ

#### Do WorkerKit schedules follow my time zone or UTC?

Your own time zone, on wall-clock time. A worker set for 8am runs at 8am through
daylight saving changes, rather than drifting by an hour twice a year.

#### How many schedules can one worker have?

Free allows one schedule per worker, hourly or daily. Pro and Team allow
unlimited schedules to the minute. One-time "run once at" schedules are not
capped on any plan, including Free.

#### Should I use a schedule or a webhook trigger?

Use a schedule when the job has a natural rhythm and "within the hour" is fine.
Use a [webhook trigger](/glossary/webhook-trigger) when the job is a reaction
that must happen within seconds. A minute-by-minute schedule is usually a
trigger nobody has wired yet: it burns tool calls all day finding nothing and
still reacts up to a minute late.

#### What happens to a schedule if my worker loses an app permission?

The worker keeps running with whatever access is left, and the receipt records
what it could not do. Permissions can be narrowed or switched off at any time
without stopping the worker, which is the point of the
[app firewall](/glossary/app-firewall).

#### Do scheduled runs cost more than on-demand runs?

No. A run costs the same however it started: its [tool calls](/glossary/tool-call)
against your plan's daily allowance, plus model tokens at provider list price
with no markup. Frequency is what changes the total, which is why cadence is
worth choosing deliberately.

## WorkerKit CLI

URL: https://workerkit.ai/glossary/workerkit-cli
Also called: wk, wk CLI, @workerkit/cli, WorkerKit command line
Updated: 2026-10-12

**What is the WorkerKit CLI?** The WorkerKit CLI is the open-source wk command-line tool for managing and running an account's AI workers and browsing the kit directory from the terminal.

The dashboard is one way to run a [worker fleet](/glossary/worker-fleet). This
is the other: a binary called `wk` that puts the whole fleet in your terminal,
your scripts and your CI, and reads the public kit directory without so much
as an account.

It is open source under MIT, published as
[@workerkit/cli on npm](https://www.npmjs.com/package/@workerkit/cli) and
developed at [github.com/workerkit/cli](https://github.com/workerkit/cli).

### Installing it

```
npm install -g @workerkit/cli
```

or, on Homebrew:

```
brew install workerkit/tap/wk
```

The npm package needs Node.js 22 or newer; the Homebrew formula brings its
own.

### What it covers

| Commands | What they cover |
| --- | --- |
| `wk workers` | The fleet: every worker with its live state, one worker in full, start and stop, what it may touch, its spend ceilings, and cloning it into new workers |
| `wk run`, `wk runs`, `wk fleet` | Trigger a run with a prompt for that run, watch it step by step, read the [receipt](/glossary/run-receipt), cancel or grade it; answer a run that ended by asking a question; the account-wide run feed, everything in flight, and the fleet ceiling. On a [decision-model](/glossary/system-one-model) worker `wk run` decides, acting on what it routes and returning the per-item decisions |
| `wk memory`, `wk instruction` | The rules and facts a worker carries into every run, and its standing instruction, versioned on every change with the history to roll back to. On a [decision-model](/glossary/system-one-model) worker `wk instruction get` reads the routing table with its install questions and `wk instruction set --answers` fills them |
| `wk schedules`, `wk deliveries` | When a worker starts on its own, in its own time zone, and where its run report goes when it finishes |
| `wk kit`, `wk publisher` | The public directory: search kits, read one in full, preview an install against your account, then install it as a new [worker](/glossary/ai-worker). And authoring: `wk kit tools`, `wk kit guide` and `wk kit vocabulary` say what a kit may grant, `wk kit validate` reports every gate at once, `wk kit publish --private` publishes one of your own, and `wk publisher` keeps your profile |
| `wk apps`, `wk model-keys`, `wk mcp-servers` | Which apps your operator can use and connecting the rest by credential (from a file, stdin or a hidden prompt, never a flag in shell history); your own model-provider keys; and registering an MCP server as your own custom MCP app when the platform does not offer the app |

The directory commands are anonymous by design: `wk kit search` works before
any sign-in, the same way the directory itself does, and so do `wk kit tools`,
`wk kit guide` and `wk kit vocabulary`, so a kit can be drafted before any key
exists. Publishing it privately and then `wk kit install` is how a worker is
created from scratch: a kit's permissions go through the same validators as a
directory listing, which is the platform's rule for permissions written by an
agent.

### Create a classifier from your questions

Run `wk decision sources --app email` and `wk decision guide` without signing in. Save the [request example](/api#decision-workers) as decision.json, then run `wk decision create --file decision.json`, or pipe the JSON on stdin. Creation needs `createWorkers`; optional `deploy:true` also needs `manageDeployments`. It creates a private kit and worker, never an initial run.

Recipes cover email previews, calendar events and Google Sheets rows. Reuse the same `requestId` with the identical body on retries. Use the returned `tokenId` with `wk deploy`, `wk run` and `wk instruction` to run and adjust the worker. A `deploymentError` leaves the worker available to deploy later. Read coverage, omissions and cost from the run receipt before claiming completion.

### Signing in

`wk auth login` runs a browser-approved sign-in. The CLI prints a short code,
an account admin enters it at workerkit.ai and chooses the key's scopes, and
the key lands in your OS keychain. The key itself never appears in the
browser, and the login link carries neither the code nor any secret.

The credential it creates is the same scoped access key the dashboard manages
under [/fleet-access](/fleet-access): per account, revocable at any time, and
holding no app credentials. Workers reach apps under their own grants; with
`readRuns` or `invokeActions` the key can read what those workers return,
including an Action worker's tool results.

### Built for scripts and agents

- `--json` prints a stable, machine-readable envelope, byte-faithful by
  contract, so a script can parse it without scraping human output.
- `--plain` strips the formatting for logs and agent transcripts.
- Exit codes are documented and distinguish auth, usage and server failures,
  so automation can branch on what actually went wrong.
- A `WK_MANAGER_KEY` environment variable carries the key in CI without
  touching a stored profile.

That makes the CLI the terminal half of
[AI worker fleet orchestration](/glossary/ai-worker-fleet-orchestration): the
same fleet an MCP client drives conversationally, driven from a shell instead.

### One definition, shared with the MCP server

Every command is generated from the same open-source tool definitions the
[WorkerKit MCP server](/glossary/workerkit-mcp-server) serves to AI agents,
published as [@workerkit/core](https://github.com/workerkit/core). One
definition per tool is what keeps the CLI, the MCP surface and the API from
drifting apart: a capability added to the platform arrives in all three at
once, behaving identically.

The CLI's product page is [/cli](/cli), the packages live at [/npm](/npm),
and the whole developer surface is summarised at [/developers](/developers).

### FAQ

#### What is the WorkerKit CLI?

It is `wk`, an open-source command-line tool that manages and runs an
account's AI workers (runs, schedules, memory, instructions, deliveries,
budgets, cloning), connects their apps, authors and publishes kits, and browses
the public kit directory from the terminal. It is MIT licensed and installs from
npm or Homebrew.

#### How do I install the wk CLI?

Either `npm install -g @workerkit/cli` (Node.js 22 or newer) or
`brew install workerkit/tap/wk`. Pick one channel and stay on it; both install
the same `wk` binary.

#### Can I use the CLI without an account?

Yes, for the public directory: `wk kit search`, `wk kit get` and their
siblings read the catalog anonymously. Managing a fleet needs a sign-in via
`wk auth login`, approved in the browser by an account admin.

#### Is the WorkerKit CLI open source?

Yes. The CLI and the core library it is built on are MIT licensed at
[github.com/workerkit/cli](https://github.com/workerkit/cli) and
[github.com/workerkit/core](https://github.com/workerkit/core), and npm
releases carry provenance attestations. The license covers the software; the
hosted service has its own terms.

#### Is the CLI different from the WorkerKit MCP server?

Same tools, different consumer. The CLI binds the tool definitions to shell
commands for people and scripts; the [MCP server](/glossary/workerkit-mcp-server)
serves the same definitions to AI agents over the Model Context Protocol. Use
whichever surface sits closer to where the work happens.

## WorkerKit MCP server

URL: https://workerkit.ai/glossary/workerkit-mcp-server
Also called: mcp.workerkit.ai, WorkerKit MCP, workers MCP server, WorkerKit remote MCP
Updated: 2026-10-12

**What is the WorkerKit MCP server?** The WorkerKit MCP server at mcp.workerkit.ai is a remote endpoint that lets any MCP client manage and run an account's AI workers, and search the kit directory.

[MCP](/glossary/mcp) is usually described from the worker's side: how a worker
reaches your apps. This is the other direction. It is how an AI client reaches
your **workers**, so the fleet becomes something a client can read, run and
maintain rather than something you open a browser to.

It is a hosted, remote server. Nothing is installed and nothing runs on your
machine.

The tools it serves are defined once, in the open-source
[@workerkit/core](https://github.com/workerkit/core) library, and the same
definitions drive the [WorkerKit CLI](/glossary/workerkit-cli), so the fleet
an agent orchestrates here and the one you script in a terminal can never
disagree. The server's product page is [/mcp](/mcp), and the whole developer
surface is summarised at [/developers](/developers).

### WorkerKit and Knowledge MCP

Connect to `https://mcp.workerkit.ai/workers` as **WorkerKit** for kit discovery
and fleet operations. Add the separate Knowledge MCP to read published reports.

| Endpoint | What it is | Auth |
| --- | --- | --- |
| `https://mcp.workerkit.ai/workers` | WorkerKit: manage workers, runs, schedules, budgets and app access; discover, install and author kits. Full profile or smaller decision profile | Sign-in required |
| `https://mcp.workerkit.ai/knowledge` | Company Knowledge: discover sources, search reports, read cited evidence and reconcile changes; admins can configure publication and reader grants | Same sign-in or key as WorkerKit |

### What the fleet endpoint can do

| Group | Tools | What it covers |
| --- | --- | --- |
| Key | `key_info` | What the presented 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`, `worker_delete` | Every worker with live run state, one worker in full including readiness, connected apps and 30-day activity, start or stop, delete, and what a worker may touch, read-only |
| Deployment | `worker_deploy`, `worker_undeploy`, `deployment_get`, `deployment_update`, `deployments_list` | Put a worker onto the hosted runtime and take it off, read one deployment, and change its model, reasoning, transcript retention, ceilings and pause state |
| 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, grade, or scrub a report a worker keeps carrying forward. On a [decision-model](/glossary/system-one-model) worker it decides instead: `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` | Every worker's runs in one account-wide feed, everything running right now, and one brief on what needs attention: blocked, never deployed, overdue, or waiting on an answer |
| 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, with its usage against every cap |
| Schedules | `schedules_list`, `schedule_create`, `schedule_update`, `schedule_delete`, `worker_timezone_set` | When a worker starts on its own, and the time zone it works in: its local dates, its report times and the clock its daily schedules follow |
| 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 |
| 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-model](/glossary/system-one-model) worker it reads the routing table and the install questions instead, and writes their answers |
| Budgets | `budget_get`, `budget_set`, `fleet_budget_get`, `fleet_budget_set`, `account_usage` | A worker's spend and run ceilings, the account-wide fleet ceiling, and what the account has left in slots, wallet and request windows |
| 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 |
| Kits | `kit_install_preview`, `kit_install` | Preview a directory kit's install form against your account, then install it as a new worker |
| Action workers | `action_worker_options`, `action_worker_create`, `worker_tools`, `worker_tool_call`, `worker_tool_invocation` | Selected app tools with no model: create the worker, list its tools, call one with exact inputs (a write takes an idempotency key) and read a write's receipt. Never deployed or 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 a client 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 | `models_list`, `model_keys_list`, `model_key_set`, `model_key_delete` | The models a worker can be given, and your own model-provider API keys, so runs bill your provider account instead of the wallet |
| 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 |

The workers endpoint also carries `workerkit_about` (what WorkerKit is and
when to use it, written for an agent and served one section at a time),
`directory_overview`, `kits_search`, `kit_get`, `publisher_get`,
and the three reads a kit is written from: `kit_app_tools` (every app and the
tools a worker gets on it), `kit_authoring_guide` and `kit_vocabulary`. These
discovery tools read the catalog. Installing a [kit](/glossary/worker-kit)
happens on the kit's page as a signed-in human, or through `kit_install` with
its own scope; publishing one takes `kit_publish`.

### Create a decision worker

Use the workers connection to discover `kit_app_tools(purpose:"decision")`, read `kit_authoring_guide(section:"decision")`, then call `decision_worker_create`. It creates a private kit and installed worker from typed questions; optional deployment never starts a run. Creation requires `createWorkers`, plus `manageDeployments` when deploying.

The initial recipes classify email previews, calendar events or Google Sheets rows without app writes. Check connections with `apps_list`. Reuse the same `requestId` and body on retries, follow the returned `nextCall`, and operate the returned `tokenId` through the existing run and instruction tools. Inspect receipt coverage, omissions and cost. [Request example and source limits](/api#decision-workers).

For a smaller list, send `X-WorkerKit-Profile: decision` consistently on every workers request, including initialization and listing. This selects a smaller set of workflow tools on the same endpoint with the same authentication. Server operators can set `MCP_WORKERS_PROFILE=decision` instead. Full remains the default profile; publishing, Action workers and broader fleet administration use that profile. Reconnect and relist after changing profiles. Successful MCP responses include structured content and a text fallback.

### Call an Action worker

An Action worker (`modelType: "none"`) has no model: it exposes selected app tools that you call one at a time with exact inputs, under the worker's own app access. On the full profile, `action_worker_options` lists apps and tools, `action_worker_create` creates the worker, `worker_tools` lists its tools, and `worker_tool_call` calls one (the `invokeActions` scope, which also covers `worker_tool_invocation` for a write's receipt). A write takes an idempotency key; never resend a call whose status is `outcome_unknown`. It is never deployed or run. [Call examples](/api#action-workers).

### The one tool worth understanding first

`worker_run` takes an optional **prompt for this run**. Omit it and the worker
does its standing job. Supply it and the worker does its job *about that
subject*, with its method, its permissions and its memory unchanged.

That is what turns a fleet into something a client can compose with: the same
research worker can be pointed at fifty accounts in an afternoon, and every one
of those runs is done the way the worker was built to do it. The pattern has its
own page, [AI worker fleet orchestration](/glossary/ai-worker-fleet-orchestration).

### How to set it up

**Use the OAuth flow if your client supports it.** It is fewer steps, and no raw
credential is ever pasted into a config file or a chat window.

1. Add `https://mcp.workerkit.ai/workers` to your client as a remote MCP server.
   In clients with a connector UI this is "add a custom connector" and the URL.
   In Claude Code it is one line:

```
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers
```

2. Connect. The client discovers the sign-in flow from the server and opens the
   WorkerKit consent page at `workerkit.ai/mcpauth`.

3. On that page, sign in with Google or Microsoft, then pick the access key the
   client should use, or create one there and then, and approve. The client's reach
   is exactly that key's scopes, and the page says so before you approve.

4. Back in the client, ask it to list your workers. If it names them, you are
   connected.

Only an **account admin** can complete step 3, because access keys are an
admin-only surface. A member who follows the flow sees a notice saying so rather
than a broken page.

#### If your client does not do OAuth

Create a key yourself at [/fleet-access](/fleet-access) and send it as a bearer
header. The key is shown once, at creation, and never again:

```
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers \
  --header "Authorization: Bearer pe_mgr_..."
```

Both routes end at the same place. A key added by hand keeps working after you
later switch to OAuth.

#### Add the Knowledge MCP for published reports

The Knowledge MCP is a separate connection at
`https://mcp.workerkit.ai/knowledge`, using the same sign-in or manager key.
Name this connection **WorkerKit Knowledge**:

```
claude mcp add --transport http workerkit-knowledge https://mcp.workerkit.ai/knowledge
```

It carries `knowledge_sources`, `knowledge_search`, `knowledge_get` and
`knowledge_changes`; admins can also configure publication and reader grants.

### Choosing what the client may do

An access key carries scopes, and a client can never exceed them. A refusal names
the scope it wanted, so nothing fails mysteriously.

| Scope | What it unlocks |
| --- | --- |
| `readWorkers` | See the fleet: which workers exist, their state, their readiness |
| `readRuns` | Read run history, receipts, live step feeds, and the reports workers wrote |
| `runWorkers` | Trigger a run now, and cancel one |
| `invokeActions` | Call an Action worker's tools and read the receipts of its writes |
| `manageMemory` | Add, edit and retire a worker's rules and facts, grade runs, scrub a report |
| `manageSchedules` | Create, edit and delete schedules, and set a worker's own time zone |
| `manageInstructions` | Rewrite a worker's standing instruction |
| `manageState` | Start and stop workers |
| `installKits` | Install a directory kit as a new worker (the worker's own key is shown once in the response) |
| `manageDeliveries` | Create, edit and delete the destinations a run report is sent to |
| `manageBudgets` | Read and change a worker's spend and run ceilings, and the fleet ceiling |
| `createWorkers` | Create an Action or decision worker from scratch, and clone a worker into new ones; a clone carries only permissions a person already approved |
| `publishKits` | Author kits: validate, publish, edit, unlist and delete, and keep the publisher profile |
| `manageConnections` | Connect and disconnect apps by credential, register your own MCP servers, and set or remove your model-provider keys |
| `manageDeployments` | Put a worker on the hosted runtime and manage that deployment; without it an installed worker never runs |
| `deleteWorkers` | Delete a worker permanently, with its sub-workers |
| `readWallet` | Read the wallet balance, fees and checkout status |
| `requestWalletTopUp` | Create a checkout link a person confirms and pays |
| `discoverAppResources` | Read private setup metadata such as GitHub repositories and Slack conversations, never their content |

A sound progression, and the one worth actually following:

- **First key: `readWorkers` and `readRuns`.** The client can describe the fleet
  and everything it has done, and change nothing. Most of the value of the first
  session is here.
- **Then add `runWorkers`.** Now it can do work. This is the step where the
  server turns into [AI worker fleet orchestration](/glossary/ai-worker-fleet-orchestration)
  rather than a read-only view.
- **Add the manage scopes deliberately.** `manageInstructions` lets a client
  rewrite the tested method of a worker, which is the largest of these and the
  one to withhold longest.
- **`publishKits` and `manageConnections` are the building scopes.** With them
  a client can write a kit from the public guide, validate it, publish it
  privately and install it as a new worker; connect the apps it needs by
  credential; and, when the platform does not offer an app, register that
  app's MCP server as your own custom MCP app. Every credential is checked
  live and stored encrypted, and no read ever returns one.

Keys are per account, revocable, optionally expiring, and an account holds up to
ten active at once. Giving a client its own key rather than sharing one is what
makes revoking it later a decision with no side effects.

### Use cases

**Ask the fleet a question in plain language.** "Which workers have not produced
a successful run this week, and why?" is one prompt against `workers_list` and
`worker_runs`, instead of opening every worker's page.

**Run something out of cadence.** A worker built from the
[Executive daily briefing](/kit/executive-daily-briefing) kit runs at 07:00, it
is now 15:00, and something changed. Ask the client to run it with a prompt
naming what changed.

**Debug a run without leaving the editor.** `run_events` replays a run's steps in
order with timings and outcomes, so "why did that take nine minutes" is
answerable where you already are.

**Keep memory honest.** A worker carrying a fact that stopped being true drifts
quietly. A client can read the memory, spot the stale item and retire it, which
keeps provenance rather than deleting history.

**Set up a schedule by describing it.** "Every weekday at 8am in America/Chicago"
becomes a schedule without anyone translating it into fields.

**Research what to build next.** On the workers endpoint, the client searches the
directory for a kit that already does the job, reads its permissions manifest and
its instruction, and hands you the install link.

### What it is not

- **It is not access to your apps.** A fleet key holds no app credentials. Only
  workers reach apps, under their own [app firewall](/glossary/app-firewall),
  [contact rules](/glossary/contact-rules) and
  [redaction](/glossary/redaction), and a run prompt cannot widen any of them.
  Run results (with `readRuns`) and an Action worker's tool results (with
  `invokeActions`) can include data from those apps.
- **It is not an anonymous way to install kits.** Discovery tools only
  read. Installing takes a signed-in human on the kit's page, or the fleet
  endpoint's `kit_install` behind its own opt-in scope.
- **It is not a place where your data sits.** The server holds no state, no
  sessions and no secrets. It forwards a request, returns the answer, and
  forgets.
- **It is not a second permission model.** MCP connects; it does not restrain.
  Every limit that applies to a worker on a schedule applies identically to a
  worker a client just triggered.

### Manners that keep a session healthy

Worth telling a client once, because these are the things that turn a working
session into a throttled one:

| Situation | The right behaviour |
| --- | --- |
| Watching a run | Poll its events every 3 to 5 seconds, never in a tight loop |
| A run comes back "skipped" | That is a receipt with a reason on it, not an error. Report the reason |
| A refusal naming a scope | The key is too narrow. An admin issues a wider key; retrying will not help |
| A rate limit | Back off for the time the response asks for |

The budgets are generous and are counted **per account**, so other people using
the same hosted server never affect you: 120 requests a minute across the
surface, 30 run triggers a minute, and a separate allowance for watching runs
that is sized for exactly the poll spacing above.

### FAQ

#### What is the WorkerKit MCP server?

It is a hosted MCP server for managing [AI workers](/glossary/ai-worker) and
discovering kits. Connect as **WorkerKit** at `https://mcp.workerkit.ai/workers`.
The separate Knowledge MCP at `https://mcp.workerkit.ai/knowledge` searches and
reads published worker reports with the same sign-in or key.

#### How do I connect Claude to my WorkerKit workers?

Add `https://mcp.workerkit.ai/workers` to the client as a remote MCP server, then
connect. The client sends you to workerkit.ai/mcpauth, where you sign in, choose
or create an access key, and approve. An account admin has to complete that step.
Clients without OAuth support can send a key created at
[/fleet-access](/fleet-access) as a bearer header instead.

#### Can an MCP client read my email or CRM through this?

Only through workers you set up. The key holds no app credentials, but run
results (with `readRuns`) and an Action worker's tool results (with
`invokeActions`) can include data from the apps that worker was granted. Choose
the worker's app access and the key's scopes together.

#### Do I need a paid plan to use the WorkerKit MCP server?

No. The connection itself is not a paid feature. What a client triggers is
metered like any other run: [tool calls](/glossary/tool-call) count against your
daily allowance, and model tokens are billed at provider list price with no
markup.

#### What can a client actually change?

Exactly what the access key's scopes allow, and nothing more. A read-only key
lets a client describe your fleet and its history without touching anything.
Running, memory, schedules, instructions and start/stop are each a separate
scope, so you decide how far the client's reach goes and can revoke it at any
time.

#### Is there an MCP server for creating kits?

Yes. The WorkerKit connection at `https://mcp.workerkit.ai/workers` includes
`kit_validate`, `kit_publish` and `kit_install`, so a client can author a kit,
publish it privately and install it as a new worker with the required scopes.

## Notes for AI agents

- The rendered glossary is at https://workerkit.ai/glossary.
- Long-form writing on these ideas is indexed at https://workerkit.ai/blog.md.
- Product overview: https://workerkit.ai/about.md. Pricing: https://workerkit.ai/pricing.md. Every public kit: https://workerkit.ai/kits.md. Crawler index: https://workerkit.ai/llms.txt.