Field notes
Work that repeats, written down.
What we have learned building a service that runs the same responsibility every week: permission design, instructions that hold up unattended, and how to tell a real result from a fluent one.
Latest — Company
Work on Repeat is live
The schedule-first home for recurring AI work is open to everyone — what it does, who it serves, how permissions work, and what it does not do yet.
Read itIn this issue
- 01Work on Repeat is live
- 02The work that deserves a schedule
- 03Why every tool starts disabled
- 04Prompts don't survive contact with a schedule
All posts
Operating model
The work that deserves a schedule
A four-part test for telling which recurring work should become a routine, and which should stay a conversation.
4 min read
Trust
Why every tool starts disabled
Permission design for AI that acts — why capability and autonomy are two separate grants, and why a server's own safety hints cannot be trusted.
4 min read
Craft
Prompts don't survive contact with a schedule
What changes when the same instruction runs fifty times without you — and the five edits that make instructions hold up.
4 min read
Playbook
A weekly security audit that never gets write access
How to put a recurring security review on a schedule, with read-only tools, a defined diff window, and evidence you can check.
4 min read
Engineering
Cron is not the hard part
An honest inventory of what you build when you build scheduled AI work yourself — and which pieces are worth owning.
4 min read
Craft
How to read a run trace
The output tells you what the model concluded. The trace tells you what it actually looked at — and only one of those can be checked.
3 min read
Put one of these on a schedule.
Define the responsibility, approve its tools, prove one run, then let the schedule own it.