Claude Agent and Workflow Architecture Decision Framework

Use the least complex Claude architecture that can meet the task's uncertainty and control requirements. Choose one model request for a bounded transformation, a deterministic workflow when code can define the steps and branches, a single agent when the model must choose the next action from changing evidence, and a manager-and-subagent design only when genuinely separable work benefits from specialized or parallel delegation. Promote a solution to the next level only when representative evaluations show that the added autonomy improves outcomes enough to justify more latency, token use, security exposure, observability work, and recovery complexity.

“Autonomous agent” does not mean unconstrained or unsupervised. Its objective, tools, permissions, budgets, stop conditions, and escalation paths remain application-defined. The architecture decision is therefore about where control resides at each step: in one request contract, in deterministic application code, in a bounded agent loop, or in a coordinator that delegates typed tasks to bounded workers.

Architecture Overview: Four Levels of Control

Anthropic's building effective agents guidance distinguishes workflows, whose model calls and tools follow predefined code paths, from agents, where a model dynamically directs its own process and tool use. That distinction supports a practical complexity ladder.

Architecture	Where the sequence is decided	Best fit	Main cost of adoption
Single model request	One application-defined request and response contract	One bounded inference or transformation	Limited opportunity to inspect, correct, or gather more evidence mid-task
Deterministic workflow	Application code and explicit branches	Known steps, stable routing rules, and auditable checkpoints	More orchestration code and intermediate-state handling
Single agent	A bounded model-directed loop	Open-ended tasks where the next step depends on observations or tool results	Variable paths, harder evaluation, and greater cost and recovery variance
Manager with bounded subagents	A coordinator delegates defined tasks and synthesizes results	Decomposable specialist or parallel work whose isolation has measurable value	Coordination overhead, compounded failures, and more complex permissions and tracing

These are not maturity levels. A deterministic workflow can be the stronger production design even when an agent is technically possible. Likewise, a single request can be the most reliable architecture for a narrow task.

Start with the Smallest Architecture That Can Close the Task

Use a single request for one bounded judgment

A single model request is appropriate when the application can provide all necessary instructions and evidence up front and consume one response under a clear contract. Typical shapes include classification, extraction, rewriting, summarization, or a constrained recommendation that requires no external action between reasoning steps.

This architecture minimizes moving parts and usually offers the clearest latency, token, and failure envelope. It becomes insufficient when the task must gather additional evidence, inspect an intermediate result, invoke a tool, or condition later work on an earlier outcome.

In this article, “single request” describes execution architecture. It is separate from zero-shot, single-shot, and multi-shot prompting, which describe the use of examples inside a prompt.

Use a deterministic workflow when the path is knowable

A deterministic workflow uses application code to order model calls, tools, validators, and human approvals. It fits tasks whose stages are known even if Claude performs judgment within individual stages. Examples include classify-then-route, extract-then-validate, draft-then-review, or retrieve-then-summarize processes.

Prefer explicit code branches when the branching rule can be stated and tested deterministically. The workflow can record input and output at each boundary, retry one failed stage, resume from a checkpoint, and require approval before a sensitive action. It also prevents the model from spending calls rediscovering a process the application already knows.

Deterministic does not mean that every model response is predictable. It means the application owns the sequence, permitted branches, and transition rules.

Use a single agent when the next step depends on discovery

A single agent becomes useful when a fixed sequence would require an impractical number of branches because the next useful action depends on evidence found during execution. Within a bounded loop, the model can choose among permitted actions, inspect results, update its plan, and continue until it meets a stop condition or escalates.

Good candidates have an open-ended path but a verifiable outcome: investigating an unfamiliar repository, resolving a multi-source research task, or diagnosing a system through several possible observations. Poor candidates have a stable process, weak success criteria, irreversible side effects, or no defensible way to decide when work is complete.

The loop still needs application controls. Define allowed tools, maximum work or spend, approval points, termination signals, evidence requirements, and what state is safe to resume. The implementation of that loop belongs in Building Claude Agents with the Agent SDK, Custom Loops, and Frameworks.

Add a manager only for bounded decomposition

