Skip to main content
OCT 2026 Latest guide updates. Latest: Mistral Large 4 AI FinOps Lean & AI Changelog →

Claude Code: 50 architecture diagrams

Visual reference for Claude Code internals: architecture, MCP ecosystem, multi-agent patterns, security models, and development workflows. 50 SVGs generated at build time, with ASCII fallbacks and guide links.

50 Diagrams
12 Themes
SVG Inline rendering
Claude Code: Foundations 4 diagrams

Context components, a teaching workflow, task routing, and six permission modes

"Chatbot to Context System": 4-layer model

This four-part teaching model groups the inputs Claude Code uses. The branches are context categories, not a fixed assembly order. Instructions and tool definitions may load at different times; MCP tools can be deferred until needed.

User message

Model request

System instructions

Relevant context
CLAUDE.md, memory, files,
working directory and Git

Available tool definitions
Built-in tools and loaded MCP tools

Conversation history
Messages and tool results

Response or tool calls

Context management

9-step workflow pipeline

This nine-stage teaching workflow summarizes a tool-assisted turn. Claude may answer directly, repeat exploration, or stop after an error or interruption. These stages do not specify nine mandatory internal functions.

Yes

Allowed

Denied

No

User message

Understand request

Gather relevant context

Choose next action

Tool needed?

Check permissions

Execute tool

Collect result

Update conversation context

Generate response

Display response

The master loop

Quick decision tree: "Should I use Claude Code?"

An author heuristic for choosing an interface. File access and repeated tool execution can make Claude Code useful; pure conversation can suit Claude.ai. This is not a product restriction or a measured time threshold.

Yes

No

Yes

No

Task to complete

Need repository or
local file access?

Consider Claude Code

Need repeated
tool execution?

Consider Claude.ai
or a direct API workflow

Define success checks
and review needed access

First workflow

Permission modes comparison

Six documented modes change how tool calls are approved. This is a summary: allow/ask/deny rules, working-directory boundaries and protected actions still matter. The availability of auto mode depends on the session.

Permission modes

default / Manual
Prompts for actions needing approval
Permitted reads can run

acceptEdits
Accepts file edits and common
filesystem commands in allowed directories

plan
Reads and read-only shell
Classifier-approved commands when auto is available
No source-file edits

auto, when available
Classifier reviews actions
without routine permission prompts

dontAsk
Denies calls that would prompt
Permitted reads and allowed calls can run

bypassPermissions
Skips permission prompts
Documented exceptions still apply

Permission modes

Claude Code: Context & Sessions 4 diagrams

Context recommendations, memory scopes, native session resume, and focused sessions

Context management zones

These four situations are an author workflow for managing context, not native percentage zones or permission states. Claude manages context automatically; no universal auto-compaction percentage is asserted here.

Focused work
Keep relevant context

Growing context
Inspect with /context

Noise or lost focus
Use /compact with a focus

Task boundary
Resume later or start fresh
with a written handoff

Context management

Memory hierarchy (6 types)

This six-part teaching taxonomy separates persistent instructions, learned notes, conversation history and external state. It is not a six-level configuration override stack. CLAUDE.md and rules shape context; they do not enforce tool permissions.

Context and persistence scopes

1. Organization instructions
Managed CLAUDE.md
2. User instructions
User CLAUDE.md and rules
3. Project and nested instructions
CLAUDE.md and scoped rules
4. Auto memory
Saved notes for the repository
5. Conversation history
Saved sessions can be resumed
6. External and tool state
Persistence depends on server or tool

Preferences and conventions
Keep credentials out of instructions

Memory files

Session continuity: Saving and resuming state

Claude Code saves conversations. Reopening a terminal can resume a saved session, or start a fresh conversation with persistent instructions and an optional handoff. A handoff summarizes progress; it does not restore every message.

Handoff fileSaved conversationsClaude CodeUserHandoff fileSaved conversationsClaude CodeUseropt[Prepare a fresh session]Open another terminalLoad persistent instructions and available memoryalt[Continue saved conversation][Start fresh]Save conversation during workWrite status, decisions and next stepsSave handoff summaryclaude --continue or claude --resumeLoad selected conversationSaved historyclaude, then read handoff if neededRead handoff when requestedSummary, not full history

Session continuation and resume

Fresh context anti-pattern vs. best practice

Unrelated tasks can fill a session with irrelevant history. The author recommendation is to work in focused sessions, use compaction when useful, and preserve a handoff before starting fresh. Saved conversations remain available for resume.

Focused workflow

Yes

No

Yes

No

Work on task A

Natural checkpoint?

Save handoff or resume later

Fresh session for unrelated task B

Context needs cleanup?

/compact with a focus

Unfocused session

Task A

Unrelated task B

Unrelated task C

