A daily task had been running for three weeks. Asked a simple question about it, what went out on Tuesday, there was no way to answer. The work had happened. The evidence was spread across a personal inbox, mixed in with everything else that arrives in a day.
Nothing was broken. That is the part worth noticing. The automation did its job every single day and still could not be checked.
Work that cannot be reconstructed did not really happen, as far as anyone reviewing it is concerned.
The first version always borrows your identity
When you set up a repeating task, the fastest path is to let it use what is already there. Your email address. Your login. Your folder. It takes a minute instead of an afternoon, and on day one it is obviously fine, because you remember setting it up and you can see it working.
The cost arrives later and arrives quietly. Three weeks in, the record of what the software did is interleaved with the record of what you did, and there is no way to separate them. You cannot filter for it, because it looks like you. You cannot count it, because it is mixed into your own volume. You cannot tell the difference between a day it ran and did nothing, and a day it did not run.
This is not an argument about tidiness. It is that the thing you will eventually need to do, which is answer a question about what happened, has become impossible, and it became impossible without anything going wrong.
Three things to separate
The fix is boring and it is mostly done up front. Give the automation:
- Its own address. A separate email account, sender, or user. Not a filter on yours, an actual separate identity. Then everything it touches is filterable by origin rather than by guessing from content.
- Its own log. One append-only record with a line per run: when it fired, what it acted on, what it did, and what it decided not to do. The last one matters most and is usually missing.
- Its own name on the record. In whatever system holds the outcome, the row should say which process created it. Six weeks from now that field is the difference between an answer and an afternoon.
None of this is sophisticated. All of it is much harder to add later, because retrofitting it means reconstructing history that was never kept.
What a useful log line contains
Most logging records success and nothing else, which recreates the original problem in a new place. A log of successes cannot tell you about the day the process ran and found nothing.
| Weak line | Useful line |
|---|---|
| "Job completed" | "Ran 05:02. 14 candidates. 5 sent. 9 skipped, below threshold." |
| "Email sent" | "Sent to 5 recipients. Ids recorded. 2 suppressed, already contacted." |
| "No errors" | "Zero actions taken. Source returned 0 rows." |
The right-hand column has a property the left does not: a run that quietly did nothing looks different from a run that worked. That is the whole point. "No errors" is the same line whether the automation is working or has been silently idle since Thursday.
Record what it skipped and why. A process making sensible decisions and a process that has stopped seeing its input produce identical output, and only the skip count distinguishes them.
The test is a question, not a dashboard
You do not need a monitoring tool to know whether this is set up properly. You need one question, asked cold:
What did this do last Tuesday, and what did it decide not to do?
If answering takes more than a minute, the automation does not have its own paper trail yet, whatever else it has. If you cannot answer at all, it has been running on trust, which works right up until someone asks.
Ask the question a week after setting anything up, while it is still cheap to fix. The answer is either immediate or it is a project.
What to take away
- Give every repeating task its own address, its own log, and its own name on the records it creates. Do it when you build it, because retrofitting means reconstructing history you never kept.
- Log what it skipped and why, not only what it did. A quietly idle process and a correctly selective one are indistinguishable otherwise.
- Test it by asking what happened on a specific day last week. More than a minute to answer means the trail is not there.
Handing work to software is not the same as handing over responsibility for it. You still have to be able to say what happened, and that is a decision you make when you set the thing up rather than when someone asks. The AI does the busywork, you still make the calls.