Why the leaked internals point to a new architecture for coding agents
Opening
The Claude Code leak matters because it exposed more than implementation details. It surfaced a design pattern for building coding agents under real constraints, where memory, repo state, tool use, compaction, permissions, and verification all work together as one operating layer around the model.
The leak itself appears to have come from published source maps in the npm package, and the surfaced source tree gave people a rare look into the internal structure of the product. Combined with Anthropic’s public documentation and the leaked memory diagram, that material suggests Claude Code is carefully engineered around a single problem: how to keep an agent useful when the codebase, the session history, and the task state are all larger than the context window it can directly hold.
A useful way to think about Claude Code is that it treats context the way a data system treats storage and compute. Different kinds of information are kept at different levels, some stay immediately available, some are retrieved only when needed, and some are compressed or dropped to protect the quality of the working state.
Context stack
Anthropic’s docs confirm that Claude Code starts each conversation with a fresh context window and rebuilds continuity from persistent project instructions and an auto-memory directory. That auto-memory layer is centered on MEMORY.md, and only the first 200 lines or 25KB of that file are loaded at startup, while more detailed topic files are stored separately and read on demand.
That single design choice says a great deal about the system. The always-loaded layer has to stay small, which means long-term usefulness depends less on raw retention and more on what the system decides deserves permanent space near the top of the stack.
The leaked memory diagram adds a deeper structure. It shows MEMORY.md as an always-present index, topic files as a second layer loaded only when relevant, and session transcripts as a lower layer accessed through narrow search rather than full rereads. Public docs do not spell out every one of those mechanics, but they strongly align with the documented split between a compact startup memory and on-demand supporting files.
Working state
Claude Code also appears to ground itself in live repository state rather than relying on memory summaries alone. Materials examined in this discussion describe the system as tracking project instructions, repository state such as branches and recent commits, and a structured session-state layer that carries the active task, workflow, relevant files, errors, learnings, and results during the current run.
That matters because software work is highly dynamic. A memory file can preserve useful continuity across sessions, but the codebase itself remains the real source of truth, so the agent needs constant contact with the live environment if it wants to stay aligned with reality.
Taken together, the architecture looks layered in a very deliberate way. Repository state tells the agent what is true now, session state preserves near-term intent and progress, and long-term memory carries only the small amount of information worth keeping across runs.
Compaction
The most interesting part of the leaked design is that memory seems built to be rewritten continuously. The diagram shows an autoDream flow tied to indexing, topic files, transcripts, and a consolidation lock, and surrounding analysis describes a background process that merges overlapping notes, removes stale material, resolves contradictions, rewrites vague references into stable facts, and rebuilds the index so it stays useful under hard size limits.
This is a sophisticated answer to a real systems problem. Long-running agents accumulate noise very quickly, and a memory system that only appends will eventually turn its own history into context pollution.
The same body of reverse-engineered analysis also claims Claude Code uses aggressive compaction under heavy token pressure, keeping only a limited slice of directly visible context and summarizing the rest, while also enforcing caps on large file reads and oversized tool outputs. Anthropic has not publicly confirmed every threshold or internal limit, but the broader pattern fits the product’s documented emphasis on keeping the hot layer of memory concise and retrieving detail only when necessary.
There is another important consequence here. When long sessions deteriorate, the cause may often be a visibility problem rather than a reasoning problem, because the model is operating over a compressed and partially filtered representation of prior work. That makes compaction one of the central design challenges in agent systems, since every summary step protects context budget while also risking the loss of subtle constraints or hard-won discoveries.
Execution and trust
Claude Code’s architecture also appears built around action, not just response generation. The material discussed here points to an execution harness with tool workflows, file-edit paths, permission handling, and verification logic wrapped around the model, which helps explain why the product feels more operational than a standard chat interface.
Permission handling is part of that same control system. Reporting on Claude Code’s recent behavior indicates movement toward more automated permission decisions with safeguards, which suggests the surrounding harness is trying to reduce unnecessary human interruption while still preserving strong boundaries around risky actions.
Verification is where the architecture becomes especially important. The reverse-engineered discussion claims there are internal success paths tied to execution behavior and stronger attention to post-edit checking, while Anthropic’s docs explicitly frame memory as context rather than guaranteed truth. That combination points to a deeper principle: the system should never rely on memory alone when it can inspect the repository, run tools, and check whether the intended change actually happened in the live codebase.
The same logic helps explain why isolation appears in the leaked design. The diagram includes a consolidation lock, and related analysis describes delegated or background work running on isolated paths so temporary exploration and maintenance work do not destabilize the main reasoning loop. For a coding agent operating across many files and many intermediate states, isolation is not an optimization detail. It is part of how the system protects coherence.
Industry shift
What emerges from all of this is a broader thesis about where agent products are heading. Claude Code suggests that practical performance depends on a disciplined architecture for context: a small hot layer, deeper retrievable layers, live environmental grounding, background memory maintenance, guarded execution, and verification loops that reconnect the model to reality after it acts.
This matters beyond one product because the same constraints will apply to any serious software agent. Large codebases are too big to fit in a prompt, session histories become noisy, memory becomes stale, and execution without verification creates false confidence, so the winning systems will be the ones that manage context with the same rigor that distributed systems manage storage, indexing, freshness, and fault tolerance.
That is the larger lesson of the leak. Claude Code shows how much leverage comes from shaping the information flow around the model, deciding what remains close, what gets retrieved later, what must be refreshed, and what has to be checked against the live world before the system can trust itself. Whoever solves that problem best will have a major advantage in practical AI software, because reliable agents are built as much from context discipline as from model intelligence.