A manager or supervisor coordinates work rather than performing every specialist step in one context. It can decompose an objective, delegate bounded tasks, monitor completion, reconcile results, and decide whether another task is necessary. This pattern is justified when work divides into independent or specialist units and the returned evidence can be checked before synthesis.

Examples include reviewing several independent components, researching separate evidence categories, or applying different permission sets to different work. Delegation is a poor fit when subtasks share tightly coupled state, require constant cross-worker negotiation, or return results that the manager cannot validate.

A hierarchy should remain as shallow as the task permits. Each added coordinator or worker creates another request boundary, permission surface, trace, timeout, and failure mode.

Evaluate the Decision Across Seven Dimensions

Architecture choice should be based on a representative workload, not on the appeal of autonomy.

Dimension	Favor simpler execution when	Consider more agentic execution when
Task uncertainty	Inputs, steps, and branches are known	Useful next actions emerge only after observing results
Control	The application must guarantee the sequence	The application can bound actions while allowing sequence flexibility
Evaluation	Correctness can be scored at one output or fixed checkpoints	Success can be evaluated across variable but observable trajectories
Latency	A predictable response budget matters	Parallel discovery or adaptive action materially improves completion
Cost	One or a few calls meet the quality target	Additional calls and context produce measured quality gains
Security	Permissions are broad or actions are hard to reverse	Tools can be narrowed, approvals inserted, and effects isolated
Recovery	A fixed stage can be retried or resumed directly	Variable plans can be checkpointed, reconstructed, and safely stopped

Treat these dimensions as interacting constraints. Parallel subagents may reduce wall-clock time while increasing total token use. A single agent may remove orchestration code while making trajectories harder to reproduce. A workflow may require more explicit code while simplifying security review and recovery.

Require evaluation evidence before escalating complexity

Compare candidate architectures on the same representative tasks. Measure task success and safety outcomes together with request count, token use, latency distribution, tool errors, approval frequency, unrecoverable states, and human intervention. Include routine, boundary, ambiguous, and adversarial cases.

An agent should earn its additional freedom by solving cases the simpler workflow misses. A manager-and-subagent design should earn its coordination overhead through better isolation, specialization, or parallel performance. If quality does not improve materially, keep the simpler design.

Formal dataset design, evaluators, trace diagnosis, and release gates belong to the series' evaluation guidance; this decision framework identifies the architecture questions those evaluations must compare.

Define a Bounded Delegation Contract

Delegation is safer and easier to evaluate when every subagent receives a contract rather than a broad invitation to “help.” Define:

one objective and an explicit completion condition;
allowed inputs and authoritative sources;
permitted tools, data scopes, and side effects;
a time, call, or token budget;
the required result shape and supporting evidence;
conditions for clarification, refusal, or escalation; and
whether the worker may delegate further.

The manager should validate returned evidence before using it, handle conflicts explicitly, and distinguish an incomplete result from a completed negative finding. It should not treat a fluent summary as proof that the worker followed its contract.

Use separate workers to create real isolation, not merely more model calls. Context selection, compaction, memory, and what evidence returns to the coordinator are covered in Context and Memory Management for Claude Applications and Agents.

Place Human Control at Consequential Boundaries

The more authority an architecture gives to model-selected actions, the stronger its deterministic controls must become. Human review is especially useful when an action is irreversible, externally visible, privileged, financially consequential, or based on weak evidence.

Design approval as an application transition. Present the proposed action, relevant evidence, expected effect, and rollback options; then issue narrowly scoped authority only after approval. Do not encode approval as a sentence in a prompt or assume that a manager agent automatically makes a worker's action safe.

Tool schemas, safe execution, result handling, and approval patterns are implementation concerns covered in Implementing Claude Tools with Safe Execution and Approval Patterns. At the architecture level, decide which component may propose an action, which deterministic control authorizes it, and which component records the outcome.

Design Failure and Recovery Before Adding Autonomy

Recovery exposes architecture quality. For every level, ask what persists after interruption, which actions are idempotent, which effects require compensation, and how an operator can determine the last trustworthy state.

