Silence is not progress
When you hand a long task to an AI agent and walk away, you are waiting for one of two things: a report saying it finished, or a message saying it is stuck. Most of the time one of those arrives.
The trouble is the third outcome, where nothing arrives at all. A job that is still working and a job that stopped an hour ago look identical from where you sit. Both are quiet. If your plan is to wait until you hear something, a dead job can sit there for as long as you are willing to wait.
The job that went quiet
On one software project, AI coding jobs were started on a desktop computer and left to run. One morning a job was asked to add a feature, and its instructions said plainly: build the code and run the tests before pushing anything.
It pushed its changes within about a quarter of an hour. The new tests it had written did not even compile. They referred to pieces of code that did not exist. Then the job went silent. No report, no note saying what was left, no sign of whether it was still going.
For more than two hours, nobody could tell whether it was still working or had died. A person looking in from outside saw recent changes to the job’s files and reasonably guessed it was still running. Nothing flagged the problem. It was found because someone went looking, on a morning when several jobs seemed to be failing, and a separate session picked up the broken branch, fixed the tests so they compiled, and ran the full suite.
The review afterwards named three causes, and none of them was about that one feature:
- “Done” was whatever the job said it was. Nothing independent looked at the test results.
- The jobs ran on a computer that could sleep, close, or lose permissions, and when that happens a running job can simply stop without telling anyone.
- Nothing was watching for silence. A dead job was found when a human happened to ask.
Why waiting does not work
Silence feels like patience. You assume the agent is busy, you do not want to interrupt, and the longer the task, the longer the quiet seems reasonable.
But an agent usually cannot tell you it has died. If the machine sleeps, the session ends, or the tool hangs, the job often never gets the chance to send a last message. The absence of a report is often the only signal you get, and it only means something if you decided in advance how long the absence is allowed to last.
This is a different problem from software that fails quietly in front of your users (covered in Nothing errored. That was the problem.). There, something ran and hid its failure. Here, the work itself may have stopped, and the only clue is that time is passing.
The habit: every unattended job gets a deadline and a watcher
Before you start any AI job you will not be watching, write down three things:
- When you expect to hear back. Not “when it’s done”, but a time. If the job should take forty minutes, pick an hour.
- Where the sign of life will show up. A report file, a message, a pushed change, a test run. Something you can look at that the job cannot fake by describing it.
- What happens if the deadline passes in silence. Treat it as a failure, not as “probably still going”. Someone, or something, goes and looks.
Then make the looking automatic, and make sure it is not the job checking on itself. On the project above, the fix was to move the jobs off the desktop computer onto cloud sessions that do not depend on a desktop staying awake, and to add a separate scheduled check that ran every hour. It did not read the jobs’ reports. It read the test results and the time of each job’s last pushed change, and flagged any job that had gone an hour without one. “Done” stopped meaning “the job said so” and started meaning “the tests on that change are green, as read by the watcher”.
You do not need that much machinery to start. A calendar reminder at the deadline, with a note of where to look, gets you most of the way. The point is that the check is decided before the silence starts, not after you have already been waiting.
Check the watcher once, too
A watcher is just another piece of software, and it can be wrong in quiet ways of its own. On the same project, the hourly check soon reported a gap of several hours in its own runs and sent an alert about it. There was no gap. The machine it ran on had no timezone data, so asking for the local time quietly returned a different timezone, and every time it reported was off by hours. The alert was confident and wrong.
The habit that caught it is cheap: the first time you set up a watcher, run it once by hand while you are looking, and compare what it says against what you can see for yourself. Check the times it reports against your own clock. If it says a job is stale, open the job and confirm.
How to check this week
Ask your AI assistant to list every job or long task it started on your behalf in the last few days, with four columns:
- when it started,
- when it was expected to finish,
- the last real sign of life (a pushed change, a test run, a report), with a link,
- whether a final report arrived.
Open the links yourself. Any row with no expected finish time is your answer: that job had no deadline, so silence from it would have meant nothing. Any row where the last sign of life is hours old and no report arrived is a job you should go and look at today.
If you want a second opinion on what a finished job actually delivered, our guide covers how to have a separate reviewer check the work instead of the agent that did it.