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 — 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.
Read itIn this issue
- 01The work that deserves a schedule
- 02Why every tool starts disabled
- 03Prompts don't survive contact with a schedule
- 04A weekly security audit that never gets write access
All posts
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.