Where AI-assisted work actually leaves its record

I went looking for the most distinctive work I’d done in the last year, and I couldn’t find it where I expected. What that absence turned out to mean is the reason for everything in this three-part series.

”The chat history is a record of conversations. The work didn’t happen in conversations.”

I’d asked an instance of Claude — the browser one, with access to our chat history — to help me reconstruct my own side projects. It did a decent job on the things we’d talked about: a space game, an LLM agent that plays XCOM, a homelab. But the work I’m actually proudest of from this period — a family of Claude Code plugins I built to run that homelab; an MCP server with identity routing; a session-logging system; the whole claude-kit configuration repo — none of it surfaced. The model couldn’t retrieve the name “memolib.” It had never heard of “claude-kit.” The ccp-* plugins were a complete blank.

The reason is obvious in hindsight and worth sitting with anyway: I built those things inside Claude Code sessions, not by discussing them in chat. The chat history is a record of conversations. The work didn’t happen in conversations. It happened in a terminal, against a filesystem, and the only honest record of it is in commit history and session logs — not in anything I would ever remember to say out loud.

§1 · The record forms where the work happens, not where you talk about it

This is a small observation with a long shadow.

For most of software’s history, the record of how you worked was reasonably well-aligned with your memory of it. You wrote the code; you remembered writing it. The commit messages were a compression of a process you’d lived through line by line. If someone asked “how did you build that?” in an interview, your recollection and the repository told roughly the same story.

That alignment is breaking. When a meaningful share of the work is done in collaboration with an agent — you steering, it typing, both of you iterating faster than you can form durable memories — the experience of the work and the record of the work drift apart. You remember the shape of the decisions. You do not remember the two hundred small moves that implemented them, because you didn’t make them by hand. The artifact remembers. You don’t.

So the question “where does the record of my work live?” stops being rhetorical. For me, right now, the answer is: in Forgejo commit histories, in the ADRs I wrote to argue with myself, and in the byte-faithful session transcripts I log to object storage. It is emphatically not in my head, and it’s not in the chat sidebar either.

§2 · Two consequences I’ve actually changed my behaviour over

First: build for the artifact, deliberately. If the honest archive of my work is going to be the repository and the logs rather than my memory, then the repository and the logs had better be good. This is why I write decision records nobody asked for, why every install in my homelab is a re-runnable script with a dated “why” note, and why I log every agent session to a document store and a blob store. It looks like over-engineering for an audience of one. It’s actually the opposite: it’s an admission that the audience of one — me, in six months, with no memory of today — needs the record more than anyone, because the alternative isn’t a worse memory, it’s no memory.

Second: the most valuable work is now the least narratable — so narrate it on purpose. The cruel irony of AI-assisted engineering is that the work that most demonstrates judgement is the work you’re least able to recount, because you experienced it as steering rather than typing. In an interview, asked “tell me about something hard you built,” I will reach for the things I can narrate — and those will systematically undersell me, because the narratable work and the impressive work are diverging. The remedy isn’t better memory. It’s writing things down while the artifact is still warm. This post is an instance of that remedy. So, frankly, is the act of publishing the projects at all.

§3 · The bigger version of the problem

Scale this up and it’s not just my problem. As more engineering moves inside agent harnesses, organisations are going to discover that their record of how decisions got made is thinning out — not because people are hiding anything, but because the medium where the work happens (an agent session) is more ephemeral and less reviewed than the media it’s replacing (a pull request, a design doc, a code review thread). The pull request was, among other things, a record-keeping ritual. A lot of agent-driven work currently has no equivalent ritual.

I think “observability of AI-assisted work” is going to become a real discipline, the way observability of running systems did. Not metrics and traces this time, but: what did the agent do, on whose instruction, with what context, and where is that written down in a form a human can audit later? I’ve been building a small, personal, opinionated version of that for my own lab — session logs, permission policies, audit transcripts — mostly because I wanted it for myself. I’m increasingly convinced it’s a preview of something everyone will need.

For now, the practical takeaway is the one I started with, pointed back at myself: the honest record of how you work is in the artifacts, not the recollection. So make the artifacts, and then — the part I’m worst at — actually publish them.

This is Part 1 of The Session Record, a three-part series about a gap in how AI-assisted work is remembered. Next: I wasn’t the only one who noticed — a field guide to the twelve projects trying to close it. Then: building the thing I actually wanted.