Introduction

An agentic design becomes operable only when its runtime is bounded. In the Claude Agent SDK, an agent loop evaluates the current state, requests tools when needed, incorporates their results, and eventually returns a final result. A production host must decide what the agent may do, how long it may continue, which prior state it may reuse, and how it stops or escalates safely.

The agent-loop documentation describes this runtime as the loop that powers Claude Code and that applications can embed through the SDK. This article focuses on that single-agent lifecycle and its controls. It does not prescribe how work should be divided across multiple agents.

Architecture Overview

The runtime has five practical phases: initialize the task and controls; let Claude evaluate the available context; execute authorized tool requests; feed results back into the loop; then inspect the terminal result and record the outcome. Every phase has a host responsibility. The SDK supplies an execution model, but the host application defines the task, tool surface, permission policy, limit handling, and business-level completion criteria.

This separation matters because a text response is not necessarily a successful operation. A host may require evidence that a tool result was valid, that a write was approved, or that a requested outcome passed a downstream check before it treats the run as complete.

Core Components

Agent-loop lifecycle and tool iteration

According to How the agent loop works, a run receives a prompt with its system context, tool definitions, and conversation history. Claude can respond with text, tool calls, or both; the SDK executes requested tools, returns their results to Claude, and repeats the cycle until Claude emits a response without tool calls. The final result includes the output, usage, cost, and session identifier.

Architects should make the tool surface intentional. A read-only research agent may need retrieval tools but not write or command execution. If a tool can make an external change, the host should apply authorization and approval controls before the side effect. A denied tool is still useful information to the agent, but a denial must not be silently treated as successful work.

Sessions: continue, resume, and fork

A session is accumulated conversation history: prompts, tool calls, tool results, and responses. The sessions documentation states that sessions are persisted automatically and can be continued, resumed by identifier, or forked to explore an alternative. It also makes a critical distinction: sessions preserve conversation history, not filesystem state.

Use continuation when a follow-up should retain the earlier investigation. Use resume when a process interruption or later request needs a specific prior context. Use a fork when an alternative approach should not overwrite the original conversational path. These choices are about context continuity; use your system's own transaction, artifact, and checkpoint mechanisms for durable changes and rollback.

Permissions and approval boundaries

Permissions determine which requested tools can run automatically, which require approval, and which are blocked. The Agent SDK permission controls should be treated as a runtime policy layer, not as a replacement for service authorization. Define an allowlist for the normal task, explicitly deny capabilities that the task never needs, and require human or policy approval where the effect is consequential.

The agent-loop documentation also explains that permission mode works together with allow and deny rules. For a headless runtime, a hard-deny posture for everything outside a narrow approved surface is generally easier to reason about than an open-ended permission prompt. Reserve broad permission bypasses for isolated environments that have been explicitly designed for them.

How Components Work Together

Consider a bounded investigation run. The host starts a session with a task, a read-oriented tool set, a turn limit, and a cost ceiling. Claude inspects the supplied context, calls an allowed tool, and receives the result. If the result is insufficient, it may take another allowed action; if it reaches a limit or cannot obtain permission, the host records a controlled incomplete result and escalates or asks for input.

This design avoids two unsafe interpretations: that the agent should continue indefinitely until it finds an answer, or that a tool denial means a different privileged action is acceptable. The host owns those escalation decisions.

Design Considerations

Budgets and stopping conditions

The agent-loop documentation documents max_turns/maxTurns for tool-use round trips and max_budget_usd/maxBudgetUsd for spending. When a limit is reached, the SDK returns a result with an error subtype rather than a normal completed result. Configure limits from the task's expected cost and complexity, then make the caller handle each limit outcome explicitly.

Stopping conditions should exist at more than one level. Runtime limits protect cost and duration; tool permissions protect capability boundaries; application success criteria determine whether the result can be used; and human escalation handles cases that require judgment or elevated authority. These controls are complementary.

Context compaction and state selection

The context window includes the system prompt, tool definitions, conversation history, tool inputs, and tool outputs. The agent-loop documentation notes that the SDK can compact older history as the context window approaches its limit, retaining recent exchanges and key decisions in a summary. Compaction can reduce available detail, so a runtime should not rely on an early conversational instruction as the only durable source of policy.

Keep stable rules in the host's configured instructions, retain structured state outside the conversation when it must survive summarization, and avoid injecting large low-value tool outputs. This is context discipline, not a reason to put every historical artifact into a prompt.

Common Mistakes

One mistake is implementing only a turn limit and calling the runtime controlled. A limit may stop excessive work, but it does not define safe permissions, business success, or a recovery path.

Another mistake is resuming a session as if it restores external system state. A session restores conversational context; external writes, file changes, and credentials require their own verification and lifecycle controls.

Certification Relevance

Within the public CCAR-F agentic architecture and orchestration scope, an architect should be able to explain how iteration, sessions, permissions, budgets, context, and stopping conditions work together. The target is a bounded single-agent runtime, not a multi-agent coordination strategy or a tool-interface specification.

Conclusion

A safe Claude agent runtime is a controlled loop, not an unrestricted conversation. Give it the smallest useful tool surface, retain only the session context that supports the task, set explicit turn and cost limits, treat compacted history carefully, and route denied, failed, or incomplete work to a defined host-level outcome.

Authoritative Sources