Glossary

A repeating cycle where Claude receives input, reasons about it, optionally invokes tools, observes results, and decides whether to continue or stop. The loop is governed by stop_reason values returned by the API.

A settings array that specifies which tools Claude Code can use without asking for permission. Supports glob patterns for matching tool names. Tools not in this list require user approval before execution.

An API parameter that marks content as cacheable for prompt caching. Placed as a property on message content blocks with type: "ephemeral". Content up to and including the marked block is cached for reuse in subsequent requests.

A prompting technique that asks Claude to show its reasoning step-by-step before providing a final answer. Improves accuracy on complex reasoning tasks by forcing intermediate reasoning steps.

Running Claude Code in non-interactive mode within continuous integration pipelines. Uses the --print flag for single-shot execution and --dangerously-skip-permissions for automated environments where no human can approve tool use.

A Python framework for building production agentic systems with Claude. Provides primitives for agents, tools, guardrails, handoffs between agents, and tracing. Designed for multi-agent orchestration with built-in safety features.

A markdown file that provides persistent context and instructions to Claude Code. Can be placed at project root, user home directory (~/.claude/CLAUDE.md), or in subdirectories. Claude reads these files at session start to understand project conventions.

The maximum number of tokens Claude can process in a single API call, including both input and output. Claude's context window size varies by model. All content (system prompt, conversation history, tool definitions, and response) must fit within this limit.

A stop_reason value indicating Claude has voluntarily finished its response. In an agentic loop, this signals that Claude believes the task is complete and no further tool calls are needed.

Strategies for handling failures in agentic systems, including retry with exponential backoff, graceful degradation, fallback tools, and providing error context back to Claude so it can self-correct.

A parallelization pattern where a task is split into independent subtasks (fan-out), each processed concurrently, and results are aggregated (fan-in). Reduces latency for tasks with independent components.

Concrete input-output pairs included in the prompt to demonstrate the desired behavior. Examples teach Claude the expected format, style, and reasoning pattern more effectively than abstract instructions alone.

A safety mechanism that constrains Claude's behavior within defined boundaries. Guardrails can operate on input (pre-processing validation), output (post-processing filtering), or tool use (restricting which tools can be called and with what parameters).

A shell command that executes at specific lifecycle points in Claude Code. Hooks run before tool calls (PreToolUse), after tool calls (PostToolUse), and on notifications. They enable logging, validation, and custom automation.

A pattern where the agentic system pauses execution to request human approval before proceeding with sensitive operations. The human can approve, reject, or modify the proposed action.

The JSON Schema object within a tool definition that specifies the structure, types, and constraints of the tool's input parameters. Follows standard JSON Schema with properties, required fields, and descriptions.

A conversation that approaches or exceeds the context window limit. Requires management strategies such as summarization, sliding window truncation, or context compression to continue meaningfully without losing critical information.

A component that connects to one or more MCP servers, discovers their capabilities, and makes them available to the LLM. The client manages the lifecycle of server connections and translates between the MCP protocol and the LLM's tool format.

A process that exposes tools, resources, and prompt templates over the Model Context Protocol. MCP servers can be implemented in any language and communicate via stdio or HTTP (SSE) transport.

The communication layer between MCP clients and servers. Two standard transports: stdio (local processes communicating via stdin/stdout) and HTTP with Server-Sent Events (remote servers). Stdio is simpler; HTTP enables remote deployment.

Observing and measuring the behavior of Claude-powered systems in production. Key metrics include latency, token usage, error rates, tool call patterns, and output quality scores. Essential for maintaining reliability and controlling costs.

An architecture where multiple specialized agents collaborate on a task. Each agent has its own system prompt, tools, and guardrails. Agents communicate through handoffs or a central orchestrator.

An architecture for coordinating multiple Claude API calls or agents. Common patterns include prompt chaining (sequential), routing (conditional dispatch), parallelization (fan-out/fan-in), and evaluator-optimizer loops.

Verifying that Claude's response meets expected criteria before using it downstream. Includes JSON schema validation, content safety checks, format verification, and semantic correctness checks using a second LLM call.

A configuration that controls which tools Claude Code can use and which require approval. Permissions are set in settings files and follow a hierarchy from user-level to project-level configuration.

A hook that fires after a tool completes execution in Claude Code. Receives the tool name, input, and output. Cannot prevent execution (already happened) but can log results, trigger notifications, or perform cleanup.

