WorkerKitFrom AI tools to an AI workforce
Build an AI workforce around jobs your company keeps, with a shared method, clear ownership, app permissions and a record of each run.
By Adam Shamos. Updated .
Moving from AI tools to an AI workforce means giving useful jobs a lasting home in the company. Each AI worker keeps the method, authorized access and run history for its job, so the team can call on it again without reconstructing one person's setup.
The change is an operating decision: which jobs should the company be able to carry out, who owns the result, and what authority does each job need?
What changes when the company keeps the worker?
A helpful result in a conversation can become a method worth keeping. The next step is to decide how that method will operate when different people need it, when its owner is away, or when an event starts the work.
| Question | What to establish for a company worker |
|---|---|
| What job does it do? | A bounded outcome and the criteria for accepting it |
| How does it do the job? | Reusable instructions or decision rules in a worker kit |
| What may it touch? | The connected apps and actions the job needs |
| When does it work? | On demand, on a supported event or on a stated schedule |
| What happens when it is unsure? | A defined exception path and a responsible person |
| How will you inspect it? | Results and a run record, checked against the job's criteria |
| Who can change the method? | A named owner and a process for reviewing changes |
These questions apply even if your existing assistant already runs background jobs. Scheduling alone does not decide whether you need another product. Check whether your current arrangement supplies the ownership, access boundaries and records your company needs at a reasonable operating cost.
In WorkerKit, the worker kit is the reusable definition you install. The worker is the configured agent in your account. The workforce is the collection of workers your team runs, and a workflow is the process they carry out together. Keeping those units distinct makes it easier to decide what to share, what to connect and what to improve.
First worker: preserve a useful method
Start with a job whose result you can judge. The Inbound Lead Qualifier reads an inquiry and the CRM, grades the lead against a scoring rubric, creates or updates the contact, logs its reasoning and saves a reply draft. It supports an inbound event or an on-demand request. Its email permissions include creating drafts, without sending the customer reply.
The reusable part is more than the draft. It includes how the worker checks for an existing contact, what evidence supports the grade, when it leaves a field blank and which ambiguous records need the sales owner to decide.
Before enabling the job, agree on a short acceptance rule: the contact is the right person, the grade cites the inquiry or existing CRM information, and the draft answers the inquiry without inventing company facts. A well-written draft attached to the wrong contact fails the job.
Name a sales owner who reviews those outcomes and a person who can repair the configuration when the job stops working. These are responsibilities for your team to assign; installing a kit does not decide them for you. Configure result delivery so the owner receives the output where they will review it.
The inbound sales setup guide covers the job in practical steps. The adoption decision is simpler: keep this worker when its useful results justify its setup, review and operating effort.
Persistence is independent of frequency
A worker can remain ready between requests without running continuously. A worker scheduled twice a day runs twice a day. A worker used for an occasional investigation can keep its instructions and authorized access between those investigations. An event-driven worker starts when the supported event arrives.
That distinction matters when assessing valuable work with irregular demand. Frequency affects cost and response time, but it is not the sole test of value. A company may want a prepared method available for an infrequent, substantial job. It should still compare the effort of maintaining that worker with the effort of doing the work directly.
Memory also needs a purpose. Decide which facts should carry into later runs and when they become stale. Keeping a worker does not make every remembered fact permanent truth, and retaining instructions does not mean the worker is always watching your apps.
Connected workers: make each handoff explicit
Connect workers when a larger process has distinct jobs with different access, quality criteria or costs. A decision worker can classify incoming items, a language worker can research or write, and an Action worker can perform a specified app operation without a model. The division should clarify the work, rather than merely increase the number of workers.
Write down each handoff before expanding the process:
| Handoff detail | What to settle |
|---|---|
| Input | Which record, facts and decision the next worker receives |
| Acceptance | What makes the upstream result usable by the next job |
| Authority | Which worker is allowed to change which application |
| Exception | Where an incomplete or uncertain item goes |
| Repeated work | How you identify an item that was already handled |
| Completion | Who checks that the whole business outcome was achieved |
An Action worker's exact inputs still need checking. If its caller supplies the wrong contact identifier, a permitted update can still change the wrong contact. Similarly, a successful classification does not prove that the following reply is accurate. Review the output of the whole process as well as the individual runs.
You can start from a coordinating kit that installs with its supporting kits as a connected group. Review the actual workers and their permissions in that installation. A workforce is not a single package with unlimited authority.
Company workforce: share methods and accountability
Expansion across teams introduces a different problem: several people depend on a method, so changes need an owner. Reps can install the same kit with their own accounts and grants, or reach a shared worker through authorized access. Those are different arrangements. Separate installations retain separate configuration; shared access needs an explicit decision about who may use the worker and for what.
Keep a small operating record for each job: its business owner, accepted outcome, app access, spending limits, review cadence and exception destination. Use the run receipt to investigate what a run read, changed, was refused and cost. Pair that evidence with the owner's judgement of the result. A receipt is a record of execution, not proof that the business decision was right.
When a kit improves, installed workers can take the update. Decide when to apply it and recheck the affected job on representative work. Where learning is enabled for language workers, instruction changes can be tested against reviewed runs and applied with approval or within the configured proven-changes mode. That improves instructions for future runs; it does not train the underlying model. Memory has separate controls.
Keep intelligence and authority separate
Model choice answers which intelligence suits the job. Authority answers what the company allows that job to do. WorkerKit lets you choose among supported models while keeping the worker's method, app grants, limits and records in the company account.
Changing the model still warrants checking the results. A different model can interpret the same instructions differently, and a starting model selection is not a guarantee of quality on your work. Use the model comparison process on the cases that matter to your team.
Similarly, permission to write is a real permission. A job designed to prepare a draft leaves the send to a person; that is different from a platform policy that holds every write for approval. Pausing a worker prevents further work under its pause control, but does not undo actions already completed. Grant the app access the job needs with those consequences in mind.
When your existing tools are enough
Adding WorkerKit is difficult to justify if your current assistant and automation system already provide useful results, appropriate app access, reliable handoffs and records at a lower total operating cost. Keeping a working arrangement can be the right decision.
The same applies when nobody owns the process, the team cannot agree on a good result, or maintaining a persistent configuration costs more than doing the work. More workers will not settle an unresolved operating decision.
Evaluate one bounded job using cost per acceptable AI result. Include the time people spend reviewing, correcting and maintaining it. Expand when the evidence supports expansion, with connected workers and then a company workforce as the work demands.
For a company-wide buying decision, use the enterprise AI automation blueprint to define the process and the platform evaluation worksheet to collect evidence from operations, engineering, security and budget owners.
FAQ
Does an AI workforce replace the people responsible for the work?
An AI workforce carries out configured jobs, while people remain responsible for deciding the job, granting access and judging whether its results are useful. A sales owner still owns the qualification rubric and customer reply even when a worker prepares the record and draft.
Do workers have to run on a schedule?
Workers can run on demand, on supported events or on schedules. Persistence means the configuration remains available between runs; it does not mean continuous execution or an obligation to repeat a completed job.
Can the team share one worker?
Authorized people and agents can reach a shared WorkerKit worker through scoped access. Another option is to install the same kit into separate workers with their own app grants. Choose based on who should use the job and which accounts it should reach.
How do we start building a workforce?
Browse the kit directory and choose a job with an outcome you can evaluate. WorkerKit is in early access and accounts open by invitation through the waitlist. Once invited, connect the required agent and apps, review the kit's access and limits, and evaluate the first worker before expanding. Current plans and usage rates are on pricing.