How to Know Your Agents Ran Overnight

At a retirement planning firm, the working day starts for the software a few hours before it starts for the advisors. One agent reads the next forty-eight hours of meetings out of the CRM and writes each advisor a brief on the people they are about to see. It posts that brief to the meeting record and sends it to the advisor's inbox. A sales tracker portal pulls a fresh copy of the numbers every hour, all day. There are ten agents there now, running across eight systems, and most of that work happens while the office is empty.

Here is the part I was slow to take seriously. If the brief agent does not run one morning, the advisor's inbox looks exactly the way it looks on a morning with no meetings. Nothing turns red. Nobody gets an error. The system is quiet, and quiet is also what working looks like.

A screen complains. An agent does not.

When a dashboard breaks you hear about it the same morning. Somebody was going to look at it, they looked, and the number was missing or obviously wrong. The people who use screens are the monitoring, and they are good at it, because they know what the number should be.

An agent gets none of that, and it is the direct cost of the thing that makes agents work at all. The systems people actually use are the ones that arrive inside something they already open. The better an agent fits into somebody's morning, the less likely that person is to notice the morning it is not there. Nobody files a ticket about an email they did not receive. They were not waiting for it. That was the whole idea.

Worse than silence is stale. A sync that stops does not leave a blank page. It leaves yesterday's figures, correctly formatted, in the usual place, under a heading that still says what it always said. Old numbers look exactly like real numbers. Someone will make a decision on them, and the first sign of trouble will be a conversation where two people are looking at the same screen and disagreeing about the business.

What goes in every build now

Three things, and none of them is clever. They add a day to a build at most.

A line per run, somewhere a person can read. When the agent runs it writes down that it ran: the time, how many items it handled, how long it took, and what it cost. Not a log file an engineer greps. A place the owner can open. Half the value is that on the day something looks wrong, the first question has an answer within a minute, and the answer is usually that it ran fine and the problem is somewhere else.

An alert on the expected count, not only on errors. Most monitoring waits for something to throw an error. The failures that survive for weeks never throw one. A job that finds no meetings and writes no briefs has not failed in any sense the code can see, and on a Tuesday it is the single most interesting fact about the morning. So the rule we write into the scope is a number: this runs on weekday mornings and normally produces between ten and forty of these. Outside that range, tell somebody.

A human name on the failure. The alert goes to a person inside the company, not only to us. That sounds like a small routing decision and it is not. It is the difference between a system the company operates and a system it rents from whoever built it. It belongs with the rest of what you owe the named owner: the credentials, the runbook, and the hours in their week to use them.

The agent is rarely the thing that broke

In practice the code keeps doing what it was told. What moves is the ground underneath it.

A field gets renamed in the CRM by somebody tidying up. A credential expires on its ninetieth day. A permission follows a departing employee out of the company. An integration starts refusing calls after a limit somebody raised a year ago and nobody remembered. The source systems belong to other people, and those people are doing their jobs properly when they change them. None of it arrives as a message addressed to your automation.

This is the argument for a small number of connections you understand rather than many you do not. It is also why the first question to put to your own IT team is not about models. It is who tells us when a field changes, and it is fair to ask them what they would want to be told in return, because your agents are now writing into systems they support.

The exercise for this week

Take whatever list you have of the automations running in your company. Next to each one write the answer to a single question: how would I find out if this stopped last night.

Some will have a real answer. A person is waiting for the output at a known time and will say something within the hour. Those are fine and you can leave them alone.

The rest will get a version of "somebody would eventually notice." That is not an answer, and the ones that recur most often are the ones to fix first, because a job that runs six hundred times a year is a job whose absence costs the most before anyone speaks up. Give each of them a number it is expected to produce and a person who hears about it when it does not. It is an afternoon of work, and it converts a set of automations you hope are running into a set you know are.