What an unattended AI fleet needs to fail well
Unattended agents fail plausibly rather than loudly. Five design choices decide whether a bad run costs an hour or a quarter, and none is model quality.
Most writing about AI agents is about making them work. This is about what happens when they do not, which is the part that decides whether you keep them running.
The premise worth starting from: **an unattended agent does not fail like software.** Software throws, stops, and turns something red. An AI worker produces a reasonable-looking output that is wrong, and nothing is red at all.
Two failure shapes
| Traditional job | Unattended AI worker | |
|---|---|---|
| Typical failure | Exception, exit code | Plausible wrong output |
| Visibility | Loud, immediate | Silent, discovered later |
| Reproducible | Yes | Not exactly |
| Detected by | Monitoring | Someone reading the work |
| Blast radius | The job | Every run since it started drifting |
The bottom-right cell is the one that costs money. A cron job that broke on Tuesday broke on Tuesday. A worker that started misclassifying on Tuesday has been confidently misclassifying ever since, and the first signal is usually a person asking why a customer got the wrong reply.
Five choices that decide the cost
None of them is "use a better model". They are all about what the system does around the model.
1. Reserve before run, not during
A run should reserve its token budget before it starts. If the balance will not cover it, the run is skipped and the reason is recorded.
The alternative, discovering mid-run that funds ran out, leaves work half finished: some tickets filed, some drafts written, no record of where it stopped. Somebody reconstructs it by hand.
For anything unattended, predictable refusal beats partial success. A skipped run leaves the world exactly as it was.
2. Hard caps, not soft ones
At the daily tool call cap a worker should stop until the counter resets, then resume. Nothing deleted, no settings changed.
Soft caps feel friendlier and are worse. A confused worker that loops on a soft cap produces an invoice you find at month end. On a hard cap it produces a paused worker and a receipt explaining why, and you learn the same day.
WorkerKit's caps are hard: 500 a day on Free, 5,000 on Pro, 50,000 pooled on Team.
3. Skips recorded, never swallowed
Every reason a run did not happen has to appear somewhere: an insufficient balance, a cap reached, a model unavailable.
A silent skip is the worst outcome available, because **it is indistinguishable from success**. The queue looks handled. The digest simply did not arrive and nobody noticed for a week.
4. Degrade on revoked access, do not die
When a permission is narrowed or removed, the worker should keep running with whatever is left and record what it could not do.
This sounds like a small ergonomic detail and it changes behaviour. Systems that treat revocation as fatal teach people never to revoke anything, so permissions only ever widen. A worker that degrades makes tightening access a reversible, low-stakes decision, which means it actually gets done.
5. A receipt per run
What it read, what it did, what it cost, what it skipped. Not because you will read them all, but because the question after a surprise is always "what did it actually do", and without a record the honest answer is that nobody knows.
What this costs, concretely
The counter-argument to all of this is that safety machinery is overhead. Here is the actual arithmetic for a five-worker fleet on hourly schedules across a ten hour day:
| Runs a month | Notes | |
|---|---|---|
| Per worker | ~300 | 10 a day |
| Fleet of 5 | ~1,500 | Within Free's 5 workers |
| Runs you will actually read receipts for | ~20 | The first week, then on surprises |
| Runs a hard cap might pause | 0 in normal operation | It is a backstop, not a throttle |
The overhead is close to zero in the good case. It is entirely a question of what the bad case costs, which is why it is worth deciding before the bad case rather than during it.
A worked example
Invoice Follow-up Assistant reaches email and Drive to chase overdue invoices with escalating reminder drafts. It touches money and customers, which makes it a good test of every choice above.
Suppose the wallet empties mid-month.
- With reserve-before-run: the next run is skipped, the receipt says "insufficient balance", no customer is contacted, and topping up resumes normal service. You find out from the receipt, or from a chased invoice not going out.
- Without it: a run starts, drafts two of five reminders, and stops. Two customers are chased, three are not, and there is no record distinguishing them from the ones that were deliberately skipped.
The second version is not a crash. It is worse than a crash, because it looks like it worked.
The reasonable objection
"This is a lot of ceremony for something that mostly works. Ship it and watch."
Watching is the right instinct and it does not scale past about one worker. The whole proposition of an unattended fleet is that nobody is watching, so "watch it" is a plan that quietly expires the moment the fleet is useful.
The narrower version of the objection is fairer: do not build this machinery yourself for one worker. That is a real argument for using a platform that has it rather than for going without, which is the same conclusion from the other direction.
When you do not need any of this
- The job is read-only and its output is advisory. A digest that is wrong is a digest you ignore.
- You are still evaluating. Run it on demand, read every output, and decide whether the job is real before automating its failure modes.
- Volume is tiny. Ten runs a month does not have a tail worth engineering for.
The machinery earns its place when the worker acts on your accounts, runs often enough that you cannot read every run, and its mistakes reach someone outside your team. That is roughly the point where a fleet stops being a demo.
FAQ
How do AI agents fail differently from normal software?
Software fails loudly and deterministically: an exception, an exit code, something red. An unattended agent usually fails plausibly, producing reasonable-looking output that is wrong, so failures are discovered by a person reading the work rather than by monitoring.
What happens if my worker runs out of credit mid-schedule?
On WorkerKit each run reserves its budget before starting, so an insufficient balance skips the run and records the reason on the receipt rather than leaving work half finished. Top up and the next due run proceeds normally.
Are daily limits on AI workers a good thing?
For unattended work, yes. A hard cap turns a runaway loop into a paused worker and a receipt you see the same day, where a soft cap turns it into an invoice you find at month end. WorkerKit's caps are hard on every plan.
What happens if I remove an app permission from a running worker?
It keeps running with whatever access is left and records on its receipt what it could not do. That matters because systems treating revocation as fatal teach people never to tighten permissions, so access only ever widens.
How do I know an unattended worker is still doing its job correctly?
Read receipts, especially early. A receipt shows what a run read, did, cost and skipped, which is what turns a surprising outcome into a diagnosis. Retention is 1 day on Free, 30 days on Pro and 365 on Team. See /pricing.