Choosing Single-Shot, Workflow, and Agentic Claude Architectures

Introduction

The right Claude architecture is usually the least autonomous one that can complete the job safely. Start with a single model call when one bounded response is enough. Add an application-controlled workflow when the steps, validations, or side effects must be explicit. Use an agentic loop only when the system genuinely needs to choose and sequence actions in response to intermediate results.

This distinction is grounded in ownership. The Claude Agent SDK overview describes the SDK as a way to run the Claude Code agent loop in an application, while a direct API integration leaves the application to implement its own tool loop. Architecture selection therefore decides who controls iteration, rather than merely which API surface is called.

Architecture Overview

Three patterns cover many Claude solution designs:

A single-shot interaction sends bounded input and consumes one response.
A deterministic workflow places the model inside application-owned stages, such as extraction, validation, approval, and delivery.
An agentic architecture lets Claude evaluate state, request tool actions, receive results, and repeat until the task completes or a control stops it.

Decision factor	Single Claude call	Deterministic workflow	Agentic system
Sequence ownership	The application prepares the input and handles the result.	The application prescribes each stage and transition.	Claude selects the next permitted action from intermediate results.
Tool use and iteration	Typically no direct tool use or iterative task loop.	The application invokes tools at defined stages and manages retries.	Claude can choose from an allowed tool surface and adapt its next action.
Best-fit trigger	One bounded response can satisfy the outcome.	The work has known stages, validations, or approvals.	Tool results must determine a path that is impractical to predefine.
Cost or latency predictability	Generally the most predictable because the interaction is bounded.	Predictable from the defined stages, subject to their fixed dependencies.	Least predictable because the amount of adaptive work can vary.
Risk or approval boundary	The application validates output before any side effect.	The application enforces approval gates at chosen transitions.	The host restricts available capabilities and enforces approval boundaries.

These patterns are not maturity levels. A single-shot interaction can be the strongest design for a tightly scoped classification or drafting task. An agent is valuable when fixed application logic cannot reasonably anticipate the correct investigation or action sequence.

Core Components

Single-shot model interaction

Choose a single-shot interaction when the application can define all necessary inputs up front and a response does not require external investigation or iteration. Examples include producing a human-readable summary of supplied text or classifying a request into a known set of routes. The application owns input preparation, output validation, retries, and any side effect after the response.

This pattern has the smallest operational surface: no tool-selection loop, no session continuity requirement, and no autonomous attempt to recover from an incomplete result. It is a strong default when determinism, latency, and cost predictability matter more than flexible exploration.

Deterministic workflow

Choose a workflow when the work has multiple stages but the application can prescribe their order. For example, an application may retrieve approved data, ask Claude to produce a draft, validate the draft against a schema, request human approval, and then write the approved result. Claude contributes reasoning inside individual stages, while application code keeps control of state transitions and enforcement.

This pattern is appropriate when each step needs independent logging, validation, retry policy, or authorization. It also makes failures easier to localize: a team can distinguish a retrieval fault from a model output that failed validation without asking an agent to infer the recovery policy.

Agentic system

Choose an agentic system when the path to completion depends on what the system discovers. The agent-loop documentation describes the cycle as Claude evaluating the current state, requesting tools, receiving results, and repeating until it returns a response without tool calls. That loop can support tasks such as investigating a codebase, but it introduces additional responsibilities for permissions, cost, context, and stopping conditions.

An agentic design is not a substitute for a business process. The host must still define available tools, approval policy, maximum work, expected output, and escalation behavior. Use it where adaptive sequencing provides more value than the added uncertainty and operational overhead.

How Components Work Together

The selection process should move from evidence to autonomy:

Define the outcome and acceptable failure mode.
Identify whether external data or actions are required after the first response.
Determine whether the application can express the action order as a workflow.
Add an agent loop only if intermediate tool results must change the next action in ways that are not practical to enumerate.

This process allows mixed designs. A workflow can contain one bounded agent step, and an agent can use deterministic application services for sensitive operations. The key is to preserve a clear control boundary: a model may propose an action, while the application validates whether that action may run.

Design Considerations

Autonomy, tools, cost, and risk

Assess the patterns against the same questions. A single-shot call has low autonomy and typically no direct tool access. A workflow can call tools, but the application selects when each tool runs. An agent may select from an allowed tool surface and revisit its plan after each result. That flexibility should be balanced against the cost of extra turns, additional context, and the possibility of unexpected action sequences.

The agent-loop documentation states that the Agent SDK can limit tool-use turns and spending with max_turns/maxTurns and max_budget_usd/maxBudgetUsd. These controls are useful when an agent is justified, but they do not make an overly broad task safe by themselves. A well-bounded prompt, restricted tools, and clear handling of limit results remain necessary.

Best Practices

Prefer a single-shot design when it meets the acceptance criteria. Prefer an application-controlled workflow when ordering, validation, or approval needs to be predictable. Adopt an agent when adaptive tool use is essential and the team can operate its controls.

For any pattern, make side effects explicit. Validate inputs before they reach a privileged service, restrict credentials to the smallest required scope, and record enough telemetry to explain a failed or costly run. These are architectural recommendations; the exact controls depend on the deployment environment and organization.

Common Mistakes

The most common mistake is using an agent because a task has more than one step. Multiple steps alone do not require autonomy; a workflow is often easier to test, secure, and maintain.

Another mistake is hiding a high-impact action behind a seemingly harmless tool name. Tool access is capability access. The tool use overview should be read together with the application's authorization model, because the caller must control which tools are available and how their results are handled.

Certification Relevance

For the public CCAR-F agentic architecture and orchestration scope, the valuable skill is a defensible tradeoff: match autonomy to the task rather than adopting an agentic pattern by default. This article does not teach the mechanics of running an agent loop or coordinating multiple agents; those are separate design concerns.

Conclusion

Choose a single-shot call for bounded reasoning, a deterministic workflow for known stages and enforceable controls, and an agentic architecture for genuinely adaptive tool-driven work. The selection is sound when the added autonomy has a stated benefit and its cost, risk, and authority are bounded by the host application.