So for managing the SAE project I’ve evolved a very simple memory system to keep track of the work and make sure everything is logged. The core of it is the “findings” doc, a structured note the agent writes to document a research finding or insight. They don’t need to be grand or meet any sort of significance bar. Very often there’s a small finding every few turns, in the format “we tried this. It didn’t work. We changed it, and it still didn’t work. Thing N+1 finally worked.”

As these accumulated, we started to have follow-ups and retractions. Findings would build into new findings. Some days had a couple dozen of them, and it was all getting a bit unwieldy. A few months ago I built a small daily script that prompts a long-running agent (hosted in a tmux session) to aggregate findings into a daily chronology doc. It weaves them into a narrative of the day and links that to the previous days’ work. I read it first thing in the morning to remind myself of the state of the work.

The system-side benefit of all this is simpler onboarding of new agents. These days, when I have a new idea, I state it and ask the agent to scan recent findings and chronology for context. It usually comes back with references to everything it needs.

Daily is the Wrong Slice

Having accumulated a few months’ worth of these, it was clear that daily is a good format for snapshots but a bad one for longitudinal threads. I often have several threads of ideas running at the same time, and they split and merge as the situation evolves. I find myself wanting to say “get context on the Intra-model Disagreement arc,” but it would take the agent a bunch of grepping to get the gist.

What I realized is that I need a second summarization track, one that follows arcs and not just dates. So I built it. Well, “built” is overselling it. More like I established a convention for a particular style of writing. When an arc feels like it’s at an end (or has at least hit a milestone) I ask the summarization agent to write an arc document. The prompt is to document the following:

1. The impetus - why did we think it was worth pursuing
2. The twists and turns - there’s always twists and turns
3. The result - what did we find?
4. The legacy - what was built and preserved?

The agent then does its fan-out and research thing, hunting down finding entries and daily logs to thread the story together. I give the output a quick read, maybe suggest some feedback or flag ideas it missed.

Arcs are a Rearview Mirror Construction

The immediately useful outcome of instituting arcs is memory consolidation. Claude Code kept warning that MEMORY.md was too large, then burning cycles mid-turn compacting it. Noisy and annoying. The arc docs format streamlines all of that, which lets MEMORY.md become an index that points at the arc instead of logging everything inline. When the agent needs detailed context about a past decision, the arc doc supplies it directly — and links down to the individual finding entries when it needs more depth.

The construct though is fundamentally backward-looking. With a finding, I can tell the agent “log a finding here” and it is about the current moment. With an arc, I have to decide in retrospect that something has graduated. Arcs rarely announce themselves in advance. They begin as hunches and surprises, and it’s only once we start digging that the rabbit hole turns out to go deep in several directions. And it is only after things bottom out (or I run out of patience/budget) that I sometimes realize: oh, this has been an arc, scattered over several days and a dozen finding docs. Writing it up consolidates the story, both for the system and for my own head.

I suppose this is the whole Kierkegaard bit — life can only be understood backwards, but must be lived forwards — writ small in the agentic coding process.