A managed runtime for unattended AI jobs

An unattended AI worker is not a model deployment, it is a job deployment. What a managed runtime standardizes is everything that job needs to keep running.

Every demo of an AI agent has the same shape: a person at a keyboard, an impressive result, an audience watching. I have given that demo more times than I can count. It is a good demo. It is also nothing like the thing people actually want, which is for the work to happen while nobody is watching at all.

The gap between those two is not intelligence. For a long list of ordinary jobs, the models cleared the intelligence bar a while ago. The gap is that supervising an agent is itself a job, and the entire point was to stop doing the job.

So here is the thesis WorkerKit is built on. **An unattended AI worker is not a model deployment. It is a job deployment.** The model is the smallest, most swappable part of it. Everything else, the access and the schedule and the limits and the record of what happened, is what the job needs in order to keep running after you stop watching it, and that is the part we standardized.

The part that is never in the demo

Take a job so small it barely deserves the word: every morning at seven, read the unread email, look at today's calendar, and put a short briefing where its owner will see it. An AI worker does this well. Executive Daily Briefing is this job, written down as a worker kit.

Now count what has to exist for it to run without you.

Something has to stay connected to email and calendar, because there is no browser session at seven to borrow. Something has to decide what the worker may do with that access, which is a different question from what it can do. Something has to keep credentials out of the instruction text, fire on time in your timezone, survive the model provider having a bad morning, write down what happened, tell you when it breaks, and keep doing all of it next month, after you have forgotten how any of it works.

None of that is the agent. All of it decides whether the agent survives contact with an ordinary Tuesday.

Here is the whole list, because seeing it in one place is the argument:

Fourteen rows. One of them is the demo.

The list does not change with the job

The observation that made WorkerKit feel inevitable to me: this list is the same for every job. The morning briefing, a lead qualifier working a CRM, an invoice chaser: different instructions, different apps, the same fourteen rows. And most teams meet the rows one at a time, each one disguised as a bug. The credentials expired. The schedule fired at three in the morning because the server thinks in UTC. Nobody noticed that Tuesday's run never happened, until Thursday.

Runtimes are not the scarce part anymore

A year or two ago the argument would have stopped there, with a comfortable contrast between a framework you assemble yourself and a platform that runs things for you. That argument has expired. Managed agent runtimes are an established category now: you can rent execution, scheduling, retries and tracing from several credible vendors, and you should not build any of that yourself.

So the useful question is no longer whether a runtime is managed. It is what the runtime is opinionated about.

A generic agent runtime is infrastructure for deploying arbitrary agents. It is excellent at that, and the unit it deploys is code: you write the agent, it runs the agent, and everything specific to your job lives inside what you wrote. Which means the app connections, the permission model, the approval step and the audit trail are yours again, only now they live in a repository instead of on a server.

WorkerKit is opinionated about something narrower: unattended jobs. The unit it deploys is a job, not a program. You do not write agent code, and there is no build step, no repository and no deploy: you write instructions, grant the apps the job needs at the access levels it needs, set a schedule, and the platform operates the rest. The model is not part of the deployment either. Workers are model agnostic, so the model is a choice you make per worker and change later, not a decision baked into a deployment.

The row I care about most is per-job permissions, because of a second-order effect that is easy to miss. Access control that is annoying to change is access control that only ever widens. When narrowing a worker's permissions is a thirty-second edit, and the worker degrades instead of dying when you make it, people actually narrow. Security that depends on someone doing the annoying thing is not security.

What "managed" means on a bad day

Anything can run an agent on a good day. A runtime earns its keep on the other days, which is where most of our design time has gone.

A run reserves its budget from the wallet before it starts, so an empty balance produces a skipped run and a recorded reason, never half the invoices chased with no note of which half. Tool calls stop at a hard daily cap, so a worker stuck in a loop becomes a paused worker the same day rather than a surprise at month end. Every run leaves a receipt: what it read, what it did, what it cost, what it skipped. And when a model is unavailable or a permission has been revoked, the run is skipped or degraded and written down, because a silent skip is indistinguishable from success, and that is the worst property an unattended system can have.

None of this machinery is exciting, which is rather the point. The part of a system that reaches into your inbox at seven in the morning should be the most boring thing you own.