Starting the assistant's response with specific text to guide Claude's output format or direction. Done by including a partial assistant message in the API call. Forces Claude to continue from the provided prefix.

A hook that fires before a tool is executed in Claude Code. Receives the tool name and input as environment variables. Can block execution by returning exit code 2, or modify the operation. Used for validation and logging.

Patterns for building robust Claude-powered systems: retry logic with exponential backoff, circuit breakers, fallback models, graceful degradation, health checks, and deployment strategies like canary releases.

An API feature that caches repeated prompt prefixes to reduce cost and latency on subsequent calls. Marked with cache_control breakpoints. Cached content is reused when the prefix matches exactly, reducing input token costs by up to 90%.

A sequence of Claude API calls where the output of one call feeds into the input of the next. Each step performs a focused transformation, validation, or decision. Chains decompose complex tasks into manageable steps.

The iterative process of refining prompts to improve output quality, reduce cost, or increase reliability. Techniques include prompt compression, example selection, instruction clarification, and A/B testing against evaluation datasets.

An MCP capability that provides reusable prompt structures. Servers expose prompt templates with defined arguments that clients can fill in. Useful for standardizing interactions across different clients.

API-enforced limits on request frequency and token throughput. Claude's API has rate limits per minute (RPM) and tokens per minute (TPM). Exceeding limits returns 429 status codes. Managed with queuing, backoff, and request batching.

An MCP capability that exposes data to the LLM. Unlike tools (which perform actions), resources provide read-only access to content like files, database records, or API responses. Resources have a URI and return text or binary content.

A pattern for handling transient API failures by retrying requests with increasing delays. Exponential backoff (doubling wait time) with random jitter prevents thundering herd problems. Only retry on retryable errors (429, 500, 529).

An orchestration pattern where an initial classification step determines which specialized agent or prompt chain handles the request. Useful when different input types require fundamentally different processing.

The order in which Claude Code resolves configuration: user-level (~/.claude/settings.json), project-level (.claude/settings.json), and enterprise-managed settings. More specific settings override general ones, with security exceptions.

A custom command invoked with a / prefix in Claude Code. Built-in commands include /help, /clear, and /compact. Custom slash commands can be defined via .claude/commands/ directory with markdown files that serve as prompt templates.

A field in the Claude API response indicating why generation stopped. Values: end_turn (Claude finished voluntarily), tool_use (Claude wants to call a tool), max_tokens (output limit reached).

Techniques for getting Claude to respond in a specific format like JSON, XML, or a defined schema. Achieved through tool use (forces JSON matching the schema), system prompt instructions, or prefilling the assistant response.

A context management technique where older conversation messages are compressed into a concise summary. The summary replaces the original messages, freeing context window space while preserving key information for continued conversation.

The initial instruction block sent to Claude that establishes behavior, persona, constraints, and context for the entire conversation. System prompts are processed first and influence all subsequent responses.

A parameter (0.0 to 1.0) controlling randomness in Claude's responses. Lower values produce more deterministic, focused output. Higher values increase creativity and variation. Default is 1.0.

Measuring the number of tokens in prompts and responses to manage costs and stay within context window limits. Anthropic provides a token counting API endpoint. Accurate counting is essential for budget management and context window planning.

A mechanism for requiring user confirmation before a tool executes. Configured through permission settings that classify tools as allowed, denied, or requiring approval based on the tool name or server.

The practice of returning structured error information from tools so Claude can understand what went wrong and attempt recovery. Tool results should include is_error: true and a descriptive message rather than throwing exceptions.

A JSON Schema definition that describes a tool's name, purpose, and input parameters. Claude uses the schema to understand what the tool does and how to construct valid inputs. Well-designed schemas include clear descriptions and constrained types.

Claude's process of choosing which tool to invoke based on the user's request and available tool schemas. Affected by tool names, descriptions, parameter schemas, and system prompt guidance.

A content block type in the Claude API response indicating Claude wants to invoke a tool. Contains the tool name, a unique ID, and the input parameters matching the tool's JSON schema.

A Git feature that allows multiple working trees attached to the same repository. Claude Code supports worktrees for parallel development: run multiple Claude Code sessions on different branches of the same repo simultaneously.

A prompting technique using XML-style tags to structure input and output. Claude responds well to tags like <instructions>, <context>, <example>, and <output> for clearly delineating sections of complex prompts.