More irrelevant context
Harder to retain instructions

Context management

Claude Code: Configuration System 4 diagrams

Managed settings precedence, skills and commands, subagents, and hook lifecycle

Configuration precedence (5 levels)

For the same settings key, the documented stack has five levels, highest first. Lists may merge and security-sensitive exceptions apply. Environment-variable precedence is defined per setting; CLAUDE.md belongs to instruction context, not this settings stack.

1. Managed settings
Organization policy
2. Command-line arguments
Session flags and --settings
3. Project local settings
.claude/settings.local.json
4. Shared project settings
.claude/settings.json
5. User settings
~/.claude/settings.json

Built-in fallback
When no source sets the value

Environment variables
Precedence defined per key

Precedence rules

Skills vs. commands vs. agents: When to use each

Custom commands have been merged into skills. Both file formats create a slash command; skills also support bundled resources and invocation by Claude. Subagents use a separate context window for delegated work. User and project scopes exist for these mechanisms.

Yes

No

Need delegated
reasoning context?

Subagent definition
.claude/agents/name.md
Agent tool, own prompt and tools

Skill
.claude/skills/name/SKILL.md
Resources and invocation controls

Compatible command format
.claude/commands/name.md

Slash command or Claude invocation
As configured

Summary returns to parent

User or project scope

Understanding skills

Agent lifecycle & scope isolation

A separate context window keeps intermediate tool activity out of the parent conversation. It does not isolate file or service effects. Ordinary subagents start fresh; forks inherit the conversation. A worktree can separate repository edits.

Files and servicesSubagentAgent toolParent ClaudeFiles and servicesSubagentAgent toolParent ClaudeFresh conversation contextalt[Ordinary subagent][Fork]Effects may be sharedOptional worktree separates repository editsDelegate taskTask prompt and agent configurationCopy parent conversation and configurationAllowed reads, edits or external callsResultsFinal summarySummary enters parent context

Sub-agent architecture

Hooks event pipeline

This simplified lifecycle distinguishes session events, turn events and tool events. PermissionRequest is conditional. Hook types and decision controls vary by event; this is not the exhaustive event inventory.

Exit 2 or block

Proceed

Yes

No, response finished

Block

Proceed

No, allowed

Yes

Allowed

Denied

Yes

No

Next prompt

Session ends

Session starts

SessionStart

Prompt submitted

UserPromptSubmit

Prompt blocked
Reason shown to user

Model processes context

Tool call?

PreToolUse

Stop

Tool blocked

Permission prompt needed?

Tool executes

PermissionRequest

Tool succeeded?

PostToolUse

PostToolUseFailure

Await next turn or end session

SessionEnd

InstructionsLoaded
Async when instruction files load

SubagentStop
When a subagent finishes

PreCompact

Compaction

PostCompact

The event system

Claude Code: Architecture Internals 5 diagrams

Agentic loop, illustrative tool families, request context, subagent boundaries, and model pipelines

The master loop

A simplified model-and-tool loop: Claude requests tools, permitted operations run, and their results return to the conversation. Turns can also end because of errors, cancellation or limits. Independent operations may run concurrently; no fixed concurrency limit is asserted.

Yes

Yes

No

No

New message

Exit

Error, cancellation or limit

User input

Prepare request context
Instructions, history, available tools

Model request

Tool calls?

Allowed?

Execute permitted tools

Return denial to conversation

Append tool results

Display response

Next user action?

Session ends

Handle interruption or failure

The master loop

Tool categories & selection

These six author-defined categories organize examples from the documented tool inventory. Availability varies by Claude Code version, model, surface and configuration; this is not a complete tool list or a native six-category taxonomy.

Illustrative tool families

Read and search
Glob, Grep, Read

Modify files
Write, Edit, NotebookEdit

Execute and delegate
Bash, Agent

Web access
WebSearch, WebFetch

Track tasks when available
TaskCreate, TaskGet,
TaskList, TaskUpdate

Control workflow
EnterPlanMode, ExitPlanMode,
EnterWorktree, ExitWorktree,
AskUserQuestion

The tool arsenal

System prompt assembly

This conceptual request diagram groups stable instructions with changing conversation context. It does not specify the exact internal assembly order, cache breakpoints or when every input is reread. Instruction files and memory may enter conversation context; MCP definitions can load on demand.

System instructions

Model request

Available tool definitions
MCP definitions loaded as needed

User and project instructions
Relevant rules and auto memory

Conversation context

Relevant environment and file context

User messages and tool results

Claude API or configured provider

Cache reuse depends on stable prefixes
and the provider contract

System prompt contents

Sub-Agent context isolation

Conversation isolation and filesystem isolation are different boundaries. An ordinary subagent has fresh context; a fork inherits the parent conversation. Both return a final result while permitted operations may affect shared files or external services.

