Audit logs are a feature, not plumbing
Most products treat a log as invisible infrastructure, built late and rarely opened. Once an agent can act on its own, it becomes the thing you check first.
The short answer
- An audit log is usually built as an afterthought, to satisfy a compliance requirement. Nobody designs it as something a person reads regularly.
- In a system where only people act, that mostly works. A person can usually explain their own actions when asked.
- In a system where an agent acts on its own, the log is no longer a backup. It is the main way anyone finds out what the agent did, including the team that built it.
- SalesCrew's audit log records every action as its actor, human, token or agent, and is append-only. The actions most worth reviewing are the automated ones, and they happen at a volume no person tracks by memory.
Why a log built as an afterthought is usually good enough for humans
Most software is built with people as the only actors. For that case, a minimal change log is usually enough in practice. It exists mostly to answer an eventual compliance question. When a person needs to know why a record changed, they can ask the person who changed it. Or they reconstruct it from memory, a support ticket, or a Slack message. The log is a fallback for when that informal route fails. It is not the main way anyone finds out what happened.
That is why audit logging gets treated as plumbing. It has to exist, usually for a checklist. Nobody expects to open it regularly, because asking a colleague usually works first.
Why that stops being true once an agent can act
An agent has no memory you can ask. It acts at a volume and speed no colleague can keep up with. Suppose an agent updates two hundred records incorrectly because of one bad assumption. There is no person to ask what happened. The two hundred records do not announce that something is wrong. The only way to answer "what did this agent do, and was it right" is to read a record of the actions themselves. The log has gone from a fallback nobody opens to the main tool for understanding, and if needed reversing, what happened.
This changes what "good enough" means. A log built as plumbing records that a change happened, maybe with a timestamp, and stops there. A log built as a feature records enough to answer real operational questions on its own: what changed, from what value to what value, who or what made the change, and ideally what evidence the actor had at the time. A person reviewing an agent's history after the fact was not there to see the reasoning live. With a colleague, they might have noticed the mistake as it happened.
What building the log as a feature actually looks like
SalesCrew's audit log is append-only. No entry, once written, can be edited or removed, not even by an administrator. A log that can be quietly altered stops being trustworthy as evidence. Every entry records its actor as one of three types: a user, an API token, or an agent. A change made by automation is never mistaken for a change a person made by hand. That matters for one question: "was this a person's judgment call, or a system doing what it was told". Every tool call across the MCP server, 145 registered tools, is written to this log. Not only the calls that change a customer-visible field. A read that fed a bad decision is part of the story of what went wrong, as much as the write that followed it.
The practical shift, for any team building or buying a product where an agent can act, is simple. Stop treating the audit log as a compliance box to tick once. Treat it as a feature someone will open regularly to understand what an automated process did. That means making it queryable by actor, by record, and by time range from day one. Retrofitting that after the first hard question is too late.
Questions
- Isn't an audit log mostly needed for compliance audits?
- Compliance is one use, but not the main one in an agent-operated system. The common use is operational. A person needs to see what an automated process did, right after it ran, to decide whether to trust the next run or roll something back.
- What makes a log entry actually useful versus just present?
- A useful entry answers four questions on its own: what changed, from what to what, who or what did it, and when. A log that only says 'record updated', with no before-and-after value, is technically a log. It is not a useful one.
- Does SalesCrew's audit log cover agent actions specifically?
- Yes. Every tool call is written to the audit log, whether a person made it through the UI, an API token made it, or an agent made it. The actor is recorded as one of those three types. An agent's action is never mistaken for a person's.