For a brief window, an npm package published by Anthropic contained a full debug bundle of the Claude Code CLI — roughly half a million lines of TypeScript, including the internal harness, the memory system, and the tool router. It was pulled quickly. By then, plenty of people had read it.
Most of the coverage focused on what leaked. The more useful question is what it implies for anyone building serious AI on top of real data infrastructure.
What the architecture actually shows
Four distinct layers, cleanly separated.
A tools layer
Every capability — file read, bash execution, web search, git operations — lives as its own self-contained module. Input schema. Permission model. Clear contract. The LLM decides which tool to call; the harness decides how to execute it. Decision and execution are not the same function.
A memory system
Three layers, designed to fight context entropy.
- A lightweight index, always in context, around 150 characters per entry.
- Topic files, fetched on demand when the index points to them.
- Session transcripts, grep-searchable but never loaded in full.
The write discipline is strict. Memory updates only after a successful side effect. No speculative writes.
A multi-agent orchestration layer
Complex tasks spawn subagents with isolated context. The parent conversation — often noisy, often contradictory — doesn't leak into the child's working memory. Each subagent gets exactly three things: its system prompt, its task, and the specific context it needs.
A query engine
Manages the LLM API calls themselves. Retries, token budgets, model routing, fallbacks. The detail that stuck with me: a rule to stop retrying after three consecutive failures. One small circuit-breaker like that reportedly cut hundreds of thousands of wasted calls.
Why this matters for data teams
If you're building AI features on top of your warehouse, the model is not your product. The harness is.
The best results won't come from picking the best model. They'll come from the foundation underneath it — a clean data layer, well-documented dbt projects, consistent naming, and a tool surface the model can actually reason about. Agents plugged into undocumented raw tables will confidently hallucinate answers. Agents plugged into documented, tested, well-named models will quietly give you correct ones.
What the leaked feature flags hint at
Dozens of feature flags. Most not yet released. A few stand out.
- KAIROS — an always-on background agent consolidating memory during idle time.
- ULTRAPLAN — offloading complex planning to a remote session for up to thirty minutes, with explicit user approval.
- Capybara — codename for the next model family, apparently with a much larger context window.
The direction is clear: from reactive agents to proactive ones, from single sessions to persistent ones. Agents monitoring pipelines overnight. Agents flagging anomalies and proposing fixes before the standup.
Three things worth doing now
- Audit your context management. If any of your long-running agent sessions load everything into a single prompt, rebuild them around pointer-based memory. Even rough versions beat monolithic context.
- Document your dbt project like an agent will read it. YAML descriptions, naming conventions, a root-level
CLAUDE.mdexplaining the mental model. Treat documentation as a tool, not a courtesy. - Invest in the harness, not the model. Tools, data foundations, documentation, retry logic. The difference between working AI and demo AI lives there.
The source code will be cleaned up. The lesson won't change.
Building AI that's meant to last? We focus on the harness — data foundations, documentation, tool integrations — not the model. Book a discovery call and we'll show you what that looks like in practice.