Ordinary subagent

Fork

Parent conversation

Agent delegation type

Fresh context
Task prompt and agent definition

Inherited conversation
Parent prompt, tools and history

Subagent tool operations

Shared checkout or external services
Effects remain visible

Optional isolation: worktree
Separate repository checkout

Final result enters parent context

Sub-agent architecture

Three model pipelines: dense, MoE, and VLM

This is a conceptual simplification. Dense versus mixture-of-experts (MoE) describes how the layers are built, and text-only versus vision-language (VLM) describes which inputs the model accepts. These are different axes that can combine: an MoE model can also accept images. Anthropic does not publicly document Claude's internal architecture, so the diagrams show published open designs, not Claude. For the axis table, see [architecture, size class, modality and task](../core/ai-concept-boundaries.md#architecture-size-class-modality-and-task).

Vision-language model

Image

Vision encoder

Projection into the
LLM embedding space

Text tokens
embedded

Merged sequence

Language model
dense or MoE

Text output

MoE variant of the layer

top-k, Mixtral: 2 of 8

not selected

Token states
after attention

Router
scores N experts per token

Selected experts
replace the feed-forward block

Idle experts

Weighted sum
by router weights

Layer output

Note: all experts stored,
only k compute

Dense decoder LLM

appended to input, repeat

Text

Tokenizer

Token embeddings

Stack of transformer layers
attention + feed-forward

Next-token probabilities

Sampled token

Architecture, size class, modality and task

Claude Code: MCP Ecosystem 4 diagrams

MCP maintainers, transports, rug pull risks and configuration precedence

MCP server ecosystem map

Group servers by their maintainer and purpose. Provider-maintained servers and MCP reference examples have different support expectations. Neither category guarantees a security audit by Anthropic. The old standalone Semgrep MCP repository is deprecated; its server is maintained through the official Semgrep binary.

Claude Code
MCP client

MCP reference examples
Educational, evaluate before production

Provider-maintained servers

Community servers
Verify exact repository and maintainer

Local or internal servers
Project tools and API wrappers

mcp-server-git
Local Git operations

sequential-thinking
Reasoning example

Context7 / Upstash
Library documentation

Playwright / Microsoft
Browser automation

GitHub MCP / GitHub
Platform tools

Semgrep official binary
Security scanning

AWS Labs MCP servers
AWS tools

Check maintenance, permissions
and pinned version before install

Guide: MCP server ecosystem map; MCP reference servers, Context7, Playwright MCP, GitHub MCP, Semgrep migration notice, AWS Labs MCP

MCP architecture: Client-Server protocol

MCP uses JSON-RPC. Standard transports are stdio and Streamable HTTP; the historical SSE transport remains supported by Claude Code but is deprecated. Streamable HTTP can itself stream replies using SSE. The diagram illustrates a tool-call exchange, not every MCP capability.

Claude requests a tool

Claude Code matches
the tool to its server

JSON-RPC tools/call
params.name + params.arguments

stdio or Streamable HTTP
Legacy SSE deprecated

MCP server executes action
API, file or CLI

External service
if required

JSON-RPC response
result or protocol error

Claude Code provides tool result
to the next model turn

Guide: MCP architecture: Client-Server protocol; MCP transport bindings, tools/call wire format, Claude Code transports

MCP rug pull attack chain

A rug pull changes a previously trusted tool or server after installation. A malicious description can try to influence Claude, but reading it does not guarantee execution or exfiltration: permissions and process isolation may block the attempted action. Review source and updates, pin versions where possible, and restrict permissions and network access.

No

Yes

Initially benign MCP server

User reviews and installs it

Attacker changes tool description
or server implementation

Malicious content reaches Claude

Claude may attempt
an injected action

Do permissions and isolation
allow the action?

Action blocked
Investigate server and exposure

Sensitive data may be read

A tool call or network request
may carry data to attacker

Revoke access, inspect logs
and rotate exposed credentials

Guide: MCP rug pull attack chain; Claude Code MCP security

MCP config hierarchy

For duplicate server names, local scope precedes project scope, then user scope. Lower-priority plugin servers and claude.ai connectors are also checked for duplicates. CLI configuration is an additional input; use --strict-mcp-config when you intend to ignore other MCP sources, subject to managed policy. Server entries are selected rather than merged across scopes.

Managed MCP policy
May enforce or restrict servers

Resolve allowed server definitions

CLI: --mcp-config file or JSON
Additional configuration

--strict-mcp-config
Use CLI MCP configuration only
subject to managed policy

Normal precedence: 1. Local scope
~/.claude.json, project-specific keys

2. Project scope
.mcp.json, team shared
3. User scope
~/.claude.json, all projects
4. Plugin-provided servers
5. claude.ai connectors

