Every agent in your firm needs an AI agent activity log, and my guess is most of yours don’t have one. Ask the most autonomous tool you run what it did last Tuesday, step by step, in order, and most owners can’t get that answer today. They know what the tool is allowed to touch. They can’t tell you what it actually did, and that distance between the permission and the record is where agent risk lives in a firm your size.
Canada’s privacy commissioners expect this kind of trail. Their principles for generative AI ask organizations that use AI in decisions about people to keep records good enough to answer an access request about that decision.
When you set the tool up, somebody made decisions. Which systems it may open. Which files it may change. If it may send mail in your name or only draft it. Those decisions matter, and most firms never look at them again. But a permission is a statement about the future. It says what the agent may do on a good day. It says nothing about what the agent did on Tuesday, in the order it did it, with your clients on the other end.
What is the difference between a permission and a record?
A permission is the before picture and a record is the after picture. The permission is the list of doors the agent holds keys to. The record is the trail of which doors it opened, what it carried through them, and what it left changed.
Firms buy the before picture because setup screens ask for it. Almost nobody asks for the after picture until something goes wrong, and by then the trail is the one thing they wish they had. That goes double for tasks that run on a timer while nobody watches.
Why is the agent’s own summary not a record?
Because a summary written by the agent is a claim, and a record is evidence. Ask the tool what it did and it will answer in confident sentences, the same way it answers everything. It may be right.
It may also skip the run that failed, smooth over the file it touched twice, or describe the job it meant to do instead of the job it did. Letting the agent report on itself is like letting an employee write their own timesheet from memory and calling the matter closed.
This is not a small-firm problem with a big-firm answer. Without a record, an owner is not reviewing the agent. They are guessing.
What belongs in the log?
Four things, in plain words a person can read. What the agent opened, system by system. What it changed, sent, or spent. Who or what was on the other end, a client, a supplier, a file, a mailbox.
And the order it all happened in, with times attached. That is the whole list. It does not need a platform or a dashboard. It needs to be complete, kept somewhere your firm controls, and readable by a person who was not in the room when the work ran.
The order matters more than owners expect. A list of actions with no sequence can hide the one step that caused the trouble, because the trouble usually sits between two innocent steps. The proof belongs inside the work, never in a report about the work. A record you can replay is a record you can trust.
If a person cannot read it on a Friday, it is storage, not a log.
Who reads it, and how often?
A named person, once a week, in a booked slot that survives busy weeks. Twenty minutes is enough at your size. Read the week’s trail the way you would read an employee’s work before it went out under your name, because that is what it is.
Then pick one item at random and trace it back to its source, the sent email in the sent folder, the changed figure in the actual file. One traced item a week keeps the whole record honest, because it proves the trail and the real files still match. I’d guard that slot harder than most meetings.
This is a habit, not a binder, the same as every other control that works in a firm your size. A yearly dig through a year of agent actions finds the problem after it has had a year to compound. A weekly read finds it while it is still a sentence you can fix and a permission you can narrow. The reading is the control. The file on its own controls nothing.
A usable log needs four columns and nothing fancy.
| What to record | Example |
|---|---|
| Systems opened | Email, shared drive, booking tool |
| What changed, was sent or was spent | File edited, email sent, order placed |
| The other party | Client, supplier, file or mailbox |
| Order and time | Every step, with a timestamp |
How do you run the Tuesday test this week?
Run the Tuesday test. Take the most autonomous tool your firm runs, the one that acts with the least human touch, and ask it to show you last Tuesday, step by step, in order. If it can, you have a record, and your job is to name the person who reads it weekly.
If it cannot, shorten the leash the same day: fewer doors, drafts instead of sends, a person approving the steps that touch clients. Then turn the logging on before any new agent ships in your firm, because adding a second unrecorded agent is how a gap becomes the way the office runs. In AI Automation Systems work, I put the trail in place before the agent gets its keys.
What people ask about AI agent activity log
What should an AI agent activity log record?
Four things in plain words. What the agent opened, system by system. What it changed, sent or spent. Who or what was on the other end, such as a client, supplier, file or mailbox. And the order it all happened in, with times attached, kept somewhere your firm controls.
Is an AI agent’s own summary good enough as a record?
No. A summary written by the agent is a claim, not evidence. It may skip the run that failed or describe the job it meant to do instead of the job it did. A log is the trail of actual actions that a person can replay and check against the real files.
Could your most autonomous tool show you last Tuesday right now? If not, that’s this week’s fix, and I cover fixes like it every Friday in the AI Newsletter with ZAK.
7 Comments