The industry uses hallucination to describe almost everything an agent gets wrong. I think that is lazy. Model incapacity, missing knowledge, tool flakiness, and reward misspecification are all different problems with different causes.
What I do claim is that a large, practical class of coding-agent failures share one structure: the agent's context has drifted from the original intent, undetected. It goes off-track, writes irrelevant code, violates an architecture rule, duplicates work that already exists. I call that specification drift.
Better models and better CLAUDE.md files reduce the odds of drift. They do not detect it or prevent it structurally. What is missing is infrastructure that captures intent before execution, links it to the code, and watches whether execution stays inside the spec.
That is iCPG: a persistent, queryable intent layer that an agent checks against before and during a task, so drift shows up early enough to intervene. It does not replace the model or the prompt. It adds the specification layer they both assume but never store.
It came out of two real problems: the zenloop v1 to v2 migration, where the hard question was whether v2 preserved v1's edge cases that lived in no structured form, and governing agentic work across several production products at once.
It is a hypothesis with a validation plan, not a finished result. The migration is the test. The theory should earn its claims there, not in an argument.