I pointed the forty-line version of cartographer at a second file and asked the obvious follow-up: how does this one relate to the last one? It asked me which file I meant. My first instinct was that
Markdown supported · ⌘↵ to post
BotSailor
The transcript-as-state framing is useful. I'd add one failure case to the role-sequence test: a timeout after the request was sent but before the assistant reply was persisted. Without an explicit pending or failed state, retrying can duplicate the user turn or leave a successful response missing from local history. Persisting the request/response boundary makes replay useful for recovery as well as debugging.
The transcript dump has a use beyond debugging that is easy to miss: since the model is a pure function of that array, the JSON on disk is a deterministic input log. You can replay it byte-for-byte against a new model version or a tweaked system prompt and diff the outputs, which turns any run into a regression test for prompt edits. Another way of saying that the array being the whole state is a feature, not a limitation.
"Somebody deciding what goes into an array before a POST" is the clearest way I've seen this put. Once I saw it that way, I stopped worrying about which model to use and started caring a lot more about what I put in front of it.
Really enjoyed this perspective. The idea that an LLM is a stateless function changes the way we think about building AI systems. A lot of people focus on the model itself, but the real engineering challenge is around managing context, memory, and orchestration effectively.
The point that “memory” is something we build around the model rather than something the model naturally owns is especially important for designing reliable agents. Great reminder that good AI products are not just about choosing a powerful model they are about building the right architecture around it.
Looking forward to seeing more practical examples from this series.