An “oracle” in this context is a component that knows something the LLM doesn’t — typically the structure of the system. The agent edits code or config; the oracle has a formal model (e.g. states, transitions, invariants) and can answer questions like “is there a stuck state?” or “does every path have a cleanup?” The oracle doesn’t run the code; it reasons over the declared structure. So the agent has a persistent, queryable source of truth that survives across sessions and isn’t stored in the model’s context window. That’s “persistent architectural memory.”
Why it helps: the agent (or the human) can ask the oracle before or after a change. “If I add this transition, do I introduce a dead end?” “Which states have no error path?” The oracle answers from the formal model. So you’re not relying on the agent to remember or infer the full structure; you’re relying on a dedicated store that’s updated when the structure changes and queried when you need to verify or plan. The agent stays in the “how do I implement?” role; the oracle is in the “what is the shape?” role.
Building an oracle means maintaining a representation of the system (states, transitions, maybe invariants) that stays in sync with the code or config. That can be manual (you write the spec) or semi-automated (the agent or a tool proposes updates to the spec when code changes). The oracle then runs checks or answers queries over that representation. For agentic systems, the oracle is the “memory” that the agent lacks: a place to look up structural facts instead of re-deriving them from source every time.
The approach is especially useful when multiple agents or humans work on the same codebase. The oracle is the single source of truth for “what’s the intended structure?” so that everyone — human or agent — can check their changes against it.
Expect more tooling that provides oracle-like structural views and checks, and tighter integration with agentic workflows so that agents can query before they act.
nJoy 😉