I Broke Down Anthropic’s $2.5 Billion Leak. Your Agent Is Missing 12 Critical Pieces.

Anthropic accidentally leaked the Claude Code repository, exposing the architecture behind a product with a $2.5 billion run rate. While most coverage focused on unreleased feature flags and what Claude Code might ship in the next few weeks, the real value lies deeper: the underlying infrastructure that sustains a production-grade agentic system serving millions of users. These are the non-glamorous backend engineering patterns that separate a working notebook prototype from a system that operates safely at massive scale.

This analysis distills 12 architectural primitives from the leaked codebase, organized into three tiers: day-one foundations, advanced operational maturity, and a practical framework for evaluating your own agent against these standards. The core thesis is simple but important: building successful agents is 80% plumbing and 20% AI. Crash recovery, permission systems, state management, and token budgeting are the actual secret sauce, not the model itself.

A companion skill (released for both Claude Code and OpenAI Codex) operationalizes these findings, offering both a design mode for new agents and an evaluation mode for auditing existing ones.

The Leak in Context: Velocity vs. Operational Discipline

This was the second significant leak from Anthropic in the same week. Earlier, Fortune reported that Anthropic left draft blog materials describing its new model, Claude Mythos, on a server open to the public. Five days later, a build configuration error leaked the Claude Code source. These were entirely different mechanisms and different systems, but they happened to the same company in the same week.

The developer community’s default conjecture for how Claude Code got leaked is telling. The theory circulating on X, flagged explicitly as conjecture by Alex Vulkov, is that someone inside Anthropic got switched to adaptive reasoning mode by accident, their Claude Code session fell back to Sonnet, and the model committed the map file (the actual leak artifact) as part of a routine build step.

Whether or not that is what happened, the fact that “the AI committed the build artifact that leaked the AI’s own code” is a plausible chain of events tells you everything about where we are with velocity and build security in 2026. When AI writes 90% of your code, as Anthropic says it does, and engineers are shipping multiple releases per day (possibly up to five per engineer), the surface area for configuration drift is enormous. Whatever the exact chain of events, that velocity had consequences this week.

The irony is that some of the primitives covered in this analysis are exactly the kind of boring infrastructure Anthropic will likely lean on to prevent this from happening again: build pipeline configuration, publish step validation, the basic operational discipline that keeps things from accidentally leaking.

Foundational Agentic Architecture (Day-One Basics)

If you are building an agent from scratch, these eight non-negotiable primitives form the foundation. They are presented in the order you should think about them when designing your own system.

1. Metadata-First Tool Registry

The pattern: define your agent’s capabilities as a data structure before writing any implementation code. The registry should answer “what exists?” and “what does it do?” without executing anything.

Claude Code maintains two parallel registries:

• Command Registry: 207 entries for user-facing actions
• Tool Registry: 184 entries for model-facing capabilities

Every entry is a dictionary carrying a name, a source hint, and a responsibility description. The registries are the source of truth; implementations load on demand. This separation is structural, not dependent on the model to infer.

Without a clean tool registry, you cannot filter tools by context, you cannot introspect your system without triggering side effects, and every new tool requires changes to your orchestration code. The registry is the foundation everything else builds on.

For your agent: Implement a listTools function that returns metadata for all registered capabilities without invoking them. It should support runtime filtering and define each tool clearly by name and description. Write this function before any call to the model to think about selecting or executing a tool.

2. Tiered Permission Systems

Not all tools carry the same risk. If your agent can execute code, call APIs, send messages, or modify files and you do not have a permissions layer, “you have a demo, not a product.”

Claude Code segments capabilities into three trust tiers:

1. Built-in: Always available, highest trust
2. Plug-in: Medium trust, can be disabled on command
3. Skills: User-defined, lowest trust by default

Each tier has different loading behavior, different permission requirements, and different failure handling. The shell execution tool alone (the bash tool) has an 18-module security architecture. That is not a typo: 18 separate modules covering pre-approved command patterns, destructive command warnings, Git-specific safety checks, and sandbox termination. When you consider that a shell execution tool could go catastrophically wrong, an 18-module security stack for a single tool is not paranoia. “It’s what separates a system that works safely at a two-and-a-half-billion-dollar run rate from one that works in a little notebook.”

For your agent: Think in terms of five layers:

• Pre-classification: Is this action read-only, mutating, or destructive?
• Pre-approved patterns: Known-safe commands that do not need approval
• Destruction detection: Flag actions that might delete or overwrite before execution
• Domain-specific safety: Targeted checks for risk factors specific to your use case
• Permission logging: Record every decision (granted or denied) with enough context to replay it