Choose winning definition
No cross-scope field merge

Guide: MCP config hierarchy; MCP precedence, CLI configuration flags

Claude Code: Development Workflows 5 diagrams

TDD, spec-first, plan-driven, refinement and observed AI fluency behaviors

TDD red-green-refactor with Claude

Write a behavior test, observe why it fails, implement the requested behavior, then refactor while keeping checks green. A passing test proves only its assertions. Confirm the feature is not already present when a new test passes before implementation, and distinguish expected failures from setup errors.

Already passes

Setup error

Expected behavior failure

No

Yes

Yes

No

New behavior requested

Write behavior test
with explicit assertions

Run test

Observed result?

Check existing behavior
or strengthen assertions

Repair test environment

Claude implements
minimal behavior

Run behavior and regression tests

Checks pass?

Diagnose and fix

Refactor needed?

Refactor and rerun checks

Review assertions and change
Verified for tested scope

Guide: TDD red-green-refactor with Claude; Verification criteria

Spec-First development pipeline

A specification helps compare intended behavior with implementation; it does not guarantee that drift is impossible. The Maintain loop is a configured automation pattern: a deterministic trigger invokes Claude, an owner triages the resulting intent, and changes pass review and deployment gates. Claude Code does not start this monitoring loop merely because a spec file exists.

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

Fix or schedule

Dismiss

Requirement

Write intent.md
Problem, owner and constraints

Intent approved by owner?

Write and clarify spec.md

Human approves spec?

Generate behavior tests

Implement from spec and tests

Run checks

Checks pass?

Human review matches spec?

Revise spec or implementation

Merge after review

Deployment gate and runtime checks

Configured monitoring
Deterministic trigger

Threshold crossed?

Claude drafts intent.md

Service owner or on-call triages

Guide: Spec-First development pipeline; Anthropic AI-native SDLC playbook

Plan-Driven workflow with annotation

Use Plan mode to separate exploration from source edits. Cycle Shift+Tab until the status indicates Plan, or launch with --permission-mode plan; the number of keypresses depends on the starting mode. Review the plan, annotate it, then verify the implementation against it. This workflow is a review discipline, not a guarantee that every action will match the plan.

No

Yes

Yes

No

No

Yes

Task needs exploration

Enter Plan mode
Shift+Tab until Plan
or --permission-mode plan

Explore code and requirements

Draft plan with files and checks

Human accepts plan?

Annotate gaps
Ctrl+G to edit plan

Approve and leave Plan mode
Implement steps

Scope or assumption changed?

Run relevant checks
and compare change to plan

Evidence meets criteria?

Report result and evidence limits

Guide: Plan-Driven workflow with annotation; Explore, plan, implement

Iterative refinement loop

Use specific feedback, compare revisions, and stop when explicit criteria are met. Appearance and satisfaction alone do not establish factual correctness; run checks appropriate to the output.

Yes

No

Style or length

Missing context

Wrong approach

Yes

No

Request with criteria

Claude produces output

Compare with criteria
and run relevant checks

Criteria met?

Report result and tested scope

Identify the specific gap

What needs changing?

Specify output constraints

Provide required information

Revisit assumptions and approach

Claude revises output

Compare before and after

Evidence of improvement?

Guide: Iterative refinement loop; Provide verification and context

AI Fluency: Observed collaboration behaviors

Anthropic studied 9,830 Claude.ai conversations. Iteration appeared in 85.7% of the sample. Iterative conversations were 5.6 times as likely to show users questioning reasoning, with 2.67 versus 1.33 additional fluency behaviors. In artifact conversations, missing-context identification, fact-checking and reasoning questions were less frequent by 5.2, 3.7 and 3.1 percentage points. These are associations between conversation behaviors, not measured bug catches or proof that polished output causes acceptance bias.

9,830 sampled conversations
Observational study

Comparison 1:
Iteration observed vs absent

Comparison 2:
Artifact vs non-artifact

85.7% show iteration

Reasoning questioned
5.6x as likely with iteration

Additional fluency behaviors
2.67 vs 1.33 on average

Artifact conversations:
missing-context identification -5.2pp
fact-checking -3.7pp
reasoning questions -3.1pp

Associations, not causality
No measured defect-catch multiplier

Practice recommendation:
question assumptions and verify
with independent evidence

Guide: AI Fluency: Observed collaboration behaviors; Anthropic AI Fluency Index

Claude Code: Multi-Agent Patterns 6 diagrams

Conceptual topologies, isolated worktrees, planning, delegation and messaging

Agent teams: Conceptual orchestration topologies

Orchestrator, pipeline and specialist routing are conceptual patterns, not three native Agent Teams modes. Native Agent Teams uses a lead and communicating teammates; it is experimental and disabled by default. It adds coordination and token cost. Sequential tasks and edits to the same files often suit a single session or focused subagents better.

