The Agent Run Report: Why Every Run Should End in a Document

An autonomous agent that works for eight minutes across five tools and produces nothing you can read has not really finished. It has stopped. The difference between "stopped" and "finished" is the report: a document that says what the agent did, what it found, what changed since last time, and whether the run met the bar you set for it.

This article makes the case that the report is not an afterthought bolted onto agent runs. It is the product of the run. Everything else, the tool calls, the searches, the queries, exists to feed it. We will walk through what a good run report contains, how success criteria turn a report from a diary into a verdict, how memory turns the third report into something sharper than the first, and where reports fit in your team's reading habits. We will also be honest about where reports fall short and what they cannot tell you.

The examples use Skopx, where every agent run ends in a markdown report rendered as a document, but the structural arguments apply to any agent platform you might use.

A run without a report is invisible work

Think about what an agent run actually is: a model reading your instructions, calling tools, reading results, deciding what to do next, and repeating until it decides it is done or hits a limit. That loop can touch Gmail, a Postgres database, a web search, and Slack in a single run. If the only evidence of all that activity is a raw log of API calls, three bad things happen.

First, nobody reads it. Raw tool output is JSON, pagination tokens, and HTML fragments. A human skimming that at 9 a.m. learns nothing. The work happened, but the knowledge it produced never transferred to a person, which means the run may as well not have happened.

Second, you cannot judge it. Was the run good? Did it find what it was supposed to find? Without a document that summarizes findings against a stated goal, "good" is unanswerable, and an agent you cannot evaluate is an agent you will eventually stop trusting for reasons you cannot articulate.

Third, you cannot compound it. A competitor monitoring agent that runs weekly should be able to say "two pricing changes since last Monday." That sentence requires the run to end in a structured artifact that the next run can compare against. No report, no baseline, no deltas.

The fix is a simple rule: every run ends in a document. Not a notification, not a log, a document. In Skopx, this is enforced by the platform itself. Every run, whether it was triggered manually, on a schedule, or by a webhook, terminates in a markdown report rendered as a readable document in the run history. The report is as much a part of the run as the tool calls are.

What a good run report contains

A run report is not a transcript. It is closer to the memo a careful analyst would write after doing the same work by hand. In practice, good reports converge on a recognizable shape:

A one-paragraph summary at the top. What was the run for, what happened, what matters. A reader who stops here should still leave with the headline. If your agent checked 40 open GitHub issues and found 3 that need a human today, that sentence goes first.

Findings, organized by importance rather than by chronology. The order in which the agent discovered things is an implementation detail. The report should lead with what the reader cares about most. A lead qualification agent should not narrate "first I opened HubSpot." It should say "two of the nine new leads match your ideal profile, here they are, here is why."

Evidence. Every claim in the report should trace back to something the agent actually observed: a specific email, a query result, a fetched page. Reports that assert without citing train readers to distrust them, and rightly so. This is where the report connects to the run's step timeline, which we cover below.

Actions taken and actions proposed. If the agent did anything write-shaped, the report should say exactly what. If actions are parked as pending approvals, the report should surface them so the reader knows a decision is waiting. In Skopx, write-shaped actions under an approval tier park as pending approvals showing the exact call and arguments, and the report is where you learn they exist. How that approval flow works end to end is its own topic, covered in AI agents with human approval.

What the agent could not do. The most underrated section. "I could not verify the Stripe invoice status because the integration returned an error" is more valuable than silence, because it tells the reader exactly where the automated coverage ends and their own attention must begin.

A verdict against success criteria. More on this next, because it deserves its own section.

Success criteria turn a diary into a verdict

The single biggest structural upgrade you can make to agent reports is defining, before the run, what a successful run looks like. Without that, every report is a diary entry: things happened, here they are, interpret them yourself. With it, the report becomes a verdict: here is the bar, here is whether we cleared it.

In Skopx, success criteria are part of the agent's anatomy alongside its instructions, trigger, grants, and budgets. You write them in plain language when you build the agent, and the run report evaluates the run against them. A support triage agent might carry criteria like "every new ticket is categorized, urgent tickets are flagged with a reason, and no ticket is marked resolved." The report then has to answer those specifically, not just narrate what it did.

This changes reader behavior in a useful way. Instead of reading the whole report every time, you can glance at the criteria evaluation. All green, skim and move on. Something failed, read carefully. Success criteria are effectively a table of contents for your attention.

