Module 7 — The AI Agent: Using It · Lesson 7.4
Reading What the Agent Did
The action ledger, undo, task activity, and telling a report of success from an actual effect
~11 min
What you'll learn
- Find the record of what the agent did and when
- Undo an agent action using the shared undo stack
- Verify an outcome rather than trusting a summary
- Investigate a silent no-op in the right order
Delegation to anything — a person or an agent — needs a way to check. The check is not distrust; it is what makes wider delegation reasonable. Kavanah records everything the agent does, which means the check is cheap. This lesson is about actually doing it.
Where the record lives
Three places, at different resolutions.
The conversation itself shows what the agent said it did, inline, as it did it. This is the fastest read and it is a report rather than proof.
The object's own activity trail — a task's activity, a deal's timeline — shows what actually changed on that record, including changes made by the agent. This is proof for that object.
And the workspace's action ledger and audit log record actions across the workspace, with arguments and outcomes. This is where you go when the question is 'what has it been doing' rather than 'what happened to this task'.
For admins, Settings → Audit Logs is the durable version of that history.
Undo
The agent's actions go onto the same server-backed undo stack the interface uses. Cmd+Z undoes; Cmd+Shift+Z redoes. The agent also has undo tools of its own, so 'undo that' is a valid instruction.
What this covers is the trash-style lifecycle changes to tasks, projects and clients. What it does not cover is anything that has already left the building — a sent email, a posted message, a triggered deploy.
That asymmetry is exactly why the governance model treats those categories differently. Internal changes are cheap to reverse, so the agent may make them relatively freely. External ones are not, so they park for approval. Knowing which side of that line an action falls on tells you which safety net applies.
The verification habit
This is the most valuable paragraph in the lesson.
The single commonest class of problem in a system like this is not a wrong action. It is a reported success whose side effect never happened — an integration that silently failed, a queue that never drained, a send that was accepted and never delivered. The summary says it was done. Nothing was done.
So for anything that matters, verify the effect rather than reading the report. If the agent says it emailed someone, the check is not 'did it say it sent' — it is whether there is a record of the send with a delivery status. If it says it created tasks, look at the board. If it says it updated a connected tool, look in that tool.
This takes seconds and it is the difference between an agent you can trust with more and an agent you eventually stop trusting for reasons you cannot articulate.
Investigating a silent no-op
When the effect did not happen, work in this order.
One: was the action actually attempted? Check the ledger. An action that was never attempted is a different problem from one that failed.
Two: was it parked for approval? Under the default policy, external sends and destructive actions do not execute — they queue for your explicit approval. An action sitting in the approval queue looks exactly like an action that did nothing. This is the single most common answer.
Three: was it refused by the charter? Charter refusals cite the line and are logged in the KVN ledger.
Four: did the underlying integration fail? Check whether the connection is still healthy rather than whether the tool call returned.
Most investigations end at step two, which is why it is worth checking the approval queue before assuming anything is broken.
Build the checking habit
- 1
Ask the agent to do something small, then verify it
Have it create two tasks, then look at the board rather than at its summary. Do this once deliberately.
- 2
Cmd+Z, or just tell it to undo. Knowing what this feels like before you need it is worth thirty seconds.
- 3
Open a task the agent touched and read what actually changed. This is proof, where the conversation is a report.
- 4
Settings → Audit Logs. Worth knowing where it is before the day you need it.
What to watch
- Verified-effect rate
- How often a reported action is confirmed to have had its effect, for the actions that matter.
- Healthy signal: Every consequential one. This is a habit rather than a number, and it is what makes wider delegation defensible.
- Approval-queue age
- How long parked actions wait before someone approves or rejects them.
- Healthy signal: Hours. A stale queue is the most common cause of 'the agent didn't do it' reports.
- Undo rate on agent actions
- Share of agent actions that get undone.
- Healthy signal: Low but non-zero. Zero usually means nobody is checking rather than that nothing was wrong.
Key takeaways
- ·Three resolutions of record: the conversation (a report), the object's activity (proof), the ledger and audit log (the workspace view).
- ·Agent actions share the interface's undo stack — 'undo that' is a valid instruction.
- ·Undo covers internal lifecycle changes, never anything that has already left the building.
- ·Verify the EFFECT, not the report — a silent no-op is the commonest failure in systems like this.
- ·When something did not happen, check the approval queue before assuming it broke.
One more in this module: what the agent remembers between conversations, and how to give it standing context.