Article 2 of 12 · ARTHA Craft
The AI agent's statelessness is not a bug. It's the most important design constraint nobody talks about.
For weeks, my entire team was frustrated with our AI coding agent.
It kept forgetting things. Important things. Architecture decisions. Module boundaries. The reason we chose this approach over that one. Developers re-explaining the same constraints in every session. Standups turning into "wait, didn't we already decide this?" The frustration wasn't mine alone — it was sitting across the whole team. Then I stopped being frustrated — not because the problem went away. Because I finally understood what the problem actually was.
We tried longer prompts. Better prompts. More detailed prompts. We tried pasting previous conversations in. We tried summarising decisions at the start of each session. It helped. A little. For a while. Then it didn't.
The team was losing hours every week not to bad code — but to repetition. Re-briefing. Re-aligning. Re-explaining history to a tool that had none.
And eventually — after enough wasted sessions, enough rebuilt decisions, enough tension in standups — something shifted. Not the tool. Not the model. My understanding of what we were actually working with.
Not because the technology is immature. Not because the model is limited. Not because the tool needs a better memory feature.
This is not a bug waiting to be fixed. It is a constraint. A hard, deliberate, fundamental constraint — as real as the laws of physics in the domain of software.
And here is what 25 years of architecture has taught me about constraints:
The HTTP Analogy
The internet is stateless. HTTP has no memory between requests. Every call arrives without history, without context, without any knowledge of what came before it.
Did we declare HTTP broken and wait for someone to fix it? No. We built sessions. We built tokens. We built cookies. We built databases. We designed an entire layer of infrastructure whose sole job was to carry state across a stateless protocol.
And the web works. Not despite statelessness — because we stopped fighting it and started engineering around it.
The agent is the stateless protocol. Your documentation is the session layer. [2] The context you hand it at the start of each session is the token that carries state across the gap.
The question was never "how do I make the agent remember?"
The question was always "how do I carry the right context across a stateless boundary?"
❌ Without the reframe
Open a chat. Re-explain the architecture. Re-explain the constraints. Re-explain the decision from last Tuesday. Spend 20 minutes getting the agent back to where you were. Build on a fragile foundation held together by a single conversation window that disappears when you close the tab.
✅ With the reframe
Open a chat. Hand the agent a structured document — what the platform is, what was built last session, where you stopped, what is locked, what is frozen, what is next. The agent reads it. Reports position. Executes. Zero re-explaining. Zero drift. Zero "didn't we already settle this?"
Same agent. Same stateless architecture. Completely different outcome.
The difference is not the tool. It is the discipline of the architect sitting in front of it.
This is the hardest mindset shift — and the most important one.
A colleague carries shared context. They were in the meeting. They remember the decision. They know what you mean when you say "the module we froze last month." History is shared. You do not re-explain it.
The AI agent is not that. And once you accept what it actually is — you can work with it at a level that the colleague mindset never allows.
The architects who have accepted this are building faster than anyone around them. [3] Not because they have a better agent. Because they have stopped expecting the agent to do the job that only the architect can do.
The memory problem was never the agent's problem to solve.
It was always yours.
And the moment you own that — really own it — you stop being frustrated with the tool and start building the system around it.