Choose a coordination pattern

Orchestrator + workers
Native teams: lead + teammates
Experimental, opt-in

Pipeline pattern
Stages depend on prior results

Specialist routing pattern
Choose worker by task

Worker owns frontend files

Worker owns backend files

Lead integrates and verifies

Requirements

Implementation

Review against criteria

Needed expertise?

Code worker

Test worker

Documentation worker

Guide: Agent teams: Conceptual orchestration topologies; Agent Teams availability and trade-offs

Git worktree multi-instance pattern

Worktrees give concurrent instances separate checked-out files and branches. Some repository metadata remains shared, and integrating their changes can still produce merge conflicts. Commands below assume the cloned repository root; each command creates the displayed path.

Repository root

git worktree add -b feature-A
../worktrees/feature-A

git worktree add -b feature-B
../worktrees/feature-B

git worktree add -b bugfix-C
../worktrees/bugfix-C

Claude 1: ../worktrees/feature-A
Commits to feature-A

Claude 2: ../worktrees/feature-B
Commits to feature-B

Claude 3: ../worktrees/bugfix-C
Commits to bugfix-C

Integrate changes
Resolve conflicts if present

Run integration checks and review

Merge when criteria pass

Guide: Git worktree multi-instance pattern; Git worktree semantics

Dual-Instance planning pattern

Use two sessions when a separate planning boundary is useful. A planner with no tools needs the relevant documents supplied in its prompt. Alternatively, Plan mode permits exploration with restricted actions. Configure the restriction explicitly; launching a second session does not disable tools. The executor needs the approved plan and required context, rather than inheriting the planner conversation automatically.

No

Yes

User supplies requirements
and relevant documents

Planner session
No tools explicitly configured
or restricted Plan mode

Plan: files, steps, checks
and rollback constraints

Human approves?

Transfer approved plan
and required context

Executor session
Configured tool permissions

Run checks and compare with plan

Report results and evidence limits

Guide: Dual-Instance planning pattern; Plan permission mode, Subagent tool restrictions

Horizontal scaling pattern

Parallelize independent work with explicit file ownership, then measure the result after coordination and integration. More instances do not guarantee proportional speedup; costs and dependencies can outweigh the benefit. Measure speedup and cost on the workload before making a performance claim.

Large task

Identify independent subtasks
and file ownership

Worker A
Owned files and criteria

Worker B
Owned files and criteria

Worker C
Owned files and criteria

Aggregate outputs and evidence

Resolve dependencies/conflicts
and run integration checks

Measure elapsed benefit and token cost
for this workload

Guide: Horizontal scaling pattern; Team size, cost and diminishing returns

Multi-Instance decision matrix

Choose by dependency, communication and isolation needs before choosing a worker count. The native delegation tool is Agent; Task was its former name and remains a compatibility alias in settings and definitions. There is no four-instance prerequisite for using subagents.

No

Yes

No

Yes

Yes

No

Task to complete

Independent work worth delegating?

Single session
Plan and execute stages as needed

Workers need discussion
and shared coordination?

Agent tool
Focused subagents return results
Former name: Task

Experimental Agent Teams
Lead + communicating teammates

Concurrent file edits?

Separate ownership
Worktrees for checkout isolation

Parallel research or review

Choose size by task independence
cost and coordination

Guide: Multi-Instance decision matrix; Agent tool rename and delegation, Teams versus subagents

Cross-Session messaging: Discovery & delivery

Eligible independent sessions can discover peers with ListAgents and send text with SendMessage. Same-machine delivery uses local sockets or named pipes; other-machine and cloud delivery uses Anthropic infrastructure. Explicit crossSessionInbound hold retains messages until an applicable accept releases them. Approval dialogs belong to some permission-mode defaults in supported terminals, not to the explicit hold setting. Availability depends on version, provider and Remote Control requirements.

Same machine

Other machine or cloud

accept

hold

refuse

Unset

Eligible sessions
Bind inbox and register locally

ListAgents / list-agents
Reachable peers and agents

SendMessage text
Target identified

Target location?

Unix socket / named pipe
Local delivery

Anthropic infrastructure
Remote Control or cloud session

Explicit inbound setting?

Delivered to receiving Claude

Undelivered
Later applicable accept releases

Dropped

Permission-mode default
Deliver or hold for approval
where dialog is supported

Approval/default-held queue
Subject to surface and expiry

Recipient permissions still apply
Peer text cannot approve permissions
or authorize config changes

Guide: Cross-Session messaging: Discovery & delivery; Messaging controls and availability

Claude Code: Security & Production 4 diagrams

Enforced defenses, sandbox boundaries, evidence and CI release gates

Security 3-layer defense model