A single request can usually be retried only if duplicate downstream use is prevented.
A workflow can checkpoint stage transitions and retry the smallest failed stage.
A single agent needs a bounded execution record, stop reason, completed-action ledger, and resumable task state.
A manager architecture needs worker identities, task states, deadlines, partial-result rules, duplicate-dispatch protection, and a policy for manager failure.

Do not let the model infer whether an external action already occurred when the owning system can provide an authoritative status. Recovery should use application records and idempotency controls rather than conversational confidence.

Keep Deployment Choice Separate from Control Architecture

The architecture pattern does not by itself select a hosting model or library. A deterministic workflow, single agent, or manager pattern can be implemented through different application-controlled runtimes. The current Claude Agent SDK documentation describes Anthropic's agent development surface, but selecting an SDK or framework follows the control decision rather than replacing it.

Claude Managed Agents is a beta managed runtime as verified on 2026-08-28 and requires the managed-agents-2026-04-01 beta header on every endpoint. Treat that contract as time-sensitive and recheck it before use. Managed execution may change operational responsibilities, but it does not remove the need to bound objectives, tools, permissions, evaluation, human approval, and recovery.

Avoid choosing a framework because its terminology matches a diagram. Adopt an abstraction only when it reduces implementation or operational risk for the selected pattern without hiding state transitions, permissions, or failure behavior the team must control.

A Practical Selection Sequence

Use this sequence during architecture review:

Define the outcome, evidence, prohibited effects, and human escalation boundary.
Test whether one request can produce the outcome from available inputs.
If multiple known stages are required, model them as a deterministic workflow.
If the next step truly depends on discoveries made during execution, evaluate a bounded single agent against that workflow.
If the task decomposes into independently verifiable specialist or parallel units, evaluate a manager with bounded subagents against the single agent.
Compare quality, latency, cost, security events, operator burden, and recovery on representative cases.
Select the least complex candidate that passes the quality and safety gates, then record what evidence would trigger reconsideration.

This sequence does not make one architecture universally correct. It makes the decision explicit, testable, and reversible.

Common Architecture Mistakes

Starting with a multi-agent hierarchy. First prove that one request, a workflow, or one bounded agent cannot meet the outcome.
Calling a fixed sequence an agent. If application code selects every step, describe it as a workflow even when individual steps use Claude.
Using autonomy to compensate for unclear requirements. An agent cannot create trustworthy success criteria on behalf of the product owner.
Delegating tasks that cannot be verified. A manager needs evidence and completion rules, not only worker summaries.
Sharing broad permissions across workers. Scope tools and data to each bounded responsibility.
Ignoring total cost when parallelism reduces latency. More concurrent work may finish sooner while consuming more calls and tokens.
Assuming more context replaces decomposition. Context size, durable memory, and task isolation are separate design decisions.
Treating managed execution as managed correctness. Hosting does not establish task boundaries, evaluation, authorization, or recovery policy.
Selecting a framework before the pattern. Decide the control architecture first, then choose the smallest useful implementation abstraction.

Relevance to Claude Certified Developer – Foundations

The Claude Certified Developer – Foundations Exam Guide v1.0 includes decisions between deterministic workflows and agents, manager or supervisor hierarchies, bounded subagent delegation, and framework or deployment tradeoffs within its Agent Architecture and Agent Patterns and Frameworks scope.

The durable skill is not memorizing a preferred pattern. It is locating control deliberately and requiring evidence for every increase in autonomy: deterministic code owns known transitions, a bounded agent owns uncertain next-step selection, a manager owns delegation and synthesis, and application controls retain authorization, observability, and recovery.

Conclusion

Choose a Claude agent or workflow architecture by escalating complexity only when the task requires it. A single request serves bounded inference, a deterministic workflow serves known stages and branches, a single agent serves discovery-dependent action, and a manager with bounded subagents serves independently verifiable specialist or parallel work.

Evaluate each choice against quality, autonomy, latency, cost, security, and recovery. No SDK, framework, large context window, or managed runtime removes the need for explicit objectives, permissions, stop conditions, evidence, and human control.