Turn the audit log into a weekly change report

Once an agent starts doing real work on your site, the question stops being “can it write” and becomes “what did it write.” The plugin keeps its own audit log of every ability call, so instead of guessing, you can have the agent read that log back to you as a plain weekly report.

The catch is deliberate. Reading the log takes the manage-options capability, which a properly scoped agent user should not have. So this is a report you run wearing your admin hat, looking down at the work the agent did under much tighter permissions.

Read this plugin's own activity log and turn it into a weekly change report.
Read only.

Go newest first, 200 rows a page, and keep paging until created_at (it is UTC)
is older than seven days ago. The read has no date filter, so that is the only
way to bound it. If it takes more than five pages, stop and tell me how far
back you got instead of guessing at the rest.

Set aside rows that are not tool calls: ability "(transport)", an ability
starting with "oauth:", "aafm/write-outcome", "aafm/activity-log-cleared",
"aafm/read-only-mode", "aafm/high-risk-abilities-unlocked",
"aafm/review-publish", "aafm/review-discard", any ability that does not start
with "aafm/" or "aafm-bridge/", any row whose detail starts with "Enabled ",
"Disabled " or "Blocked " (someone switching an ability on or off in wp-admin),
and any denied row with no acting user. Count those on one line.
Group everything else by ability and by status, so I can see how many create,
update, and delete calls ran and how many succeeded, errored, or were denied.
Break the activity down by day, and note which account each run acted as.

I know the log records the argument keys but not the values, so do not guess at
specific post IDs; just tell me what ran, how often, and whether it worked. Put
the totals at the top.

Why this is safe to run

The activity log read is exactly that, a read. It cannot alter a single row of history, so running the report can never change what the log says or what the site looks like.

The honesty of the report comes from what the log deliberately withholds. It stores each call’s ability name, status, acting account, timestamp, the keys of the arguments, and a short note of the identifiers touched, but never the free-text content of those arguments. So the report can tell you that a run of updates happened and whether they landed, without leaking the contents of those calls. When you need the specific before-and-after on a given post, that lives in the post’s revisions, which is the draft-first change-review recipe’s job. Keeping this read behind manage-options is the point: the agent works on a short leash, and the oversight sits above it with you.

Cross-check it against the Activity Log tab

Since 1.9.0 the tab opens with a 7-day summary: calls, success rate, denied, errors and the five busiest tools. Put the agent’s totals next to it. After the prompt sets the non-call rows aside, the two should land within a few rows of each other. The card refreshes about once a minute and counts agent tool calls only, so expect small gaps, not exact matches.

For anything the report flags, the tab has what the agent cannot return: the refusal reason on each denied call, the connection name, the source IP and the duration. Filter by tool or user, set the dates, and Export CSV if you want the week in a spreadsheet.

Already connected? Skip the paste. Ask your agent, as an admin, for the “weekly change report” recipe, or just ask what it has been doing this week, and it runs the same read on your own log.