When I sat down with Emma Kriskinans of Tyk for a conversation about the middle ground on AI, she described a working habit that I found interesting. Every time she figures out how to do something, she writes it up — a file, a fake blog post, whatever you want to call it — that records not just what she built but “what was my thinking process.” Months later, when she comes back and asks how did I build this tool, she does not go digging through conversation history. She reads the thing she wrote. Her reason for doing it that way is entirely practical and I have not heard anyone say it this plainly: re-reading a long conversation history is powerful, but it burns an enormous number of tokens, and the README does not carry the thinking. So she writes the thinking down separately, on purpose, for a reader who does not exist yet — a later version of herself.
My reaction on the recording was immediate, and I want to unpack it here because it is a useful thing I have realized about my own work in a while. What she described is what API Evangelist has always been for me. Before there was any AI to hand it to, I was writing three to five posts a day, for years, and it was mostly stream of consciousness. Eight months would go by and I would think — wait, there was that one company I looked at — and I would go search my own blog, and there it was. Exactly what I thought about them at the time, with the date on it. I did not build that archive as a memory system. I built it as a publishing habit and it turned into a memory system, which is a much more interesting thing to have accidentally built.
There are more than five thousand posts in the archive right now, and it starts in 2010. I have described how the research and writing actually works before, but I always described it as a publishing process. It is not. It is a retrieval process with publishing as the side effect. Every post is a dated, addressable record of what I understood on the day I understood it, written in enough detail that I can reconstruct the reasoning rather than just the conclusion. That last part is the whole trick, and it is the part Emma named better than I ever have. A conclusion does not survive contact with a changed world. The thinking behind the conclusion does, because when the facts move you can go back and see which of your assumptions moved with them.
What has changed is not the writing. It is that something else reads it now. Over the past couple of years I retooled that archive so it is not just a website — there is a search layer at search.apievangelist.com, there is an API, and there is an MCP server on top of it. Same five thousand-plus posts. New consumer. And here is the part worth sitting with: I did not have to go build a knowledge base for AI. I had one. I had been maintaining it daily for sixteen years for an audience of one, and the work of making it useful to a machine was almost entirely plumbing — dates, structure, tags, a search index, a contract. The corpus was already there because I had been writing for the version of me who comes back in eight months, and it turns out that reader and an agent want almost exactly the same thing.
This is why the current scramble over memory files reads strangely to me. Everyone is standing up their CLAUDE.md, their memory.md, their AGENTS.md, and as I said on that same call, I do not think there is a canonical set of files everyone should use — markdown became the control plane and every platform is putting its own name on the same idea. The file name is not the interesting question. The interesting question is what goes in it, and the answer that two people arrived at from completely opposite ends — a marketer at a gateway company in 2026 and an API blogger in 2010 — is the same answer. You write down what you did and why you did it, you date it, and you keep it where you can find it again.
Emma also named the honest problem with the practice, which I appreciated, because most people describing a workflow do not tell you where it strains: it might get more unwieldy the more she does it, since it keeps creating more and more content. I can answer that one from the far end of the curve. Yes, it becomes unwieldy. Sixteen years and five thousand posts is genuinely unwieldy. But the unwieldiness turns out not to be the problem — the volume is only a liability if you cannot retrieve from it, and it is an enormous asset the moment you can. What makes an archive survivable at scale is boring: consistent structure, a date on everything, and a real search layer over the top. She has one mechanism for this that I want to steal outright — a rule that nags her when a file has not been touched in ninety days, so staleness surfaces itself rather than quietly rotting. That is exactly the kind of thing I check other people’s APIs for and have never once run against my own writing.
I have argued that context engineering is governance — that deciding what a consumer gets to see is a policy act, not a prompt trick. This is the personal-practice half of that same argument. The context you hand an agent has to come from somewhere, and the highest quality source available to you is the one nobody else has: a written record of your own reasoning over time. You cannot buy that. You cannot generate it. It only exists if somebody wrote it down while they still remembered why.
So the advice, such as it is: write the fake blog post. Write it when you figure something out, while the reasoning is still in your hands, and write the reasoning rather than the result. It does not matter whether anyone reads it. For sixteen years the main beneficiary of API Evangelist was me, and the audience — and now the agents — showed up to a thing that was already built. That is not a bad trade for a habit that costs twenty minutes a day.