3. Session Persistence That Survives Crashes

Your agent session is not just the conversation history. It is a recoverable state that includes conversation, usage metrics, permission decisions, and configuration. If any of those are missing when you resume, the session will not work the same as the original.

Claude Code persists sessions in their entirety as JSON files: session ID, messages, token usage (in and out), permission decisions, and configuration settings. The query engine can be fully reconstructed from a stored session: load, reconstruct transcript, restore counters, and return a fully functional agentic engine.

Agents crash. Connections drop. Users close tabs. If your agent cannot reliably resume where it left off, including what tools were available, what permissions were granted, and how many tokens were consumed, then every interruption is a restart and every restart is a degraded experience.

For your agent: Build a session state structure that captures everything needed to resume. Persist after any significant event, not just at shutdown. Build a resumeSession function that reconstructs full agentic state, not just conversation history.

4. Workflow State Separation

When you resume a conversation, you are not resuming a workflow. These are different problems with different solutions:

• Conversation state answers: what have we said?
• Workflow state answers: what step are we in? What side effects have occurred? Is this operation safe to retry? What should happen after a restart?

Almost every agentic framework conflates conversation state with task state. Without workflow state, you can reinstantiate the agent to be exactly where it was in conversation, but it will not remember where it was in the workflow. The agent will not survive a crash mid-tool-execution without potentially duplicating a write, double-sending a message, or rerunning an expensive and potentially destructive operation.

“It’s like when we were in the 1990s and we saved our game every two seconds because we didn’t want to lose the game if the computer crashed. Same idea. Be paranoid. Save your workflow state.”

For your agent: Model long-running work as explicit states: Planned, Awaiting Approval, Executing, Waiting on External Party. Persist those checkpoints constantly.

5. Strict Token Budgeting

Claude Code’s query engine defines hard limits:

• Maximum conversational turns
• Maximum token budget per conversation
• Automatic compaction threshold

Every turn calculates projected token usage. If the projection exceeds the budget, execution halts immediately with a structured stop reason before an API call is made.

This is notable because these checks are not beneficial to Anthropic in the short term. You might expect a provider to be happy with runaway token consumption. Instead, Anthropic is being a responsible citizen by preventing unintended spending. “It’s the same way that Amazon enables returns, which may not be good for Amazon in the short term, but increases customer trust in the long term.”

For your agent: Input tokens, output tokens, budgets, hard stops. It is a non-negotiable. It is just responsible building in 2026.

6. Structured Streaming Events

Streaming is not just about showing text as it arrives. Every streaming event is an opportunity for the user to understand what the model is doing and intervene if it goes off track.

“I use that streaming state all the time with Claude because it tells me where the model is going, and I will sometimes intervene in the model’s train of thought and type a message because I have seen what it’s thinking about and I know it’s going off track.”

Claude Code’s query engine emits explicitly typed events: message start, command match, tool match, and others. Critically, it anticipates crashes by including a special typed event with the reason for the failure as the last message the stream sends if there is an issue. “It’s like a little black box from a crash.”

For your agent: Design streaming systems that send meaningful, typed events about tool selection, token consumption, and wrap-up status. Do not just send raw text. And plan for crashes.

7. System Event Logging

