The Recurring Task Your Agent Scheduled With Nobody To Inherit

A user types "remind me every Tuesday to check that integration." The agent creates a cron entry, returns a polite confirmation, and the session closes. Six months later the user has changed teams. The integration was deprecated last quarter. The cron is still firing, hitting an API key that was rotated in April, into a Slack channel that was archived in May, charged to a project budget that nobody reviews. The agent did exactly what was asked. The asking is what aged badly.

This is not a bug in any particular agent. It is the shape of a category. The moment we gave agents the ability to schedule durable side effects — cron jobs, webhooks, polling loops, workflow triggers, calendar invites, recurring queries — we created a class of infrastructure that is born without a lifecycle. The create primitive is loud and easy. The delete primitive, the audit primitive, the inheritance primitive — they don't exist on equal footing, so they don't get used.

The cost is invisible until you go looking, which is exactly when nobody is looking.

Create Is Easy, Inherit Is Impossible

Traditional infrastructure has an ownership trail because it was created by a human who has a manager, a team, a Slack handle, a PagerDuty rotation. The cron entry on the prod box was added by someone who showed up at standup. When that person leaves, there is at least a chain of custody: their manager inherits their tickets, their teammates inherit their on-call, and somebody eventually notices the orphaned job because it shows up in their grep.

Agent-created infrastructure has none of that. The agent is not on a team. The agent does not show up at standup. The agent's session ended seconds after the schedule was created and the agent has no memory of having created it. The only ownership thread is the user who made the request — and that thread is thin to begin with. The user did not write the cron file. The user did not name the workflow. The user often does not remember asking, and if they do remember, they have no inventory to consult.

Industry data on the closely related category of non-human identities is sobering. Only 20% of organizations have formal API-key offboarding processes. Ninety-one percent of former-employee tokens remain active after offboarding. The average enterprise environment contains over 800 risky AI agents, and only 15% of organizations report near-full agent ownership. Now imagine the agent itself spinning up scheduled jobs that inherit none of the audit scaffolding the underlying agent identity is already failing to maintain. The asymmetry compounds.

The phrase the security community has settled on is "zombie agents" — identities that persist after their owner or purpose is gone, retaining valid credentials and behaving like normal traffic. Zombie agent-created tasks are the operational analogue: schedules that persist after their reason is gone, firing valid requests into infrastructure that has moved on.

The Failure Modes Are Quiet

Orphan recurring tasks fail in ways that don't page anyone:

• The schedule fires into a Slack channel that no longer exists. Slack returns a 404. The agent logs an error nobody reads. The job retries on its next interval.
• The schedule fires against an API key that was rotated. The 401 response is logged. Nobody triages logs from a job nobody owns.
• The schedule fires successfully against an inbox owned by an account that has been deprovisioned. The mail bounces. The bounce goes to the SMTP from-address, which is the agent's service account, which has no human reading it.
• The schedule fires successfully and writes results to a destination that is still alive but has been repurposed — the dashboard the user used to check is now a dashboard for a different team's metric. The signal is silently pollutting somebody else's view.
• The schedule fires successfully and consumes paid compute every interval. The bill goes to a cost center that the finance team flagged as "unallocated overhead" twelve months ago. Nobody touches unallocated overhead because nobody owns it.

None of these fail loudly enough to trigger investigation. They fail quietly enough to accumulate. The fleet grows, not because any individual job is wrong, but because no individual job is anyone's job to delete.

Why The Asymmetry Is Structural, Not Accidental

It is tempting to treat this as a UX failing — "the agent should just ask the user about cleanup at creation time." That helps at the margin and fails at the system level, for three reasons.

First, the user asking for a recurring task is, by construction, optimistic about the task's future relevance. People who think a thing is worth doing weekly do not typically pre-commit to its expiration date. Asking "when should this stop?" at creation time gets you the answer "I don't know, just leave it running." That answer is structurally wrong and conversationally polite, and the agent will accept it.

Second, the user's relationship to the task and the task's relationship to the infrastructure are decoupled by the agent. In a pre-agent world, when a user wanted a recurring Slack notification, they had to figure out how to set it up, which meant they had to learn the system, which meant they ended up with a mental model of what they had created and where it lived. When the agent does this for them, the user has a request and a confirmation, not a system. They cannot audit what they cannot mentally locate.

Third, the agent's incentive gradient is biased toward creation. Every agent benchmark, every demo, every product launch celebrates "the agent that took action." Nobody runs a benchmark for "the agent that deleted its own stale outputs six months later." Build a system that is graded on create-actions and you will get a system that is, on net, an emitter.

Loading…