Where a person stays in the loop

Unattended does not mean unaccountable, and it should not mean the worker gets the last word on anything that matters. Permissions split reading from writing, per app, and the app firewall narrows what a worker may touch inside the apps it holds. So the pattern I push for consequential work is: let the worker read, sort, decide and draft, and leave the sending to a person. A worker that prepares replies it cannot send still saves you the hour. It just does not spend your reputation without asking.

The clock-shaped jobs run on schedules; the event-shaped ones start from webhook triggers; both leave the same receipts and hit the same caps. And what a worker carries between runs is memory you can open, edit and wipe, because "it remembers things about my business" should be a feature you can read, not an ambient property you discover later.

Why a job is installable and a deployment is not

Deploying a job rather than a program has a consequence I did not fully appreciate until we had a few hundred of them: the job becomes portable.

A worker kit is the whole job written down. The instructions, the exact app permissions it needs, the schedule it expects. It carries no code, no dependencies and no infrastructure assumptions, so installing one creates a worker in your account with those permissions and nothing more, running on the same runtime as everybody else's workers. That is why somebody else's job is something you can install in a minute rather than something you read for ideas and rebuild.

Nobody installs a stranger's agent deployment. There is no reason they would: it assumes their infrastructure, their secrets, their model account and their code. A job assumes a runtime that is standard everywhere it lands. So the directory of kits WorkerKit opens on is downstream of the runtime, not the reason for it. Publish a kit against a runtime nobody shares and you have published a README.

What this does not solve

A managed runtime does not turn a vague job into a good one. A worker with mushy instructions produces confident, plausible, wrong work, on schedule, which is worse than not running it at all. The runtime makes that failure visible and cheap to catch; writing an instruction that holds is still your work, and it is real work.

It is also the wrong tool for a genuinely strange job. Being opinionated about jobs is what buys everything above, and the bill for it is arbitrary control flow: if the work needs a custom loop, a bespoke tool you wrote this week or a model call in the middle of your own pipeline, you want a framework or a generic runtime, and no amount of instruction text is a substitute for code. The line is not how hard the job is. It is whether the job is a job or a program.

It does not argue that everything should be unattended, either. My private test: if you would not hand the job to a capable temp with a written brief and a scoped login, do not hand it to a worker either.

And it is not free. Runs meter model usage against the wallet, and every plan caps tool calls per day; pricing has the numbers. I consider the caps part of the product. A ceiling you chose in advance is the difference between a bad day and a bad month.

FAQ

What is a managed runtime for AI workers?

It is the layer that operates an AI worker for you: it holds app access and secrets, enforces permissions, starts runs from schedules or webhooks, executes the run, handles retries and failures, records a receipt, sends run notifications and keeps state and memory between runs. On WorkerKit this layer is the platform itself, so you define the job and the runtime operates it.

How is WorkerKit different from a generic agent runtime?

A generic runtime deploys arbitrary agents, so the unit you give it is code and everything job-specific stays yours: app connections, the permission model, the approval step, the audit trail. WorkerKit is opinionated about unattended jobs, so the unit you give it is a job, and app access, per-app permissions, schedules, receipts and spending limits are part of the platform rather than part of your program.

Do I have to write agent code to run an unattended job?

Not on WorkerKit. A job is instructions plus the apps it may reach plus when it runs, so there is no repository, build step or deployment. Installing a kit creates a worker in your account with exactly the permissions the kit declares, and you can edit any of it afterwards.

Which model does an unattended worker run on?

Whichever you choose for that worker. Workers are model agnostic, so the model is set per worker and can be switched later without rewriting the job, and a worker with its own provider key can run on that instead of the wallet.

Can a person stay in the loop for risky actions?

Yes, and for consequential work they should. Permissions are per app and split between read and write, so a common shape is a worker that reads, sorts and drafts but cannot send, leaving the final step to a person. The receipt and the run notification then show exactly what was prepared and why.

What happens when a run fails overnight?

It is recorded, not swallowed. The run's receipt says what was read, done and skipped, and why; a run notification tells you it happened. An empty wallet skips the run before it starts, a revoked permission degrades the run rather than killing the worker, and hard daily caps stop a runaway loop the same day.