Commit

"Customer records updated successfully." That's a status message. It doesn't say which records changed, what authorised the change, or whether "successfully" means the tool returned OK or someone checked the result. Last article I asked who gets to stop an agent and approve a restart. Whoever that is needs something better than a reassuring sentence. And better than several thousand lines of events with no obvious place to start. Start with the job, not the model's story. "Clean up the customer records" is a request. "Delete records with no activity in twelve months" is an interpretation. An approval for formatting changes is not approval for that deletion. If the log merges all of it into "completed customer cleanup," the most important part has disappeared. Security logging already has foundations: NIST's audit-record fields, OWASP's when/where/who/what. For agents, connect the events to the original task and the specific approval. Here's the kind of record I'd want waiting for whoever holds the restart decision: Requested: standardise address formatting. Approved: formatting changes to 42 records. No deletions. Observed: the database audit recorded 42 updates. A before-and-after comparison found changed address fields in 40, and changed account-status fields in 2. Current state: run paused, no further writes through 14:32 UTC. Queued work not yet checked. Decision needed: review the two status changes and outstanding work before authorising a restart. Notice where the evidence comes from: the database audit, not the agent's account of the database. If the agent assembles its own receipt, nothing else in the record is worth much. An explanation isn't a receipt either. Anthropic tested reasoning models with planted hints. Models sometimes followed them without admitting the influence. A particular research setup, but enough to distinguish a readable account from a faithful one. "I changed the status because the account was inactive" is a stated reason. Not the confirmed cause. Not proof it was authorised. And "the operation succeeded"? A tool response, a recorded write and a verified business outcome are different pieces of evidence. A timeout leaves the result unknown. Retrying without checking can make things worse. A model-written summary can help navigate a long trace if it's labelled, linked to its sources and checkable without asking the same model another question. And more detail shouldn't mean copying every record and credential into another database. Keep the evidence needed, protect access to it, and prevent the agent from rewriting its own history. The test: can the responsible person use this record to distinguish a safe restart from a guess? If the answer depends entirely on the model telling a convincing story about itself, we haven't given that person an audit trail. We've given them another output to verify. Full post: https://coredatalabs.com/blog/logs-the-owner-can-actually-use…