Logs are usually written for engineers. A run log for an assistant has a different reader: someone who wants to check the work, quickly, without learning the internals.
The reader’s questions
- Did it run when it should have?
- What did it do?
- Did it ask me for anything?
- Did anything fail?
A good log answers these four in the first screen.
A sketch
Friday status summary, run 14 · 15:00 · succeeded
- Trigger: schedule, Fridays at 15:00.
- Read 12 closed tasks from the project tracker.
- Grouped them into 3 projects.
- Drafted summary (5 bullets).
- Approval requested at 15:01, approved at 15:09 with one edit.
- Posted to the team channel at 15:09.
This is an example of the format, not real data.
What belongs
Counts, names of sources, times, approvals, and links to the underlying items.
What does not belong
Raw model output in the main view, internal identifiers, and anything that makes the reader scroll to find the result. It can live behind a “details” link for the person who wants it.
Failure should be loud and specific
When a step fails, the log should say which step, what it was trying to do, and what the likely cause is, for example that a connection lost its permission. Then it should offer the obvious next action, such as reconnecting.
Retention
Logs are useful, but they hold information about your work. We let you choose how long run history is kept and delete it whenever you like.
Leave a Reply