Prevention, detection and response reduce different risks. Put enforced permissions and process isolation in place before running untrusted work. CLAUDE.md guides the model but does not enforce a security boundary. Sensitive-file protection needs file-tool permission rules and operating-system restrictions, not an assumed ignore-file feature. Logs must be configured and their coverage checked. Bypass permissions is appropriate only in an isolated environment, not merely because a job is labelled CI.

No

Yes

Untrusted code or content

Prevention before execution

Vet MCP/skills/plugins
review updates and pin versions

Minimal tool permissions
managed deny/ask policies

Protect sensitive files
file-tool denies + OS access restrictions

Isolate whole process when needed
container / VM, limited network

Run within configured boundaries

Detection
hooks + audit collection + alerts
verify logging coverage

Suspicious action or exposure?

Continue monitoring
Residual risk remains

Response
stop access, preserve evidence
rollback and rotate exposed secrets

Investigate exposure
and strengthen controls

Guide: Security 3-layer defense model; CLAUDE.md compliance limits, Permissions, MCP security

Sandbox decision tree

Choose the boundary that covers the process at risk. The native shell sandbox supports macOS (Seatbelt) and Linux/WSL2 (bubblewrap and socat); native Windows needs WSL2 or another isolation environment. File tools, local MCP servers and hooks run outside the shell sandbox. Unknown MCP or hooks require vetting and, where needed, isolation of the entire Claude Code process. acceptEdits auto-approves edits, so it is not a stricter alternative to manual permissions. Native sandbox default reads can include credentials unless explicitly restricted.

Yes

No, shell commands only

macOS

Linux or WSL2

Native Windows

Yes

No

Choose execution boundary

Untrusted MCP, hooks
or whole-process access?

Vet first, then isolate whole process
container / VM or dedicated runtime
restrict credentials and network

Platform?

Native shell sandbox
Seatbelt, enable via /sandbox

Native shell sandbox
bubblewrap + socat dependencies

Use WSL2, container or VM
no native shell sandbox

Restrict filesystem and network
verify actual boundaries

Keep appropriate permissions
manual + narrow allowlist when needed
review changes and evidence

Production or CI environment?

Ephemeral/isolated execution
limited secrets and deployment gates

Apply boundary for project risk
monitor residual exposure

Guide: Sandbox decision tree; Native sandbox scope and platforms, Permission modes

The verification paradox

Asking the generator for an unsupported opinion does not verify its work. Claude can run deterministic tests and show results; those checks prove only what they exercise. Review critical behavior independently and distinguish code checks from deployment readiness and observed runtime behavior. Passing checks alone do not guarantee a safe release.

No

Yes

Claude writes code

Opinion-only self-review
No runnable evidence

Defects may remain undetected

Run behavior/regression tests
inspect assertions and output

Run relevant static/security checks

Independent review of critical behavior

Evidence meets acceptance criteria?

Fix and rerun relevant checks

Release decision
known evidence scope and residual risks

Deployment checks
runtime verification and monitoring

Guide: The verification paradox; Runnable verification and adversarial review

CI/CD integration pipeline

CI should run lint, tests and security checks as explicit jobs and use their statuses as gates. Claude Code can read that evidence and produce an advisory review in non-interactive print mode, using claude -p or --print. A prompt does not itself guarantee parallel execution or trustworthy pass/fail aggregation. Configure authentication, tool permissions and job outputs explicitly; enforce release decisions through CI and human review rather than an agent opinion.

No

Yes

PR created or updated

CI configures isolated runner
auth secret + minimal permissions

CI lint job
record exit status

CI test job
record assertions and exit status

CI security scan job
record findings and exit status

Required CI jobs pass?

Report failing jobs
developer fixes and reruns CI

Collect job evidence

claude -p
Review quality-check evidence

Advisory agent review
not a replacement for CI status

Human review and branch rules

Merge/release gate
deployment and runtime checks

Guide: CI/CD integration pipeline; Print-mode CLI, Runnable verification

Claude Code: Cost & Optimization 4 diagrams

Model selection, measured cost optimization, subscription capabilities, token reduction strategies

Model selection decision flow

Use model families as candidates, then compare them against the same acceptance criteria. A lower token rate saves money only if quality and total task cost remain acceptable.

Simple and mechanical

Standard implementation

Difficult reasoning

No

Yes

Task to complete

Task type?

Try Haiku

Try Sonnet

Compare Opus and other available models

Same acceptance gate passes?

Adjust context, effort or model

Compare total cost, retries and review

Select within measured budget and allowance

Model selection

Cost optimization decision tree

Diagnose one recurring source of waste, change it, and replay comparable tasks. If the checks below explain none of the cost, investigate further before calling the baseline acceptable.

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

High cost per accepted task?

Conversation history too large?

