For most of the past few years, building an AI agent meant wiring a model to a few tools and hoping the prompt held. The architecture was simple because the task was simple: one shot, one response. What has changed — and what makes the current moment genuinely different — is the loop. The ability to let a model call a tool, inspect the result, and decide what to do next sounds mechanical, but it is the ingredient that crosses the threshold from “smart autocomplete” to something that can actually pursue a goal over multiple steps.
Anthropic’s Claude Certified Architect exam, released in March 2026, is worth paying attention to not because certification matters in itself, but because of how it is structured. Rather than testing abstract knowledge, it drops candidates into six production scenarios and asks them to diagnose what is going wrong. That framing — anti-patterns first — turns out to be a surprisingly honest map of where agentic engineering tends to break.
The loop is not optional
The theoretical grounding here goes back to 1966: Böhm and Jacopini showed that any computation can be expressed with just sequences, conditionals, and loops. AI systems have had the first two for a while. The loop is what is new, and getting it right is the first lesson the exam hammers home.
The most common mistake when building an agentic loop is treating the model’s response as finished output the moment it arrives. It is not. Every iteration should inspect `stop_reason` — the field in the API response that says why the model stopped generating. If the reason is `tool_use`, the model has produced parameters for a tool call; the surrounding code needs to execute that tool and feed the result back. (The model itself cannot run tools — it only describes what it wants to call and with what inputs.) If the reason is `max_tokens`, the response was cut off mid-thought, and using it as-is means acting on an incomplete answer. That is a quiet failure mode that causes real bugs in production.
Specialize agents; starve them of context they do not need
The multi-agent scenario surfaces two related mistakes that practitioners tend to make once they have the loop working and start scaling up.
The first is tool overload: building one orchestrator agent and handing it every tool in the system. A useful analogy is a carpenter who shows up carrying plumbing and electrical gear as well. The extra tools do not make the carpenter more capable at carpentry — they add noise and surface area for mistakes. The pattern that holds up is the opposite: one agent, one or two tools, one job. This mirrors functional programming’s single-responsibility principle and for the same reasons — narrower scope means fewer failure modes and easier debugging.
The second mistake is passing full context between agents. When a critic agent receives not just the claim it is supposed to evaluate but also the reasoning trace that produced it, the critique tends to follow the same path. Agents converge. The fix is to pass only the slice each agent actually needs: a critic gets the claim and the evidence, not the chain of thought behind it. Context is tokens, and tokens are money and confusion in equal measure. A million-token context window does not mean filling it is free or neutral.
Fork subtasks; compact early
As agents run longer, context accumulates. Subtask output in the main thread is one of the fastest ways to blow past the point where the model is still reasoning well rather than just pattern-matching on a very long input.
The practical response is context forking: when a subtask starts, spin up an isolated subthread for it. The subtask accumulates its own tokens there. Only a summary of its result is injected back into the main thread. Monitor the main thread’s token count and compact it before it becomes a problem — not after.
Non-interactive pipelines and the cost of confirmation prompts
One scenario covers Claude Code running inside a continuous integration pipeline, and the failure mode is familiar to anyone who has tried to automate an interactive tool: the system stops and waits for a human to confirm a permission. In an unattended CI run, that means a hang. The fix is straightforward — configure the tool for non-interactive mode — but it has to be deliberate. Interactive confirmation is the default; pipeline operators have to override it explicitly.
A practical side note from the same scenario: Anthropic’s batch API offers 50 percent cheaper token costs for workloads that can tolerate results arriving within 24 hours. For overnight processing jobs, that is a significant saving.
What the pattern suggests going forward
Three principles recur across nearly every scenario: always inspect `stop_reason`, isolate context aggressively (both at the agent and the thread level), and compact early rather than late. None of these are glamorous. They are the kind of operational discipline that separates a demo that works once from a system that holds up in production.
The honest read on agentic engineering right now is that the hard problems are mostly not in the model — they are in the scaffolding around it. Getting that scaffolding right, loop by loop, is where the practice is growing up.
Text summarized and optimized using Anthropic’s models and reviewed by a human.