They also change agent behavior. A model that knows the run will be graded on "no duplicate rows created in the sheet" behaves differently during the run than one told vaguely to "update the sheet." Criteria written down before the run act as guardrails during it. Writing criteria that are checkable rather than aspirational is a skill in itself, and we go deep on it in defining success criteria for AI agents.

One honest caveat: the evaluation is performed by the model, against criteria you wrote. It is a strong signal, not a proof. A criterion like "the summary is accurate" is graded by the same class of system that wrote the summary. Criteria tied to observable facts ("all 12 accounts were checked", "no message was sent without approval") are far more reliable than criteria about quality of judgment. Write the former where you can.

The step timeline: the evidence behind the document

A report you cannot verify is a report you eventually stop believing. That is why the report should never travel alone. Behind every Skopx run report sits a step timeline: every action the agent took, in order, with humanized labels ("Searched Gmail for invoices from March") that expand into the raw tool results underneath. The run also carries its duration and token count.

The relationship between report and timeline is the relationship between a paper and its footnotes. Most days you read the paper. The day something looks wrong, you follow the footnote. If the report claims "no new negative reviews this week," the timeline shows you the actual review-platform queries and their raw responses, and you can check whether the agent searched the right places or quietly searched nothing.

This pairing matters for three distinct audiences:

• The daily reader wants the report and nothing else.
• The skeptic wants to spot-check a claim against raw results. The expandable timeline serves them without cluttering the report.
• The debugger wants to know why run 14 produced a strange report. The timeline is where the answer lives, and debugging AI agent runs walks through that workflow step by step.

Run history in Skopx is append-only, which matters more than it sounds. A report that can be silently edited after the fact is not a record, it is a draft. Append-only history means the report you read on Tuesday is the report that existed on Tuesday, which is the property that makes reports usable as an audit trail at all.

Delta reports: why the second run reads better than the first

The first run of a monitoring agent produces a survey: here is the landscape, here are 30 things that exist. Useful once, exhausting weekly. What you actually want from run two onward is the delta: what changed since last time.

Deltas require memory. In Skopx, agents carry memory that persists between runs: cursors ("last processed email ID"), baselines ("competitor pricing as of last Monday"), and whatever state the agent needs to compare against. On the second run, the agent loads its baseline, checks current reality against it, and reports the difference. Second runs are typically cheaper too, because "compare against a stored baseline" is much less work than "survey everything from scratch." The mechanics of what agents can remember and how are covered in AI agent memory explained.

The reporting consequence is significant. A delta report is short, specific, and immediately actionable: "Since last run: competitor B removed their free tier, one tracked keyword dropped off page one, nothing else changed." That is a report a human will actually read every week for a year. A weekly 30-item survey is a report a human reads twice and then filters to a folder.

If your agent reports feel bloated, the fix is often not better writing instructions. It is giving the agent a baseline to diff against, so it has permission to say "nothing changed" about the 27 things that did not change.

Report, log, notification: three artifacts, three jobs

Teams often conflate three different run outputs. They serve different readers and different moments, and a healthy agent setup uses all three deliberately.

The common mistake is trying to make one artifact do all three jobs. A Slack message containing a full report gets scrolled past. A report that is really a log gets skimmed and mistrusted. Keep the notification short ("Weekly SEO run finished, 2 criteria failed, report inside"), keep the report judgmental and organized, and keep the log complete and boring. In Skopx these roles are separated by design: the timeline is always attached to the run, the report is always the run's final artifact, and whether the agent additionally posts a summary to Slack or email is up to the instructions and grants you give it.

Where reports land, and how teams actually read them

A report only creates value when it intersects a reading habit. Three patterns work reliably.

The workspace as the archive. In Skopx, every run report lives in the agent's run history in the workspace, alongside the timeline, duration, and token count for that run. This is the canonical copy: append-only, complete, always in context. Treat it the way you treat a ticket history, the place you go when you need the full record.

The push summary. For scheduled agents feeding a routine, have the agent deliver a condensed version where the team already lives: a Slack channel, an email. The classic case is a morning brief, where a scheduled agent surveys your tools before you start work and the report is the brief. We describe that pattern fully in the AI agent morning brief. The push copy should link back mentally to the full report, not replace it.

The escalation. Some reports exist to be ignored. An uptime or data-quality watcher that finds nothing should say "nothing found" quietly in run history. When it finds something, that is when a human should hear about it. Success criteria make this pattern reliable: the criteria evaluation is the trigger for whether the report deserves a louder channel.

