Scheduled agents that check, digest, and report are the cheapest leverage available in a multi-project estate, and the cheapest way to ruin them is skipping cooldowns.
The lowest-effort, highest-return automation I run is not a complicated pipeline. It's an agent on a timer that looks at something — a queue, a set of accounts, a repository — and tells me only when there's something worth telling me. Cron, in the old Unix sense, applied to something that reads and reasons instead of just running a fixed script. It is genuinely the cheapest leverage I have found in running more than one project at once, because it converts "I should really check on that" from a recurring cost on my attention into a recurring cost on a machine that doesn't mind. The projects I run this against differ wildly — a deploy health check, an inbox, a quota dashboard — and the automation is the same shape every time, which is itself the point: once you've built the pattern once, adding a new thing to watch is cheap.
What makes it work is the same thing that makes any monitoring good: it has to check often enough to catch things while they're still small, and it has to shut up the rest of the time. An agent that runs every five minutes and reports every five minutes is not a digest, it's a denial-of-service attack against your own attention, and you will mute it within a day whether or not the underlying check is valuable. The value of a scheduled agent is entirely in the gap between how often it looks and how often it speaks.
The mistake that undoes this is treating "don't repeat yourself" as something the model will handle by default. It won't, reliably, because a scheduled run has no persistent memory of what it already told you unless you build one. I had a usage-monitoring agent re-announce the same "you're at 80% of weekly quota" line every single poll cycle, because its notion of "already said this" was in-memory state that reset every time the process restarted. Each restart, from its point of view, was the first time it had ever seen that number, so it said so again, out loud, on a schedule.
The fix has to live on the caller's side, not inside whatever text-to-speech or notification layer is doing the actual announcing. A generic announcement tool has no way to know that this particular fact was already said an hour ago — it just says what it's told. So the deduplication has to be a persistent, keyed cooldown that the scheduled agent itself checks before it decides to speak: a record on disk, not in memory, keyed to the specific fact being reported, with a time-to-live long enough that a restart doesn't reset it to zero.
Once that's in place, the pattern generalises cleanly across very different kinds of checks — quota monitors, health checks on a deployed service, digests of what changed in a repository overnight, watchers on an inbox for something that needs a response. The shape is always the same: look often, hold a memory of what you've already surfaced, only speak when the fact is new or has meaningfully changed. That shape is what turns "scheduled agent" from a toy into infrastructure.
The honest accounting is that most of what these scheduled checks find is nothing — the quota is fine, the deploy is healthy, nothing changed overnight. That's not a failure of the automation, that's the automation doing exactly its job: absorbing the cost of checking so that the rare time something is actually wrong, I hear about it within minutes instead of whenever I next happened to look. The value isn't in any single run. It's in never again being the one who has to remember to check. Once a handful of these are running, the estate starts to feel less like a set of projects I have to periodically inspect and more like a set of projects that tell me when they need me, which is the only way I've found to run more than a couple of them at once without one quietly going stale while I'm looking somewhere else.