The core insight no one noticed

Claude Code is not a code assistant. It is an agent operating system.

Every other agent implementation you have seen is a single process program. All state lives in one shared address space. There is no memory protection. There is no garbage collection. There is no scheduler.

Claude Code is the first production agent that solves this correctly. It implements every core abstraction that general purpose operating systems adopted in 1965, adapted for LLMs. This is not an incremental improvement. This is the first agent architecture that actually scales past 10 turns of work.

This article breaks down every component, the tradeoffs they chose, and the patterns that have been proven to work inside Anthropic across hundreds of engineers and millions of agent runs.

Why single context windows always fail

All monolithic agents fail the same way. Every file read, every failed experiment, every abandoned tangent, every half finished thought stays in the context window forever.

After 15 turns, approximately 40% of the context window is dead weight. The model cannot forget. It cannot ignore noise. It cannot garbage collect state that is no longer relevant. Every additional token makes it incrementally dumber.

This is not a prompting problem. This is not a RAG problem. This is a fundamental architectural flaw. You cannot fix this with better system prompts. You cannot fix this with longer context windows. Longer context windows just let the agent accumulate garbage for longer before it collapses.

Every agent demo you see on Twitter dies right around the 12 turn mark for exactly this reason.

Subagents: the process abstraction for agents

Subagents solve this. A subagent is an isolated Claude instance with its own clean context window. It receives a single explicit task. It runs. It returns only the final result. All intermediate state is discarded when it exits.

This is exactly the process abstraction that operating systems invented 60 years ago. You do not run every program in the same address space. You isolate them. They communicate only via explicit message passing. When they exit you throw away everything except the return value.

Subagents can run in parallel. They can have different permission levels. A research subagent can get read only access. An implementation subagent can get edit access. A subagent processing untrusted public input gets zero write permissions at all.

Independent verification subagents catch 2.1x more bugs than reviews done in the main conversation context. They have no exposure to the justifications, tradeoffs, and blind spots accumulated during implementation. They see only the final code.

Dynamic workflows: agents writing their own scheduler

Prior to February 2026, every agent harness was written by humans. You would write a static orchestration script that worked for one narrow class of task. If your task deviated even slightly from the expected pattern, the harness broke.

Dynamic workflows change this. Claude Opus 4.8 will now write a custom orchestration harness on the fly, built exactly for the specific task you asked it to do. It will define the subagent roles, the execution order, the merge logic, the verification steps and the termination conditions. It will then execute the harness it just wrote.

This is not a gimmick. The Bun runtime was fully rewritten from Zig to Rust using this pattern. 1200 files, 317,000 lines of code. The workflow spawned one subagent per translation unit, one independent verifier per change, merged passing changes incrementally, and looped until all tests passed.

No human wrote that harness. Claude wrote it after reading the request.

Common workflow patterns proven at Anthropic

After running tens of thousands of dynamic workflows internally, Anthropic has identified a small set of composable patterns that produce consistent reliable results. These are not theoretical. These are the patterns Claude will reach for by default when building a workflow.

Fan out and synthesize. Split a task into N independent units. Run one subagent per unit. Wait for all to complete. Run a final synthesizer agent to merge the structured outputs. This works for refactoring, resume ranking, incident root cause analysis and bulk triage.

Adversarial verification. For every agent that produces output, spawn a second independent agent whose only job is to break that output. Do not let them communicate. This pattern alone eliminated 62% of bad internal PRs.

Tournament selection. Spawn N agents all attempting the same task with different approaches. Run pairwise comparison agents to judge outputs. Comparative judgment is 37% more reliable than absolute scoring for any qualitative task.

Loop until convergence. Spawn agents repeatedly until an explicit stop condition is met, not for a fixed number of passes. This is the only reliable pattern for debugging flaky tests.

Classifier routing. Run a lightweight classifier agent first to decide what type of task this is, then route to the appropriate specialist agent. This is how you avoid running expensive Opus instances for trivial work.

Skills: not markdown, shared library modules for agents

The single most common misconception about Claude Code is that skills are just markdown files. They are not.

A skill is a directory. It can contain instructions, reference snippets, helper scripts, binaries, templates, log files, and even full SQLite databases. Skills are shared libraries for agents. They package domain expertise so Claude does not have to rediscover it every time.