Match the landing spot to the agent's job. Weekly strategic monitoring earns a document you read with coffee. High-frequency checks earn silence until they do not.

Writing instructions that produce good reports

The report is generated by the model, which means it is shaped by your instructions. Agents built in Skopx's Create Agent are described entirely in plain language, so the reporting spec is just part of the same instructions that define the job. A few practices consistently improve output:

Specify the report structure explicitly. "End your report with these sections: Summary, New findings, Changes since last run, Actions awaiting approval, Could not verify." Models follow structural templates well, and a stable structure makes reports scannable week over week.

Demand evidence per claim. "For every finding, name the source: the email subject, the query, the URL." This single line does more for report trustworthiness than any other instruction.

Authorize brevity. "If nothing changed, say so in one line. Do not pad." Models pad by default because unspecified length reads as a request for thoroughness. Give the agent explicit permission to be short.

Ban invented certainty. "If a tool call failed or returned nothing, report that. Never guess at what the result would have been." This belongs in every agent's instructions without exception.

Tie the report to the criteria. "Address each success criterion by name with a pass or fail and one sentence of justification." This makes the verdict section impossible to skip.

Instruction writing is versioned in Skopx, so you can tighten the reporting spec over time as you see what the agent actually produces, and roll back if an edit makes things worse. The broader craft of writing agent instructions has its own guide in this series.

Where reports fall short

Candor section. Reports have real limits, and pretending otherwise is how teams get burned.

A report describes what the agent believes it did. The step timeline is ground truth for what tools were called and what they returned. The report is an interpretation layered on top, and interpretation can be wrong. The agent can misread a tool result and confidently report the misreading. This is why the timeline exists and why spot-checking early runs is not optional. The habit of comparing report claims against raw steps is covered in AI agent run transparency.

Self-graded criteria are a signal, not an audit. As noted above, fact-shaped criteria grade reliably, judgment-shaped criteria less so. Do not build a compliance process on an agent grading its own essay.

A report cannot cover what the agent could not reach. If a grant was missing, an integration errored, or a budget cap ended the run early, the report can only be as complete as the run was. Skopx surfaces duration and token counts per run, and budget-terminated runs still produce a report, but "the report exists" is not the same as "the job finished." Read the verdict section, not just the summary.

Reports do not replace dashboards. A report is a point-in-time narrative. If what you need is a continuously queryable metric, that is a different tool. Agents are at their best reporting on judgment-shaped questions ("which of these tickets actually matter") rather than replicating what a chart already does.

None of these limits argue against reports. They argue for reading them the way you read a colleague's memo: valuable, usually right, worth trusting more as the track record grows, and never beyond checking.

FAQ

What should an AI agent run report include?

A top summary, findings ordered by importance, evidence for each claim, actions taken and actions awaiting approval, an explicit list of what the agent could not do or verify, and an evaluation against the success criteria defined for the agent. In Skopx this arrives as a markdown document at the end of every run, backed by an expandable step timeline showing the raw tool results behind each claim.

How do I know the report is accurate?

Check it against the step timeline. Every Skopx run records each step with humanized labels that expand into raw tool results, and run history is append-only, so the record cannot be quietly rewritten. Spot-check claims in early runs, and write success criteria around observable facts, which the model grades far more reliably than subjective quality judgments.

Why is the second run's report shorter than the first?

Because of memory. The first run has no baseline, so it surveys everything. From the second run on, the agent compares current state against cursors and baselines stored in its memory and reports only the delta. Second runs are typically cheaper as well, since diffing against a baseline is less work than a full survey.

Can the report include actions the agent has not taken yet?

Yes, and it should. When a write-shaped action falls under an approval tier, Skopx parks it as a pending approval showing the exact call and arguments. The report is where you learn a decision is waiting. Approving executes exactly that parked call once, rejecting executes nothing, and approvals can expire if left unaddressed.

Where do reports go, and can they be sent to Slack or email?

The canonical copy lives in the agent's run history in the Skopx workspace, alongside the timeline, duration, and token count. If the agent has the relevant grants, its instructions can also have it deliver a condensed summary to Slack, email, or wherever your team reads, with the full document remaining in run history as the permanent record.

Does a stopped or failed run still produce a report?

Runs stopped mid-flight or ended by a budget cap still leave their step timeline in history, so the record of what happened up to that point is preserved. Treat any run that did not complete normally as unverified work: read the timeline, check what was and was not done, and rerun if the job matters. Three budget failures auto-pause a Skopx agent so it does not keep burning runs that cannot finish.