The agent’s activity log is part of the deliverable

An agent can finish with a short "done, the change is complete" and that tells me nothing about which files it read, which command failed the first time, whether it changed approach halfway or whether the final check looked at the actual target. I need that when I review the work or come back to it later. The full chat transcript doesn't really help either, because it mixes reasoning, source content and tool output into one long scroll, can expose private data and still doesn't say exactly which artefact changed. So I want the activity log delivered with the result, the same way tests and a diff come with a code change.

The basic unit is a run, meaning one attempt at one named job, and a retry is a new run linked to the same job. Each event gets a timestamp, run ID, sequence number, event type, component, target and outcome. Useful event types are things like input resolved, file read, tool called, change proposed, approval received, change applied, check run and target verified. I'd attach the instruction version, tool config version and code revision to the run as references, and keep the log append-only, so a mistake gets a correcting event instead of an edited entry.

The bit I care about most is keeping the request, the tool's response and an independent check as separate events. An exit code of zero or a successful API response doesn't mean the intended state exists. For an external record, the worker should read the target back and compare the fields it meant to change; for a database update, that's affected-row counts plus a query against the destination. The run's final status should come from that verification event. Checks get the same treatment, because "tests passed" is too compressed for a handover. I want each check named with its command, result and an output reference, plus anything skipped and why. If the build passed but no browser check ran, the log should say exactly that.

The handover also needs to say where the system was left. For a repo, that's the branch, commit or uncommitted files, generated artefacts and any process still running; for a data job, the last accepted checkpoint, rejected records and queued retries. I'd generate that snapshot from the environment (repo status, service status, a targeted query) instead of from the agent's memory, and include the exact target so a staging check doesn't get read as production evidence. Scratch files, branches, containers and test records either get removed or listed with a reason and an owner.

Sensitive stuff stays out of the durable log. Prompts, retrieved documents and raw output can hold personal data, client material and tokens, so the log keeps operational facts and references that resolve through the source system's own permissions, and redaction happens at the tool boundary before anything's stored. My test for all this is a small controlled change. I'll compare the generated report with the actual repo and tool state, then give it to someone who didn't watch the run, and any question they can't answer without opening the transcript tells me which event or final-state field is still missing.

Back to that "done, the change is complete" message. It's fine as a summary line, but what I want handed over is the result plus a log showing what was read, what was checked against the real target and where things were left. If someone picking up the work has to open the transcript to answer a basic question, I'd treat the log as unfinished and add the missing event before calling the job done.