A Claude agent succeeds when it completes the intended work, not merely when it produces a plausible final message. That sounds obvious until the system has to survive a tool timeout, a partially completed task, or conflicting outputs from two delegated workers. Under those conditions, the difference between a reliable architecture and an impressive demonstration is usually the design of the control loop.<\/p>\n
For Claude Certified Architect \u2013 Foundations<\/a>, Agentic Architecture & Orchestration is the largest published blueprint domain at 27%. The relevant skill is deciding where a model should choose an action, where the application should preserve state and enforce limits, and how several pieces of work can be coordinated without surrendering accountability. This article develops that architecture through one production-style example rather than another collection of agent definitions.<\/p>\n Imagine a compliance research assistant answering whether a proposed supplier meets an organization’s onboarding requirements. The task may require a company registry check, internal policy retrieval and review of a signed questionnaire. The assistant must report conflicts and cite the records behind its conclusion. It is not authorized to approve the supplier or update the company’s official register.<\/p>\n At first, a deterministic sequence is attractive: fetch three sources, run validation checks, produce a summary. If the required sources and order are known, orchestration code can call them directly and ask Claude to synthesize the permitted evidence once. Calling that an agent adds little value. If the assistant must select among different registries, investigate contradictions or ask for missing documents, a bounded tool-using loop can be appropriate. The application still owns the stop conditions, tool permissions<\/a>, state and review handoff.<\/p>\n The useful distinction is between a workflow<\/em>, in which code determines the path, and a model-directed loop<\/em>, in which Claude chooses the next permitted step from evidence it observes. Neither is automatically superior. The architecture should grant only the freedom necessary to solve the changing part of the problem, while leaving eligibility rules and final approval in deterministic systems.<\/p>\n With client-executed tools, Claude receives a description and input schema for each available operation. When it decides a tool is needed, the API response contains a `tool_use` block. The application executes the operation, then sends back a `tool_result` referencing the corresponding tool-use identifier. Claude can continue from that result. The model has requested work; the application has performed it. This separation is fundamental because no instruction in a model-generated argument can override the executor’s authorization policy.<\/p>\n Applications should treat `stop_reason` as part of the execution contract. A response indicating `tool_use` is not a completed answer: the client must dispatch the requested operation or return a genuine failure result. A normal end-of-turn response is not proof that every external side effect succeeded, and truncation or other stopping conditions need explicit recovery behavior. Use Anthropic’s current API documentation for the exact stop-reason names and supported model behavior rather than assuming all termination signals mean the same thing.<\/p>\n The record need not be verbose. It needs enough stable identifiers to tell a resumed run what happened without asking the model to reconstruct external state from conversation text. Tool logs and user-facing explanations answer different questions; keep both, but do not put secrets or full private records into the prompt merely to make the trace easy to read.<\/p>\n A ten-step limit prevents an endless loop, but it is a crude substitute for a stopping policy. Suppose Claude has fetched the same policy document three times and keeps asking another search tool for a perfect citation. The architecture should recognize lack of progress, not simply permit seven more searches. Similarly, reaching a configured token budget while an approval is unresolved should end in an honest escalation, not a guessed conclusion.<\/p>\n Define limits across several dimensions: model turns, tool invocations, total time, estimated cost, duplicate operations, error rate and consequence level. A repeated read may be harmless but wasteful. A repeated write may be costly or dangerous. Mark certain operations as human-gated, and attach explicit failure states to tool outputs so the system cannot mistake an authorization denial for an empty answer.<\/p>\nChoose the control structure before choosing the number of agents<\/h2>\n
What happens in a real tool-use loop<\/h2>\n
\n
\n \nEvent<\/th>\n What the orchestrator should record<\/th>\n Next safe action<\/th>\n<\/tr>\n<\/thead>\n \n Model requests registry lookup<\/td>\n Tool-use ID, requested supplier identifier, permitted identity, deadline<\/td>\n Check authorization and input; dispatch read-only lookup<\/td>\n<\/tr>\n \n Registry returns current evidence<\/td>\n Result timestamp, source identity, document version, tool status<\/td>\n Return structured result for Claude’s next permitted decision<\/td>\n<\/tr>\n \n Lookup times out<\/td>\n Unknown execution status and whether the tool is idempotent<\/td>\n Reconcile outcome or retry safely; never invent a successful result<\/td>\n<\/tr>\n \n Model asks for approval action<\/td>\n Request denied by application policy, pending review state<\/td>\n Stop model-side action and route to authorized human workflow<\/td>\n<\/tr>\n \n Analysis complete<\/td>\n Evidence inventory, unresolved conflicts, final output version<\/td>\n Validate synthesis and hand off as a recommendation, not an approval<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Bounded loops need more than a maximum turn count<\/h2>\n