AI Agent Logging
Logs are where the evidence lives. A trace tells you a tool was called and took 900ms; only the log tells you what it returned and what the agent did with it. That makes agent logs the most useful and the most dangerous thing your system produces, so this page covers the schema, the redaction, and the bill.
Print statements do not survive contact with an agent
A log line for an agent is not a sentence, it is a structured event: a fixed set of fields, one JSON object per thing that happened, joined to a run id. The difference matters because you will be searching these at 2am, across thousands of runs, for one customer's request, and grep over prose does not survive that.
| Log an event when | Why |
|---|---|
| The run starts and ends | Bookends. Without them you cannot tell a crash from a run still going. |
| A tool is called, and again when it returns | The arguments and the raw result are the two things you will actually want, and they are not in the trace. |
| A guardrail or check fires | Blocked injections and failed checks are the events security will ask you for. |
| The agent escalates or refuses | The volume of these is a product signal, not just an engineering one. |
| Anything retries | Retries hide inside a successful run and only the log shows how much work was really done. |
Live: build the log event
Tick the fields you would keep. The event rewrites itself, and untick anything essential and it tells you which 2am question you just gave up on.
Live: redact before you store, not after
Paste anything an agent might read: a support email, an order record, a config file. The rules below run in this tab and nothing leaves your machine. This is the same regex pass you would run at write time, in the logging layer, before the event reaches the store.
The redacted version appears here.
Regex catches the shapes: cards, emails, phones, keys. It will never catch "the customer said her daughter's diagnosis was". That is why retention is the other half of the answer, and why nobody should be able to query raw agent logs without a reason.
Live: what this will cost you
Agent logs are big, because the payloads are prompts and documents. Put your own numbers in. The point of the calculator is not the exact bill, it is finding out that full payload logging at your traffic is a five figure line item before finance does.
Three things to try, in this order
1. Untick the run id, then read the event
It is still perfectly valid JSON and completely useless. Every other field describes something that happened to nobody in particular. The join key is the field, and it is the one people forget.
2. Paste a real support email into the redaction box
Run it with the rules off, then on. What comes out with the rules off is what would be sitting in your log store tonight, searchable by everyone with a dashboard login.
3. Set the calculator to your real traffic
Then set the event size to 40KB, which is what full prompt logging actually costs. That number is the reason sampling and payload truncation exist, and the reason to decide the policy now instead of after the invoice.
How logging fails
Prose instead of fields
log("tool failed for user") cannot be counted, filtered, or joined. One JSON object per event, always the same keys.
Logging the output only
The final answer tells you what went wrong and never why. The tool arguments and the raw result are the evidence.
Everything at debug
Then everything is off in production, and the one run you need has no record. Put the evidence at info and truncate instead.
Redacting on read
Once it is written, it is in the backups, the replicas, and the vendor's index. Redact in the logging layer, on the way out.
Related: Observability · Tracing · Metrics · Monitoring · Guardrails · all patterns
Free from AI School - no signup, everything runs in your browser.