The highest impact skill inside Anthropic is not a document. It is a 700 line Playwright script that drives the full signup flow, runs assertions at every step, and records a video of the execution. Claude does not generate this code. It calls it. It spends its tokens on interpreting the result, not recreating boilerplate.

Skills can also register lifecycle hooks. They can block dangerous commands, enforce validation, or trigger verification steps automatically when loaded.

The nine categories of useful skills

After cataloging every internal skill used at Anthropic, they fall cleanly into nine distinct categories. Any skill that tries to span more than one will confuse the agent and underperform.

1. Library bindings. Edge cases, footguns and reference snippets for internal or poorly documented libraries.
2. Verification drivers. Scripts that run tests, drive UIs and validate state.
3. Data connectors. Wrappers for monitoring, logs and databases.
4. Workflow automation. Standard repeatable tasks like standup posts and ticket creation.
5. Scaffolding. Boilerplate generators that follow internal conventions.
6. Code review. Standardized checklists and adversarial review logic.
7. Deployment. Safe rollout, canary and rollback procedures.
8. Debugging playbooks. Symptom to investigation mappings for production services.
9. Operational maintenance. Guardrailed procedures for cleanup and destructive actions.

The only skills worth spending engineering time on are verification skills. A good verification skill will pay for itself in days.

Tool design: stop building tools for humans

Almost everyone builds agent tools wrong. They build tools that would be convenient for a human. You need to build tools that are convenient for an LLM.

This is the core principle of tool design that almost no one gets right. You have to see like an agent.

When Anthropic built the AskUserQuestion tool they went through three failed iterations. First they added questions to the exit plan tool. Claude got confused. Then they tried a standard markdown format. Claude abandoned the structure 28% of the time. Only when they made it a dedicated first class tool did usage jump 4x and user satisfaction double.

Even more telling: they removed the TodoWrite tool. It was an essential crutch for Claude 3. For Opus 4.5 it became an active handicap. The model was capable of tracking its own progress, and the todo list was only forcing it to stick to bad initial plans.

Claude Code has exactly 20 tools. The team removes tools more often than they add them. Tools are not permanent features. They are crutches matched exactly to the capability level of the model you are running.

Progressive disclosure instead of RAG

Claude Code does not use RAG. There is no vector database. There is no pre indexing step.

They tried RAG. It worked fine. Then they gave Claude grep.

It turns out Claude is better at deciding what it needs to read than any retrieval system humans can build. It will search, navigate, filter and build its own context incrementally. It will follow references across files. It will stop when it has found what it needs.

This is progressive disclosure. You do not dump all possible context into the prompt up front. You give the agent the tools to find the context it needs, when it needs it.

This is the single most important architectural decision anyone building agents today can copy. Stop building RAG pipelines. Give your agent grep.

When you should not use any of this

None of this is free. Dynamic workflows use 3-10x more tokens than a standard session. Subagents have overhead. Skills add latency.

Do not use workflows for 10 line bug fixes. Do not spawn 5 adversarial reviewers for a documentation change. Do not use a subagent to look up a single constant. 90% of tasks do not need any of this.

This architecture exists for the 10% of high stakes, complex tasks that monolithic agents cannot complete at all. This is for refactoring 100 files. This is for debugging flaky tests. This is for auditing 6 months of incident reports. This is for work that would take a human engineer multiple days.

You can set explicit token budgets for workflows. Always do this. Runaway workflows are the single most common failure mode.

What this means for the future of agents

All of the current generation agent frameworks are obsolete. Langchain, LlamaIndex, AutoGPT, every single one of them is built around the monolithic single context window model. They will never work for real work. You can stop trying to fix them with better prompting. The architecture is wrong.

The correct architecture is the one described here. Isolated subagents. Explicit message passing. Dynamic orchestration. Progressive disclosure. Skill based extension.

None of these ideas are new. Every single one was invented for operating systems 60 years ago. Anthropic did not invent anything. They are just the first people to realize that LLM agents have exactly the same failure modes, and exactly the same solutions.

This is not the final agent architecture. But it is the first one that works. If you are building agent systems today, stop building monoliths. Go copy this.