Use /compact or a fresh session

Unnecessary output?

Request concise answers while preserving required evidence

Repeated project instructions?

Keep concise stable instructions in CLAUDE.md

Model or effort mismatched?

Compare another supported model or effort level

Noisy MCP results?

Reduce irrelevant tool output

Investigate retries, automation and other causes

Measure total cost and acceptance after the change

Keep only a measured improvement

Cost optimization strategies

Subscription tiers: What each unlocks

Separate product access from usage allowance and organization controls. Parallel CLI sessions share account capacity; they are not a Max-only capability.

Free subscription
Claude apps with limited usage
Claude Code not included

Pro
Claude Code included
Parallel CLI sessions share usage

Max
Claude Code included
5x or 20x Pro usage allowance

Team
Claude Code included
Standard or Premium seats
Team administration

Enterprise
Claude Code included
Advanced organization controls
Audit logs, SCIM and retention controls

API or supported cloud provider
Separate billing and rate limits

Usage depends on model, task and shared limits

Subscription plans & limits

Token reduction strategies pipeline

Several strategies affect the same token classes. Select one lever, replay the same acceptance gate, and compare total cost, retries and review. Keep or reject that change before testing the next lever; do not multiply advertised reduction percentages.

Yes

No

Yes

No

Measure task baseline

Select and apply ONE lever
CLI-output filtering OR history compaction
OR concise instructions OR a lower-rate model

Replay the same acceptance gate

Compare total cost, retries and review

Acceptance and cost
criteria satisfied?

Keep this change

Reject this change

Another lever to test?

Record the measured result

Cost optimization strategies

Claude Code: Adoption & Learning 3 diagrams

Onboarding paths, proposed UVAL comprehension practice, trust calibration

Onboarding adaptive learning paths

Choose a starting path based on responsibilities and existing skills. Progress when the observable criteria pass; no fixed training or team-adoption duration is implied.

Developer

Non-technical user

Team lead

New to Claude Code

Your responsibilities?

First scoped task

Practice a workflow with relevant verification

Add agents, hooks or MCP when the task needs them

Explain and verify the change; recover safely

Learn concepts and access boundaries

Practice reversible edits and explanations

Use a scope appropriate to skills and permissions

Explain the result and respect access boundaries

Define acceptance criteria and a cost baseline

Share concise conventions and controls

Run a small pilot and collect evidence

Review quality, rework, cost and feedback

Expand only when pilot criteria pass

Adoption approaches

UVAL learning protocol

UVAL is a proposed practice for checking comprehension during AI-assisted work. It does not establish a retention benefit or replace the policy for accepting a change.

Needs more practice

Assessment recorded

U: Understand First
State the problem and identify gaps

V: Verify
Check explanation and prediction against evidence

A: Apply
Test a requirement or diagnose a defect

L: Learn
Record an insight

Assess later recall or transfer

Keep evidence; do not assume internalization

The UVAL protocol

Trust calibration matrix

Assess data sensitivity, security and external effects before accepting an output. Tests and rollback establish only their verified scope; a Git revert cannot reverse data disclosure or every external action.

Yes

No

Yes

No

Yes

No

No

Yes

Claude proposes output or an action

Sensitive data, security
or external effect?

Qualified review and relevant authorization

Can the behavior be verified?

Run checks that cover the required behavior

Evidence meets acceptance criteria?

Fix, narrow scope or stop

Effects and recovery understood?

Review with a domain expert
or find another verification method

Accept only within the verified scope

Claude explanations are hypotheses
check against independent evidence

Trust calibration

Claude Code: Context Engineering 4 diagrams

Instruction scopes, context budget checks, conditional rules, rule placement

The 3-layer context system

This teaching view separates global, project and session instructions. It is not a complete inventory of organization policy, auto memory or runtime tool context. Instruction files become model context, not enforced security settings.

Global: ~/.claude/CLAUDE.md
Cross-project preferences

Project: ./CLAUDE.md or .claude/CLAUDE.md
Shared stack and conventions

Session: task instructions
Recorded in the conversation

