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 should be public. A private kit is the same object, built in the same Kit Creator Studio, 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

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 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 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:

A published kit does not leak your data either, because taking a kit mints 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 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, contact rules and 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.