An AI agent run log is the paper version of the line most automations never write: date, task, result, notes, one row per run. This ai automation log template is a free printable two-page set. Page one is a run table with 10 write-in rows, each with a date, the task the run did, OK/FIX result circles, and a notes column. Page two is the planning side: a recurring-jobs box with 5 lines, a what-to-automate-next box with 3, and 4 opinion tips. It is a tracking sheet built for printing, not a dashboard to log into. The pre-build side of the same work lives in the agent workflow checklist, and what to watch after launch is in the AI agent monitoring basics guide.
How to use this page: print both pages at 100% scale. On page one, one row per run: the date you ran it, what the run was supposed to do, and a circle on the result you actually got, OK or FIX, plus whatever notes the future-you will ask for. Nothing on the sheet names the tasks; your runs name themselves. On page two, the recurring-jobs lines hold the runs that fire on a schedule, and the next-automation box turns the rows you circled FIX, or did by hand twice, into your next build decision.
Nothing on the sheets is pre-filled: the 10 rows, the 5 lines, and the 3 lines are empty on purpose. The same two pages work for a script that calls a model API, a scheduled job, or a run inside an agent framework, because the sheet records what happened and assumes nothing about what ran it.
One row per run. Write the date, the task the run did, circle OK or FIX for the result, and use Notes for what the row should remember.
| Date | Task (write it in) | Result (circle) | Notes (write it in) |
|---|---|---|---|
| 1. ____________ | OK FIX | ||
| 2. ____________ | OK FIX | ||
| 3. ____________ | OK FIX | ||
| 4. ____________ | OK FIX | ||
| 5. ____________ | OK FIX | ||
| 6. ____________ | OK FIX | ||
| 7. ____________ | OK FIX | ||
| 8. ____________ | OK FIX | ||
| 9. ____________ | OK FIX | ||
| 10. ____________ (the run you almost skipped logging) | OK FIX |
Ten rows is a sitting, not a ceiling: when the table fills mid-week, start a fresh print and keep the pages in order, because the sequence of OK and FIX circles is the part that shows patterns.
What goes in Notes. The input you ran, where the output landed, how long the run took, and what it cost. When a run misbehaves, those four fields are where debugging starts; without them, a FIX circle is a mood, not a lead.
Jobs that fire on a schedule run whether or not anyone is watching, and the next-automation box works only if you fill it from rows you actually circled.
| 1. | ____________ (the job that fires even on your day off) |
| 2. | ____________ |
| 3. | ____________ |
| 4. | ____________ |
| 5. | ____________ |
Give each line its schedule in the same words your scheduler uses, so a missing run is obvious the day it happens instead of the month.
| Done by hand once this week | |
| Done by hand twice or more | |
| First automation, with a stop condition written |
These two pages are a tracking sheet: date lines, task lines, circles, and boxes. They hold no agent code, no tool-specific setup steps, and no performance figures, and they are not a productivity or outcome guarantee of any kind.
Ten rows record what happened; they do not structure what happens next. The README of the pack this page belongs to opens with the reason that paperwork exists:
“Agent products fail on paperwork, not code: the spec was never written, the prompt grew by accretion, the incident got fixed but not documented. These templates are the paperwork, pre-structured so you only answer the questions.”
- Agent-OS Template Pack README, Why this exists
The Agent-OS Template Pack is 20 markdown templates for the paperwork around runs like these: the spec written before the build, the system prompt with boundaries, the eval checklist run before release, the incident report written after one, and the runbook that keeps the next incident from repeating. You fill in the [BRACKETS], delete the headings you do not need, and the templates make no assumptions about your stack, model, or platform. The product README lists the contents verbatim:
- Product specs (3): full v1 spec, single-feature spec, launch spec with success bar
- System prompts (4): general agent, support agent, research agent, workflow automation — each with boundaries, refusal lines, and example blocks
- Eval checklists (3): pre-release checklist, prompt quality grading, user testing script
- Incident/runbook (2): post-incident report format, one-page triage runbook
- Onboarding (2): new-user guide, one-screen quick start card
- Changelog/release notes (2): running changelog format, public release notes template
- Pricing copy (2): pricing page skeleton, purchase-unblocking FAQ
- Support macros (2): seven common-ticket replies, six hard-conversation replies
According to the same README, index.md maps all 20 templates to the moment you need each one, and searching for `[` in any template surfaces every placeholder. The templates structure decisions and docs; the technical content stays yours.
one-time · 20 markdown templates · instant download · personal + commercial use, no resale of the files as-is