Sponsored by
Full transparency: beehiiv runs this whole newsletter, so when they offered to sponsor, it was an easy yes. I only build on tools I actually use.
Most of my week was not about building something new. It was about catching the moment two of my automations started lying to me, one by repeating itself and one by losing track of what it had already done. Neither was dramatic. Both were the kind of quiet drift that costs you trust in a system right when you need it most. So this issue is about memory: the boring layer that decides whether an automation is something you can walk away from or something you have to babysit.
Build Log: the run ledger that gave an automation a memory
Here is the build. Every Sunday a scheduled task writes my whole content kit: a newsletter, three LinkedIn posts, a carousel, a podcast outline, and more. It worked. The problem was that each run started from zero. It had no idea what last week's run had said, so it would happily re-pitch the same shipped item, reuse the same Try This tip, and pull the same quote line a second week in a row. To a reader that reads as a tired account, even when the underlying work is fresh.
The fix was not a smarter model. It was a memory. I built an append-only run ledger, one plain text file the task reads before it writes a single word and adds to right after it finishes. Each entry records what shipped that week, the Try This topic, the quote line, the three curated reads, and which idea-bank pieces got used. The first instruction in the task is now: read the ledger, then do not repeat anything in it.
That one move fixed three problems at once. The content stopped repeating itself. The off-week and on-week rhythm got tracked in the same file, so the newsletter knows when there is a new podcast episode and when to rotate in a feature like this one. And because the ledger is append-only, I get an honest history of what the system did, not what I hoped it did. The same week, I found my follow-up email engine sending a message without advancing its own counter, which would have double-sent real prospects on the next run. Same root cause: a system with no reliable memory of its own actions. The lesson I keep relearning is that the intelligence is rarely the bottleneck. The memory is.
Worth Your Time
Advancing Claude for Education by Anthropic. Anthropic expanded its education push: a free AI Fluency course, new partner institutions, and a move toward letting students pull readings and lecture material straight into a conversation. I keep this one for the planning meeting where someone asks where this is all heading. The direction is less about the chatbot and more about the context you feed it.
The Five Questions That Turn a Messy Task Into an AI Loop by Nate Jones. Five questions that turn a recurring task into an automated loop, plus a prompt that stops you before you point the thing at something you cannot undo. This is the exact discipline behind everything I shipped this week. If you only read one thing here, read the part about scoping a loop tight before you build it.
Where Do Schools Go From Here? by Stephen Fitzpatrick. After a summer of AI-and-cheating arguments, he makes the case that we have to stop fighting long enough to ask what school is for. The point I would carry into a leadership room is his one about access: if you want older students to learn to use AI well, you cannot hand them a hobbled version of it.
What’s next is almost here.
On July 16th at 1PM ET, beehiiv is going live with a look at the future of publishing, audience growth, and digital business.
What started as a newsletter platform has evolved into something much bigger: a place where creators and brands can grow, monetize, and own their audiences without stitching together half the internet to make it work.
The next chapter starts live at the Summer Release Event.
Join us to see what’s coming next.
Try This: give your recurring automation a run ledger
If you have anything that runs on a schedule, a weekly report, a digest, a batch of emails, a social post, give it a memory this week. It takes about fifteen minutes and it is the difference between a system you trust and one you check by hand every time.
Step one: make one plain text file and call it a ledger. Put it where the automation can read and write to it. A note, a doc, a text file, it does not matter. The only rule is that it is append-only. You add to the top each run and you never edit old entries. That constraint is what makes it an honest record.
Step two: decide the five or six things worth remembering, and only those. For my content task it is the date, what shipped, the main topic, the headline line, and the sources used. For an email automation it might be who got contacted, what was sent, and the date. Keep it skimmable. A ledger nobody can read in ten seconds is a ledger nobody reads.
Step three: change the order of operations. The first thing the automation does is read the ledger. The last thing it does is write to it. In between, add one explicit instruction: do not repeat anything already in the ledger. That single line is what stops the repetition and the drift.
Step four: read it yourself once a week. The ledger is not only for the machine. It is the fastest honest summary of what your system did while you were not looking, and it is usually where you spot the bug before it spots your customers. Mine caught a double-send waiting to happen. Yours will catch something too.
You do not need code for this. A shared doc with a strict "add to the top, never edit" rule does the same job. The value is not the file. It is forcing the work to remember itself.
That's it for this one. If something here landed, share it with someone who'd get something out of it. If it didn't, that's part of the deal too. You can find more of what I'm working on at evalveconsulting.com, or book a call if you want to talk through what you're dealing with.
Talk soon,
Chris