Claude's Internal Architecture Revealed | How AI Agents Actually Work

High-level incident

• Anthropic accidentally published source maps in a distributed CLI bundle, which exposed the original TypeScript source of their internal AI coding agent (“cloud code”). This was a deployment mistake, not a hack.
• The reconstructed repo from that leak gained massive attention (100k+ GitHub stars very quickly).
• Community engineers performed a clean‑room rewrite: TypeScript → Python prototype → Rust port (Rust chosen for performance, safety, and single-binary distribution).
• Timeline: exposure → working Rust implementation in roughly 24 hours, accelerated by engineers using LLM tools.

Not a hack — a deployment mistake.

What “Cloud Code” is (architectural overview)

Purpose

• An AI coding agent / automation orchestrator built to perform multi-step developer tasks rather than returning a single model response.

Core components

• Agent loop
  • An iterative reasoning loop where the model repeatedly decides next actions, calls tools, ingests results, and continues until the task completes.
• Tool registry
  • ~20+ tools exposed to the agent (read/write files, run shell commands, web search, codebase pattern matching, spawn sub-agents, etc.).
  • Tools execute actions; the model issues requests but does not run commands directly.
• Hooks (middleware / checkpoints)
  • Intercept before and after every tool call to inspect, modify, block, or log inputs/results — essential for observability and safety.
• Memory system
  • Session memory with compaction/summarization when history grows too large, keeping the model within its context window while preserving long-running task state.
• Context loaders
  • cloud.md: repo-level onboarding/config file with project conventions, preferences, folder ignores, testing style, etc.
  • Skills registry: reusable instruction sets (how to do code reviews, write docs, etc.) the agent can pull in as needed.
• Sub-agents
  • The agent can spawn parallel worker agents (via an “agent tool”) to handle subtasks like reviews, tests, or scans. Sub-agents are treated as another tool call, yielding a distributed orchestrator/worker pattern.

Design principles and implications

• Clear separation of concerns: the model handles decision-making; tools handle side effects. This minimizes direct model access to the filesystem/OS.
• Hooks provide a standard way to implement safety, auditing, and policy enforcement.
• Memory compaction is necessary for long, multi-step sessions — analogous to log rotation or archived summaries.
• The architecture maps to conventional distributed system patterns (queues, middleware, workers, config).
• Engineers who master these patterns will be well-positioned to lead future agent and system design.

Security, legal, and operational notes

• Source maps must not be shipped to production; shipping them can directly expose internal IP.
• The community rewrite aimed to be a clean‑room reimplementation (study then reimplement), which matters legally versus verbatim copying.

Practical takeaways / what engineers can learn or build

Key patterns to learn and implement:

1. Iterative agent loop
2. Tool registry and interface
3. Hook / middleware layer
4. Memory / summarization strategy
5. Context / config loading (cloud.md)
6. Skill modules
7. Sub-agent orchestration

• Suggested follow-up: a tutorial to build a minimal agent loop and wire up a basic tool to demonstrate these patterns in code.

Main speakers / sources

• Anthropic — original internal “cloud code” implementation.
• Community engineers who reconstructed the architecture (Python prototype, then Rust port).
• Video narrator/presenter (unnamed in subtitles) summarizing the leak, architecture, and lessons.