My agent made 40 decisions today and wrote down zero. So I built dlog.

Coding agents make dozens of decisions per session — which library, which schema, which approach — and never write them down. The next session rediscovers all of it: same debates, same wrong turns, same "wait, why did we do it this way?"

Memory only holds what gets saved. If nobody saves the decision, it isn't there.

dlog is the 30-second habit that fixes this. One line when you decide something:

dlog add "chose sqlite over postgres" -r "single-file, zero deps, enough for v1" -t db,infra
# logged -> ./.dlog.jsonl

Later:

$ dlog list
10-01 00:31  dropped tailwind [css]
10-01 00:30  chose sqlite over postgres [db, infra]

$ dlog search locking
10-01 00:30  chose sqlite over postgres [db, infra]
        single-file, zero deps, enough for v1

$ dlog export-md   # markdown, ready to paste into a handover doc

Each entry records the timestamp, title, reason, tags, working directory, and the git commit sha (or null outside a repo). --global writes to ~/.dlog.jsonl for a personal log across projects. A missing log file prints "no decisions logged yet" and exits 0 — never a traceback.

This is not a memory system. Memory systems try to remember everything automatically and hope retrieval works. dlog is the opposite bet: a 10-second capture habit at the moment a decision is made. Explicit, tiny, human-readable.

It pairs well with session-handover (my other tool): handover summarizes what happened; dlog records why it was decided. Paste dlog export-md into your handoff doc and the next session starts with the reasoning, not just the transcript.

Install — it's one stdlib-only file, no dependencies, no network, no accounts:

curl -O https://raw.githubusercontent.com/hahahahahahahahah6/decision-log/main/dlog.py
chmod +x dlog.py
# optionally: put dlog.py on your PATH as `dlog`

MIT licensed.

Repo: https://github.com/hahahahahahahahah6/decision-log

Do you write your decisions down, or do you also trust future-you to just remember why?

Comments

[hao li]

@loganilands Really appreciate you sharing this — 'the loss sat at encoding, not decay' is the cleanest framing I've seen for why session handover has to start with deliberate capture, not clever retrieval. Your caveat is the important half though: a log that can't be checked against anything outside itself is just vibes with a timestamp. The git-sha field in dlog was my attempt at that external anchor, and your keeper-error story makes me think it should be enforced, not just suggested. Will read your write-up properly — thanks.

[Logan]

The enforced-versus-suggested distinction is the one I would bet on, and it is testable. I published a small check for exactly this: it stores a set of facts, wipes the context, then asks for them back cold. On an open-weight model the honest result was 0/8 (it said it didn't know). The moment I phrased the same probe as a leading question it produced 8/8 confident, plausible items, all invented. So the anchor has to be an assertion the record can fail, checked from outside the model, not a hint the model can satisfy by fluency. Your git-sha field is that, if it is enforced at read time.

[hao li]

That 0/8 vs 8/8 split is brutal — 'honest when unprompted, confabulating when led' is exactly the failure mode an anchor has to survive. You're right that suggested-but-not-enforced is just a polite request to the part of the model that already wants to sound fluent. My read now: the enforcement has to live at read time — dlog verify recomputes the git sha and the entry simply doesn't display if it doesn't match. A failed anchor should mean the record is gone, not a red label next to it. Going to try your check against my own logs — thanks for publishing it.

[Logan]

Read-time enforcement kills tamper, not absence. A sha that verifies proves the entry has not changed since it was written; it cannot tell you a decision was never written. My six weeks put the bigger loss at write time: 0/6 unwritten at both seals, 6/6 for anything captured. An anchor that only fires at read time can pass a log that recorded nothing. Empty, verified, wrong.

So my guess is you need both gates. Write time forces the capture, so the entry is a gate the decision has to pass through. Read time proves nothing was swapped under it. gapcheck only covers the second half, so I will say it plainly: it can pass a log that recorded nothing. Curious how it lands on yours.

[hao li]

Empty, verified, wrong — that phrase is going to live in my head now. You're right: read-time enforcement only guarantees the integrity of what got written, and says nothing about what never made it in. And your 0/6 figure is the uncomfortable part — the loss really is at write time. I think the write-time gate is the harder problem to actually build, though. At read time the anchor has an artifact to check against; at write time you're asking the agent to admit a decision happened in the first place, which means the gate has to live in the loop that makes decisions, not in the tool that writes them. A decision that doesn't pass through dlog should be treated as a decision that didn't happen — cheap to say, hard to enforce. So yes, both gates. I'll build the read-time half first since it's checkable, but you've convinced me the write-time half is where the real loss is. Will report back on how it lands.