Nobody watches the agent that runs at 3 a.m.

The person who set it up, and that answer has to carry an unpleasant consequence or it means nothing: the task stops when that person leaves. A scheduled run is the one case where an agent acts without anybody asking it to, and that is exactly what makes it hard to govern.

We argue elsewhere that an agent acts with the requester’s rights and never with its own, because giving it an identity of its own creates a path around every permission you have set. The scheduled task is the hole in that rule, and we say so rather than hide it: at 3 a.m. there is no requester. Attaching the run to whoever created the routine is the least bad option available, and it is only honest if you accept what it implies the day that person leaves.

What separates a scheduled task from a conversation?

Three things vanish at once, and they do not get replaced separately.

The requester first, and with them the attachment of rights. Then the context: in a conversation the agent knows why it is being asked, whereas a routine starts from a time and a condition. And finally the witness, the person who would have seen an absurd answer go past and flagged it within the second.

That last loss is the most underrated. In conversational use, human review is free and constant: it is written down nowhere, nobody calls it a control, and it still catches most of what matters. Removing it does not cost you convenience, it costs you the only detection mechanism that worked without having been designed.

Triggering itself is, incidentally, one of the five behaviours that separate a real agent from a well-dressed assistant. It is also the one that changes the nature of the risk the most, because it is the only one that removes the human from the loop by construction rather than by neglect.

Who owns a routine six months later?

Nobody, most of the time, and it has become a named category of risk.

An orphaned agent is an agent whose accountable human owner has left the organisation or is no longer identifiable, while its credentials remain valid. The phenomenon is not theoretical: security teams report an accumulation of autonomous tools still running after their creators departed. The credentials involved are routinely created with one to two year expiry, sometimes none, where the standing recommendation is 90 days and two declared active owners per registration.

The order of magnitude is the one we cited about non-human identities: 45 non-human accounts for every human one, and 92% of identity management tools unsuited to those objects. A routine is nothing other than a non-human account with a clock attached.

The remedy is administrative and holds no mystery: add agents to the leaver process, alongside a badge, a mailbox or remote access. It is not glamorous, it fits on one line of an existing checklist, and it is the difference between a routine that stops cleanly on a Friday and a routine still writing into a CRM under the name of somebody who has worked elsewhere for eight months.

Why silence is the worst failure mode

Because a run that found nothing and a run that never happened produce exactly the same thing.

The numbers make it concrete. Datadog measures roughly 5% failures on model requests in production, nearly 60% of them from capacity limits. On a daily routine that averages one missed run a month, at an hour when nobody is looking, for a reason that has nothing to do with the quality of what was asked. Add that nearly seven companies in ten now run at least three different models, and you get several sources of unavailability that do not coordinate with each other.

The rule we take from it is more demanding than it sounds: the absence of a result has to be an event. A routine that ran and found nothing says so, briefly, wherever it usually speaks. It feels chatty for two weeks, then it becomes the only thing separating a quiet month from a month in which the task was broken. The cost of that convention is one line a day; the cost of skipping it is a gap discovered six weeks later, when somebody notices they have not received anything in a while without being able to say since when.

A less obvious corollary: a run that fails does not retry indefinitely in silence. Retrying without saying so is one of the behaviours a good agent refuses, because a series of invisible attempts turns a clean outage into a slow degradation nobody can date.

Which tasks deserve to be scheduled?

The ones whose result is faster to check than to produce, which is the same criterion as for a first delegation to an agent and for the same reason: trust is built on what you can verify at a glance.

Two further properties matter when nobody is watching. The task must survive running twice, because recovery after an incident will replay it: a nudge sent twice is damage, a figure recomputed is not. And its output must be bounded, in the sense that you know in advance what a normal result looks like. A routine that can legitimately produce three lines or forty pages cannot be supervised, since no deviation stands out.

What fails all three tests, consistently, are judgement tasks: deciding which candidate to call back, arbitrating between two priorities, choosing the tone of a difficult reply. They can be prepared overnight, they cannot be settled overnight, and the difference between those two verbs is the whole governance of this subject.

What we decided, and the case we did not solve

At Balt a routine is an object somebody owns, not a configuration. It carries the name of the person who created it, it runs with their rights, it appears on their screen, and an administrator can suspend it for the whole company in one gesture. What it produces arrives in a conversation, not in a log nobody opens.

The rule that settles the rest is the one we apply everywhere: approval follows the action and never the agent. A routine that prepares a message prepares it and stops there, because a send triggered by a clock is still an outbound send a person releases. Scheduling a task creates no new permission, and that is the only wording that holds up under the pressure of convenience, because the temptation to add “and just send it” comes up roughly every week.

The case we have not solved cleanly is departure. Attaching the routine to its creator means it falls when they leave, and that behaviour is good for security and bad for operations: a weekly nudge useful to a whole team stops because the person who wrote it changed jobs. We chose to let it fall, knowing it would produce irritation, because the other option is running rights that belong to nobody. An explicit handover to a new owner is still the right answer, and it is a human gesture rather than a mechanism.

What to review, and how often

An hour a quarter is enough, provided you look at the right columns.

For each routine: who owns it, which rights it runs with, when a human last read its output, and what it has produced since. The third column is the one that talks. A routine whose output nobody has read in six months is not a routine working quietly, it is an active access whose reason nobody remembers, and it gets retired rather than fixed.

That review does not replace the question that comes before it and decides everything else: which controls apply to which action, since reading, drafting, writing internally and writing outward do not call for the same guardrails, and a single policy applied to every agent fails at both ends.