Most people's artificial intelligence (AI) sessions vanish when the window closes. Whatever was figured out, whatever was fixed, whatever was tried and abandoned, gone. Mine do not. Every work session is logged to a local, queryable store. It is the least glamorous layer of the workspace and the one I would rebuild first, because it closes the loop: the assistant does not just act, it keeps a record I can mine.
Three Things the Log Unlocks
| Use | What it replaces | What it looks like |
|---|---|---|
| Standups | Reconstructing the week from memory on Monday morning | "What I did" generated from real session activity, grouped by day |
| Search | "I fixed this once, where was it" | Find a past session by keyword, file, or change |
| Self-improvement | A vague sense that something is slow | Usage patterns that show where the friction is |
The first one pays for the whole thing. A standup built from the log is a list of things that actually happened, with the files they touched. A standup built from memory is a list of things you remember feeling busy about. The difference is the same one I keep coming back to in this series: a status that comes from a source, never a status inferred from a date or a mood.
What a Record Needs
Less than you think. A timestamp, the project, a one-line summary, the files touched, and a few tags. That is enough to answer every question I have actually asked the log. The temptation is to capture the full transcript, and you can, but the summary line is what you search, and a record you cannot skim is a record you stop reading.
The habit is to write the record at the end of the session, in the same breath as the commit. If the session was an assistant's, the assistant writes it. If it was mine, I do. Either way it is one command and it is not optional, for the same reason memory entries are not optional: the value is in the completeness, and completeness is a rule, not a mood.
Friction Shows Up in the Counts
The self-improvement row is the one I did not expect to matter. After a month, the counts tell you things. The file touched in the most sessions is the file that needs a tool. The tag that keeps appearing is the skill you have not written yet. The project that shows up every day for a week and then vanishes is the one that was either finished or quietly abandoned, and the log knows which. This is the dispatch rule fed by data instead of by irritation: you do not have to notice you have done something twice, because the count is three.
Take It
The store I run is SQL-backed. The one I am handing you is simpler, so you can start today: session-log.js, no dependencies, writing one JSON record per line to a local file that you can also grep by hand. Four commands.
| Command | What it does |
|---|---|
log "summary" --project p --files a b --tags x | Appends one record with a timestamp |
standup 7 | Everything from the last seven days, grouped by day |
search sitemap | Sessions whose summary, project, files, or tags match |
stats 30 | Projects, files, and tags that appear most in the last thirty days |
When the file outgrows grep, move the two functions that read and append into a database table and keep everything else. The record shape is the part worth keeping. The store is a detail.
This is part of a track on agent tooling and spec-driven development that goes deeper than a field report, with something you can download and run in each one. Free for now while the track grows; the deepest installments become a paid tier later.