Audits and logs

Every action an agent takes produces a record: what triggered it, which rule matched, which tools it called with which arguments, what came back, and what it decided next.

That record has three uses, and only one of them is debugging.

Answering the question afterwards

When a customer asks why something happened, “the system did it” is not an answer anyone accepts, and increasingly not one regulators accept either. A complete log turns that question into a lookup: this arrived, this rule applied, this action followed.

That capability is worth having before you need it. Reconstructing a decision from an incomplete log, months later, is not possible at any price.

Readable by the people who own the process

A log that only a developer can interpret is a log that gets read once, during an incident, by the wrong person. The record is written to be read by whoever owns the process: plain descriptions of what happened rather than internal identifiers.

The source for improvement

The log is where you see which exceptions keep recurring. A case that escalates once is noise; the same case escalating forty times is either a rule that needs writing or a process that needs fixing.

That is a better roadmap than any planning session, because it is built from what actually happened rather than from what people remember happening.

Retention

How long records are kept is agreed per engagement and written into the data processing agreement. Indefinite retention is not a default: a log of every action an agent took on your customers’ data is itself data, and it falls under the same rules as everything else.