If structured streaming (primitive #6) tells you what the agent is thinking, system event logging tells you what the agent did. When something goes wrong, the conversational transcript needs to show what actions were taken, not just what was said.

Separate from conversation and streaming events, Claude Code maintains a history log of system events. It is the absolute source of truth for:

• What context was loaded
• Registry initialization details
• Routing decisions
• Execution counts
• Permission approvals and denials

Every event has a category and structured details so you can fully reconstruct any agentic run. “This is what you do when you are building a system that you intend for enterprise.”

For your agent: Maintain a system event log that records not just what was said, but what was done, with enough structure to provably walk it back.

8. Two-Level Verification

Verification must happen at two distinct levels:

Level 1 - Task Verification: The agent performs a separate, built-in step to check its own work. This is the visible part: you see Claude going through the stream of events to verify the work was correct.

Level 2 - Harness Verification: You also need to verify that changes you the human make to the agentic harness do not break subsequent agent runs. This means maintaining verification tests for foundational guardrails:

• Do destructive tools still require approval after this change?
• When tokens run out, does the model gracefully stop or hard crash?

“You have to provide for the harness evolving.” Name these guardrails. Log them. This second level of verification is the one teams forget about because it requires thinking about the system changing over time, not just individual runs completing successfully.

Advanced Operational Maturity

As agentic systems scale, architecture must accommodate complex workflows, longer runtimes, and specialized task delegation. These four primitives represent operational maturity beyond the day-one basics.

9. Dynamic Tool Pool Assemblies

If you have 184 tools, you do not assemble all of them into a usable pool on every agent run. Instead, Claude Code assembles a session-specific tool pool based on mode flags, permission context, and deny lists.

This contrasts with how most enterprise workflows handle tools: hard-coding a fixed list. Claude Code’s approach says that a general-purpose problem-solving agent may need to assemble a shorter, dynamically selected tool list for a given run, reading from a wider registry and picking what is relevant.

For your agent: If you have a general-purpose agent, consider dynamic tool compilation rather than passing every tool on every run. It improves efficiency and focuses the model on the immediate task context.

10. Transcript Compaction

Conversation history is a token-expensive resource. Claude Code automatically manages it by compacting after a configurable number of turns: discarding older, less relevant entries while preserving recent context and the initial system instructions. The transcript store tracks whether it has been persisted to avoid data loss.

This is a hot area of development because longer-running agents create a tension: you need to keep the initial instruction that got the agent started, but you also need to cut intervening conversational turns and actions that are no longer relevant to the agent’s present state.

For your agent: Build automatic compaction routines. Define your token threshold, decide what is safe to discard, decide what must be preserved (especially system instructions), and validate that your compaction logic does not lose critical context.

11. Queryable Permission Audit Trails

Permissions should not be simple boolean gates. Claude Code makes permission state a first-class, queryable object and builds three separate permission handlers for different contexts:

1. Interactive Handler: For human-in-the-loop decisions
2. Coordinator Handler: For orchestrator agents handing out permissions in multi-agent setups
3. Swarm Worker Handler: For autonomous execution layers managed by an orchestrator

Three different types of agent context, each needing a different permission structure, all accounted for in a single permission architecture.

12. Specialized Agent Type Systems

As far as is known, this was not leaked before now. Claude Code defines six built-in agent types:

1. Explore: Cannot edit files
2. Plan: Does not execute code
3. Verify: Checks work
4. Guide: Provides guidance
5. General Purpose: Full capabilities
6. Status Line Setup: Narrow configuration task

Each type comes with its own prompt, its own allowed tools, and its own behavioral constraints. An Explore agent is physically incapable of editing files. A Plan agent does not execute code.

“The transferable lesson here is not ‘just spawn agents randomly like you’re cloning minions.’ It’s to constrain roles really sharply when you split work out, and constrain them in a number of observable types so that you can manage those types to control your overall agent population.”

The Agentic Harnesses Skill

To operationalize these principles, an “Agentic Harnesses Skill” has been built, compatible with Claude Code (as a Claude skill package) and OpenAI Codex (with Codex-specific metadata, path patterns, and agent routing). The core logic is identical because these primitives scale across LLM providers.

Design Mode: Describe what you are building (a chat assistant, a workflow orchestrator, a code agent) and the skill walks you through a structured design process. It recommends a harness shape, identifies the minimum useful set of primitives, sequences the implementation into phases, and defines verification criteria, all before you write a line of code. “It doesn’t just generate boilerplate. It generates an architecture with rationale deeply rooted in what we can learn from how the most successful agent in production today runs.”

Evaluation Mode: Point it at an existing codebase, a CLAUDE.md file, or architecture documents and it evaluates every dimension (architecture, safety, permissions, state, durability) against the 12 primitives. It returns findings ordered by severity, a prioritized upgrade path, and specific tests to confirm fixes work.

The skill is opinionated by design. It biases toward lean, single-agent, solo-maintainable architecture. It starts with single-agent design unless you give it strong reasons for multi-agent coordination. It biases toward simplicity because simplicity is maintainable.

“The most common failure mode I’ve seen in agentic systems is not underengineering. It’s overengineering. Building a really complicated multi-agent coordination layer before you have a working permission system. Or implementing a plug-in marketplace before your sessions can survive crashes.” The skill pushes back on unnecessary complexity because premature complexity is where most projects go to die.

The Core Takeaway

Building agents is 80% non-glamorous plumbing and 20% AI. So much of what makes Claude Code work at a multi-billion-dollar level is the kind of thing most people roll their eyes at: failure cases, security, crash recovery, typed events, limited schemas. It is the architecture of scale, and it is essentially a function of good backend engineering. “We’re just applying good backend engineering to these agentic pipelines and discovering that, hey, that works pretty well.”

---

“The plumbing isn’t very glamorous maybe, but I’m talking about it because I believe it’s the whole game.”

Meta

Added: 2026-04-03