How should an AI agent report what it did?
A useful agent report is built from what actually ran, not from the model's description of itself. It names what completed (with links or receipts), what failed and why, what is waiting on you, what comes next, and what it cost. Everything else is noise.
What should an agent's report actually contain?
The core problem with most agent output is that it reads like a summary the model wrote about itself rather than a ledger of real events. A model can describe a task as 'completed' while the underlying action never fired. The fix is to anchor every line of the report to an observable artefact: a sent timestamp, a deployment URL, a transaction hash, a file path, a screenshot. If no artefact exists, the line should say 'attempted' rather than 'done'.
A well-structured report has five sections in order: what finished (with evidence), what did not work and the specific reason, what is blocked waiting on you, what the agent intends to do next, and what the run cost in credits or tokens. Keeping these five sections separate forces honesty — a failure cannot hide inside a paragraph of successes.
- Completed
- Actions the agent can prove ran: a link, a receipt, a file, a timestamp. If the proof is absent, the item moves to 'attempted'.
- Blocked
- Steps the agent cannot take without a decision or credential from you. Named explicitly so they do not silently stall the queue.
- Failed
- Steps that ran and produced an error, with the error quoted verbatim rather than paraphrased.
- Pending
- Steps the agent plans to take next, in order, so you can object before credits are spent.
When should the report arrive — immediately or on a schedule?
The timing of a report matters as much as its content. Three conditions should always trigger an immediate report: the task finished, the agent is stuck and cannot continue, or the next step requires your approval before real money or irreversible actions are involved. Waiting until a scheduled daily brief to surface a blocker wastes hours and can leave downstream tasks queued behind a problem you could have resolved in seconds.
For long-running background work — monitoring, recurring publishing, strategy execution — a single daily brief at a time you choose is the right default. Constant interruptions for routine progress defeat the purpose of automation. The distinction is simple: if the agent can continue safely without you, it should continue and report later; if it cannot, it should stop and tell you now.
| Situation | Report timing | Reason |
|---|---|---|
| Task fully completed | Immediately | You may need the output to start the next task yourself |
| Agent is blocked | Immediately | Every hour of silence is wasted queue time |
| Next step is irreversible or costly | Immediately, with confirmation request | Approval before action, not after |
| Routine background progress | Daily brief at chosen hour | Interruptions reduce the value of automation |
| Recurring strategy or schedule running normally | Daily brief or on-demand | No action needed from you unless a limit is hit |
How do you tell whether a report is trustworthy?
The most reliable signal is whether the report was generated from execution logs rather than from the model's own memory of what it did. A model's memory of a session can drift; an execution log cannot. Look for reports that quote error messages verbatim, include links that actually resolve, and separate 'attempted' from 'completed' rather than collapsing both into a single past-tense verb.
A second signal is whether the report names what it cost. An agent that reports outcomes without reporting resource consumption gives you no basis for deciding whether to run it again. Cost transparency is not a nicety — it is the mechanism by which you stay in control of a system that acts on your behalf. If the report omits cost, treat its other claims with proportional scepticism.
A third signal is the presence of a 'decisions I made for you' section at the end of a long multi-round run. Any agent that made choices on your behalf during a complex task should surface those choices explicitly — what it decided, why, and how you could change the outcome — rather than burying them inside the completed items.
Where does a simpler tool outperform an agent's report?
An agent report is the right format when the work involved multiple steps, multiple tools, or decisions made on your behalf. For a single discrete action — send this email, resize this image, run this query — a simple confirmation is better. A five-section structured report for a one-step task creates overhead without adding clarity.
Similarly, if you are running a workflow where every step is deterministic and pre-approved, a plain log file or a webhook to your existing monitoring tool is more appropriate than a conversational report. Agent reporting earns its complexity when the agent exercised judgement. When it did not, a lighter format is the honest choice.
Common questions
What is the difference between an agent saying 'done' and proving it is done?
Saying 'done' is the model's assertion about its own output. Proving it means attaching an artefact that exists independently of the model: a URL that loads, a sent timestamp in an email thread, a transaction hash on a public ledger, a file at a known path. If the artefact is missing, the honest word is 'attempted', not 'done'. This distinction matters most when the action was irreversible or costly.
Should an agent interrupt me every time it completes a small step?
No. Constant interruptions for routine progress undermine the point of automation. The right trigger for an immediate report is one of three conditions: the whole task is finished, the agent is blocked and cannot continue, or the next step requires your approval before real money or irreversible actions are involved. Everything else can wait for a scheduled daily brief.
Why does an agent report need to include cost?
Without cost, you have no basis for deciding whether to run the agent again or adjust its scope. Cost transparency is the mechanism by which you stay in control of a system that spends resources on your behalf. An agent that reports outcomes but hides consumption is giving you an incomplete picture, and an incomplete picture is not a trustworthy one.
What should an agent do when it hits the same problem a third time?
Applying the same patch a third time is a sign the root cause has not been identified. A well-designed agent should change its approach at that point: look for the underlying cause rather than patching the symptom again, and say explicitly that it is doing so. Repeating a failed fix without disclosure is a form of misreporting, even if the agent believes each attempt is slightly different.
GROX ends long multi-round runs with a 'Decisions I made for you' section — every choice it made on your behalf, why, and how to change it — and its site-check and build-verification steps produce counted facts rather than model opinions. Read more at grox.life.