Your system can be complicated. Your work shouldn't be.

I came back to my actual job at Sage after several weeks away, and the thing that became obvious almost immediately wasn’t that I’d forgotten anything. It was that I had far more potentially useful connections between things than I could sensibly hold in working memory at once.

There are campaigns, research programmes, customer stories, AI visibility work, events, product priorities and stakeholders who each own one part of a problem, alongside old work that might suddenly matter again and new work that sounds important but might not be. None of it exists in isolation the way it does inside my own thinking about Editorial Intelligence, where I’ve spent months accumulating ideas about judgement, memory, evidence and how knowledge work is changing.

The conventional response to that kind of return is to prioritise: what’s urgent, what’s important, what’s blocked, what does my manager need. Reasonable questions. But turning everything into a task list destroys most of the interesting information. One project connects to research finished six months ago. A customer question in one workstream also matters for a different one. An event that looks like a content opportunity is really a way to test a hypothesis before committing to it. None of that survives being written as “TO DO: write article” — the relationships between things are exactly what a flat list throws away, and the relationships were usually the point.

I don’t think the answer is to simplify those relationships away. I think it’s to put the complexity somewhere else.

The system should carry what I can’t

I’ve made versions of the underlying argument before, from different angles: that accumulated context behaves like capital rather than archive, that AI can let an old thought collide with a new piece of evidence instead of that thought staying wherever it was first had, and that editorial judgement can become infrastructure rather than something rediscovered by whoever happens to be in the room. My GitHub repository, which started as a way to stop losing decisions between AI conversations, is the practical version of all three.

What’s become clearer this week is the shape of the design principle underneath them: the knowledge system should preserve the complexity. The interface with the work should reduce it.

That’s a different objective from the one I used to assume. I’d always taken it as given that a good working system gets simpler over time — fewer tools, fewer folders, one place for everything. I think that’s actually two different claims wearing one piece of advice. The experience of doing the work should get simpler. The system underneath it might need to get considerably more complicated to make that possible.

What that looks like in practice

Concretely: instead of walking into a conversation and explaining an entire mental model — we need a system connecting research, narrative, customer evidence and institutional memory — the useful move is usually smaller. We already have strong evidence answering that question; maybe we improve how people find it, rather than commission another article. Same underlying thinking. Nobody needs the whole map to get the benefit of it existing.

Most people I work with don’t think the way I do about this, and they shouldn’t have to. Someone running a campaign needs the campaign to work. Someone owns AI visibility outcomes on their own terms. My private model of how five things connect is only useful if it changes what I actually recommend, not if I make everyone sit through the model itself.

The test

There’s an obvious way this goes wrong: build the repository, capture everything, tag every thought, design an elaborate routing system, and the knowledge system becomes another job. I’ve come close enough to that to recognise it. So the test has to stay practical. Did remembering this change what I did? Did old research stop unnecessary work? Did a previous conversation improve a new one? If not, it’s storage — possibly sophisticated storage, but still storage.

I originally imagined a good AI memory system as something approaching complete recall: know everything relevant, all the time. I think that’s both unrealistic and the wrong goal. A useful system needs to hold far more than I personally need at any moment, then narrow it aggressively down to the smaller question that actually matters right now. That’s an editorial problem — selection, hierarchy, relevance, timing — dressed up as a technical one.

When I’m back in the middle of a messy week with a dozen possible directions, the measure isn’t how impressive the repository looks. It’s whether I can reach a simpler decision faster: don’t write anything yet, talk to these customers first, reuse this research, drop that idea. More context, more connections, more accumulated history, all in service of doing less. That’s an odd thing to build sophisticated infrastructure for. It might also be where most of its value actually sits.