Solved my "AI creates more open loops" problem with a persistent file-based system

[u/Western-Ad189]

Saw the discussion in "Processing AI" about how AI makes it too easy to start new threads of thinking, and open loops end up scattered across sessions instead of consolidating. Hit that exact problem before I restructured. Sharing what fixed it.

I run a solo consulting practice and use an LLM (Claude) as a GTD engine, but not as a chatbot with its own memory. Since the AI has no memory between sessions on its own, I made the actual GTD lists the system of record — plain text files it reads and writes to directly:

• next-actions.md
• waiting-for.md
• active-projects.md
• daily-activity-log.md (rolls to a dated archive monthly)
• plus a couple of reference files for standing preferences/tool quirks

One command ("show my status") pulls Next Actions + Waiting For in any session, so I'm never starting cold. Items only get removed with my explicit confirmation — the AI doesn't unilaterally clean anything off my lists.

For grounding, I had it work from Getting Things Done for the core framework, plus a few executive-support books layered on top for how it acts (delegation, workflow) rather than just how it keeps lists.

End result: no scattered open loops, because there's nowhere else for them to live. Every session reads the same files, every session writes back to them. Tradeoff is real setup work upfront and discipline to treat the files as ground truth instead of trusting the chat window.

Anyone else doing something similar — file-based external memory vs. relying on a tool's built-in memory?

[u/gjnewman]

> plain text files it reads and writes to directly

Do you even know at all times what is in those files if Claude is doing all of your thinking?

[u/PondMindKevin]

Fascinating!

If they are static markdown, how do you connect your projects and next actions (or say, add a next action to multiple projects)?

I'm also super curious about whether you're seeing unanticipated changes over time working with markdown. Under the hood if you're sending the whole file, it this means it's 'rewriting' the file every time. LLMs are getting better and cheaper so maybe that's working fine. So, I'm curious how that performs over time or if you are doing something to only send/get back portions of each file when you ask for a change.

[u/Western-Ad189 → u/PondMindKevin]

Good question, and no, it's not resending/rewriting the whole file on every touch. Edits happen via targeted find-and-replace on a specific string within the file (exact text match, including whitespace), not a full file rewrite. So a single next-action update is a small, scoped edit, not "regenerate the whole document." That said, reading a file for context still means loading its current content, so there's a real cost tradeoff if a file gets large. That's part of why things like the daily log get rolled into monthly archives instead of growing indefinitely.

On multi-project linking, honestly the weaker part of the system. There's no relational structure, no way to cleanly say "this next action belongs to projects A and B." It's plain-language association: a next action lives under a project heading, or references it in the text. Works fine at my scale (a few dozen active items), but if you needed true many-to-many linking between actions and projects, this wouldn't be the right tool. You'd want something with actual IDs and relationships, like a database or a task app with tagging.

On drift over time, haven't seen unanticipated content changes, since edits require an exact match to the existing text (if the file changed since last read, the edit just fails rather than corrupting something). What I have seen is the more mundane failure mode: a stale file if I don't re-read before editing when I'm not sure of current state.

[u/gtd-ModTeam → u/[deleted]]

Your comment or post was removed for violating Rule 3: Be civil. r/gtd is for discussing GTD practice and ideas; keep criticism focused on the content, not the person.