At the lowest level, you’re right: everything the model ever sees is context. I’m not claiming a channel beyond tokens. The distinction I’m trying to draw isn’t

At the lowest level, you’re right: everything the model ever sees is context. I’m not claiming a channel beyond tokens. The distinction I’m trying to draw isn’t where state ends up, but how it is governed. AGENTS.md (and similar conventions) are a good step toward making agent context explicit. But they are still instructional artifacts: static guidance that gets loaded into the prompt. They don’t define a state lifecycle. They don’t encode history, correction, or invalidation over time. And they don’t change unless a human edits them. In most agent setups I’ve worked with, “state” is assembled per turn. An agent or orchestration layer decides what to include, summarize, drop, or rewrite. That makes continuity an emergent property of context engineering. It works locally, but over time you see drift, silent overwrites, and loss of accountability. What I’m experimenting with is treating state as a process artifact, not an input artifact. The assistant doesn’t curate its own context. On startup, it reconstructs orientation from a fixed, inspectable set of external files — logs, rules, inventories — with explicit lifecycle rules. State changes happen deliberately (append, correct, invalidate), not implicitly via prompt evolution. So yes, the model ultimately reads tokens. But forgetting, correction, and continuity are handled outside the prompt logic. The prompt becomes closer to a bootloader than a workspace. If you always load a root AGENTS.md plus a stable artifact set, the surface can look similar. In practice, the difference shows up in failure modes: how systems degrade over weeks instead of minutes. I’m not arguing current frameworks can’t approximate this — just that persistent state is usually framed as a context problem, rather than as first-class state with explicit lifecycle semantics. That shift changes what “agentic” failure even looks like.