Conditional rules
.claude/rules/*.md with paths

Root @imports
Expanded at launch

Load on matching Read, Write or Edit

Organization managed settings
Enforced policy is a separate mechanism

Instructions concatenate
Remove conflicts; no guaranteed override order

Configuration hierarchy

Context budget & adherence checks

There is no universal adherence percentage for a given line count. Review relevance and conflicts, measure the context actually loaded, then compare violations and task outcomes before and after a change.

Inventory loaded instructions

Find irrelevant or conflicting rules

Keep shared instructions concise

Scope subsystem rules to matching files

Replay representative acceptance checks

Compare loaded context, violations and rework

Keep the change only when the evidence supports it

The context budget

Monolithic vs. modular architecture

Move subsystem-specific instructions out of an always-loaded root into native conditional rules or nested CLAUDE.md files. Splitting root imports into more files changes organization but does not itself reduce startup context.

Always-loaded root
API, DB, UI and deployment rules mixed

Every task receives irrelevant subsystem context

Concise root CLAUDE.md
Shared instructions only

.claude/rules/api.md
paths: src/api/**

.claude/rules/ui.md
paths: src/components/**

.claude/rules/db.md
paths: prisma/**

Load when matching files are read, written or edited

Alternative: src/api/CLAUDE.md
Native nested instruction file

Measure loaded context and task adherence

Root @imports load at launch
No automatic token reduction

Modular architecture

Rule placement decision tree

Decide whether a requirement needs enforcement before choosing the scope of its instructional text. A skill provides reusable guidance; a permission rule, hook, script or CI gate must implement and verify any required hard stop.

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

New instruction or requirement

Requires an enforced stop,
ordering or retries?

Managed permission or sandbox policy,
hook, script, CI or workflow
Test the enforcement

Reusable procedure,
reference or judgment?

Skill directory
SKILL.md loaded when invoked or relevant

Relevant across projects?

User CLAUDE.md
Cross-project guidance

Specific files or subsystem?

.claude/rules/area.md with paths
or nested area/CLAUDE.md

Stable project guidance?

Project root CLAUDE.md

Session instruction

Repeated and stable content
is a candidate for a durable layer

Configuration hierarchy

Claude Code: Enterprise Governance 3 diagrams

Proposed risk tiers, MCP approval controls, organization data policies

Governance risk tiers: What to control and when

Choose controls by the effects and sensitivity of the work, then verify that the policy reaches the relevant session. The four tiers are proposed organization patterns, not Anthropic product tiers or regulatory certifications.

Personal isolated work

Shared team repository

Production or sensitive effects

Regulated work

Assess data, actions and environment

Work context?

Starter proposal
Scoped access and relevant verification

Team proposal
Shared conventions, review gates
and approved MCP configuration

Strict proposal
Managed permissions and sandbox controls
Approval and audit evidence

Regulated proposal
Applicable obligations and contract review
Validated technical controls

Verify the applicable controls

Managed sessions can constrain permissions,
models, login and MCP
Unmanaged devices/accounts need a separate boundary

Assess the evidence before expanding use

Governance split

MCP governance workflow

Treat the registry as organization bookkeeping and the deployed MCP configuration as a separate control. Review source integrity, permissions, data destinations and advisories; popularity or a patch version does not prove a server safe.

MCP config and managed policyOrganization MCP registryReviewer and SecurityDeveloperMCP config and managed policyOrganization MCP registryReviewer and SecurityDeveloperalt[Unacceptable risk or missing required evidence][Acceptable within approved scope]loop[On a version, permission, destination or advisorychange]Request server, source/version, use case and data scopeReview integrity, permissions, destinations and advisoriesRefuse or request evidence, record reasonTest in an isolated environment if requiredRecord exact version, restrictions and review criteriaDeploy .mcp.json and applicable managed restrictionsVerify effective policy and server behaviorRecord deployment evidence or stop if checks failReview relevant change and replay required checksRenew approval, restrict or revoke

MCP governance workflow

Data classification & Claude Code access rules

This is an example organization classification policy. Approve the processing route and test access controls for the actual data and integrations. Public content still requires action permissions and can contain malicious instructions.

PUBLIC
Public code and documentation

Policy: permitted within action permissions

INTERNAL
Non-sensitive organization material

Policy: organization-approved route and controls

CONFIDENTIAL
Business secrets and private IP

Policy: verify contracts, retention,
provider and integration controls

RESTRICTED
Customer PII, regulated data or credentials

Example policy: prohibit in AI context
Enforce and test boundaries

Permissions plus OS sandbox and MCP review
A Read rule alone does not prove no disclosure

AI usage charter

Frequently asked questions

What topics do the diagrams cover?
50 diagrams across 12 themes: Foundations, Context & Sessions, Configuration System, Architecture Internals, MCP Ecosystem, Development Workflows, Multi-Agent Patterns, Security & Production, Cost & Optimization, Adoption & Learning, Context Engineering, Enterprise Governance.
Are these diagrams free to use?
Yes. Open-source under CC BY-SA 4.0. Use, adapt, and redistribute with attribution.
How are the SVGs generated?
Diagrams are generated as SVG at build time using mermaid-cli (mmdc), with an ASCII fallback. The page uses JavaScript for guide tooltips, filtering, and navigation; rendering the diagrams does not require a Mermaid client runtime.
Where are the source files?
In guide/diagrams/ on GitHub. Each .md file contains Mermaid syntax, an ASCII fallback, and a reference to the relevant guide section.