How do I audit what an AI agent did?
Log every tool call with actor, arguments, result and cost. Keep it append-only. Make it filterable by agent, record and time. That combination answers 'why did this happen' in one query.
The short answer
- Log every tool call an agent makes with four fields: the actor (which agent, user or token), the arguments it called with, the result, and the cost. Keep that log append-only, so it cannot be edited after the fact.
- Make the log filterable by agent, by record and by time window. A log that exists but cannot answer 'show me everything that touched this contact last week' is not useful when a specific question comes up.
- A well-built audit log answers 'why did this contact get emailed' in one query. Which agent decided to send, what evidence it used, what it sent, and when. Without the tool-call detail, you can only say 'the agent was asked to do something like this', which is a weaker claim.
- The audit log is not a substitute for the approval queue or guardrails. It is what lets you check whether those controls did their job after the fact, and what lets you explain a specific outcome to a customer or a colleague.
Why logging the prompt is not the same as logging the action
A natural first instinct is to log the instruction an agent was given. "Summarize this deal." "Draft a follow-up to this contact." That captures intention, and intention is useful context. It is not what happened. An agent given the same instruction twice can behave differently depending on what it found in the record at the time, which tool it decided to call, and what that tool returned. Only a log of the actual tool calls, not the prompt that led to them, shows the real sequence of events.
This distinction matters most exactly when something goes wrong. If a customer asks why they received an email, "the agent was asked to check in with stale contacts" is not an answer. "The agent called cadence_advance for this contact at 9:14am, found no reply in eleven days, and sent step three of the sequence" is an answer. It is only available if the tool calls themselves were logged, not only the instruction behind them.
What belongs in an audit log entry
| Field | Why it is needed | Example |
|---|---|---|
| Actor | Identifies which agent, user, or token performed the action | "Inbox agent" or a specific MCP token name |
| Tool called | Shows exactly what kind of action was taken, not only the intent behind it | cadence_advance, deal_update_stage, inbox_reply_send |
| Arguments | Shows what the action was applied to and with what content | Contact ID, message body, target stage |
| Result | Shows whether the call succeeded and what changed as a result | Sent, queued for approval, failed with a reason |
| Cost | Ties the action to what it cost to produce, for later cost-per-feature analysis | Model used, tokens in and out, dollar cost |
| Timestamp | Places the action in sequence relative to everything else that happened | ISO timestamp, filterable by range |
Making the log actually queryable
A log that exists but can only be read top to bottom is not much better than no log once a CRM has more than a handful of agents running. The useful version supports three filters at minimum. By agent, so you can review one agent's whole history. By record, so you can answer "what happened to this contact" directly. By time window, so you can scope a review to a specific incident rather than searching everything.
Disclosure: SalesCrew is our product. Its audit log records who or what, user, token or agent, did what, and when, for every tool call the MCP server processes. That covers a person in the UI, an MCP client, or an agent acting on a schedule. The log is append-only and filterable by actor and by record. That is what makes "why did this contact get emailed" answerable in one query rather than a reconstruction project.
Logging the prompt audits the intention, not the action
Questions
- Is logging the prompt enough?
- No. The prompt shows what the agent was asked to consider, not what it did. Two runs with similar prompts can take very different actions. Only a log of the tool calls themselves, with arguments and results, shows what changed in the CRM.
- Does the audit log need to be append-only?
- Yes, or it stops being trustworthy. A log that can be edited or deleted after the fact cannot answer 'what happened' with confidence, because the record could itself have been altered. Append-only is what makes the log usable as evidence, not only as a debugging aid.
- Who actually looks at an audit log day to day?
- Usually whoever owns the approval queue or is investigating something specific. A customer asking why they received a message. A stage change nobody remembers making. Most teams do not review the whole log routinely. They query it when a specific question comes up.