I’d heard about agentic AI for months but never really looked into it, because it seemed like a way to burn through my token limits expeditiously. Spoiler alert: I wasn’t completely wrong, Anthropic says multi-agent systems used tokens about 15x faster than a single chat thread. After finally seeing the basics of agentic systems in action, at WordCamp US 2026, I decided I needed to learn more, and I found the Claude Certified Architect – Foundations (CCAR-F) exam. I figured I might as well jump in head-first.
It took about a week to complete the CCAR-F Exam Prep Course on Udemy. Every concept was surprisingly intuitive, and there’s almost no code in the course itself — the SDK gets mentioned as something that exists, but building systems with it isn’t covered in depth. There is a lesson on how to build an MCP server with Python, but knowing how to do this isn’t as important for the exam as having a solid understanding of how to use MCP servers. There are still a lot of software engineering concepts mentioned, such as graceful degradation and error handling. The exam is organized into five domains: Agentic Architecture, Tools & MCP, Claude Code, Prompt Engineering, and Context Management.
This is the first post in a five-part series, one per domain. Domain 1, Agentic Architecture, covers what actually makes something an agent instead of a chatbot or a workflow, and the design decisions that keep an agent from going off the rails.
What Is an Agent?
The distinction between a chatbot and an agent is that an agent decides its own flow — which tools to call and in what order — rather than following a fixed script. You can also build a system that uses an LLM inside a workflow without that system being agentic, or a chatbot either. One key to using agentic AI effectively is knowing when not to use it: plenty of tasks still belong to a deterministic workflow. If the process has a predictable sequence, that’s the ideal path, not an agentic system. There’s a tradeoff between predectability and adaptability. There are 5 patterns discussed in the course, which, while not all are inherently agentic, are often used in agentic systems.
- Prompt Chaining is a fixed sequence of LLM calls, feeding the output of one into the input of the next.
- Routing involves an LLM classifying an input and directing it to one of several fixed downstream paths – that could be to LLM, or it could be to a deterministic system
- Parallelization involves either splitting a task into independent subtasks or identical tasks in a voting-type scenario.
- Orchestrator-workers involves a central LLM dynamically breaking down a task and delegating subtasks to worker LLMs and synthesizing the results. This one is explicitly agentic, since the orchestrator is deciding the decomposition and delegation at runtime.
- Evaluator-optimizer involves an LLM generating and a second LLM critiquing and looping until the evaluators criteria passes or the loop budget has been exhausted. This one is pretty close to being agentic, but it’s more of a controlled feedback loop.
Risks and Auditability of Non-Deterministic Workflows
The core risk of putting an LLM into a workflow is that it’s non-deterministic by nature. It can hallucinate or drift from the intended goal, producing output that’s factually fine but not what anyone wanted, if it isn’t engineered carefully. How many safeguards you need depends on how fault-tolerant the overall workflow is — stronger safeguards generally mean faster token burn. There’s also a mechanism for letting agents fail gracefully, or retry conditionally with additional context, rather than just erroring out.
How Does an LLM Become an Agent?
LLMs don’t have file access, tool access, or memory on their own — for that, you need an application layer. Claude Code is one; Pi, Hermes, OpenClaw, and DeepSeek Harness are others. These applications let users connect memory and tools, and write distinct skills and agents that use those skills, all through natural language.
Loops: Know When to Hold or Fold
Agents need to be told when to stop, when to retry, how many times to retry, and when to escalate. Escalating can mean handing off to another agent, a deterministic system, or a person. Without a retry budget, an agent can burn through credits fast.
Task Decomposition
Agents need a tightly defined goal. If the goal is too vague, or there’s more than one goal at once, the context between them gets muddled fast. It’s best to give an agent a one-track mind and split tasks out granularly — sometimes decomposing further, depending on how complex the goal is. A task might need data from one external system or several. If the sub-tasks can run independently, run them in parallel; if one depends on another, chain them. Real workflows often mix both, which ends up looking like a hierarchy. Failures in a sequential chain prevent the rest of the chain from executing, so robust error handling is essential. Sequential workflows are more fragile than parallel workflows, but they are more debuggable and auditable. Parallel execution is faster than sequential (assuming the tasks are independent), but it adds complexity because you need to synchronize the branches and assemble the outputs at the end. If some of the branches fail, there’s additional logic needed to retry or proceed with partial results or aborting the whole process.
Static Vs Dynaic Planning
Some tasks need flexible planning if there’s enough unpredictability. Allowing an agent to shift the plan mid-execution requires constraints to avoid drift as well as a cap on iterations.
Handling Ambiguity
While it’s usually best to avoid ambiguity, sometimes it’s unavoidable for some systems. When that’s the case, the system needs to know how to handle ambiguity when it comes up. High-stakes scenarios require prompting a person for clarification, which adds latency. For some low-stakes scenarios – especially for reversible decisions, it’s acceptable to allow the agent to infer the correct direction and proceed, provided there’s adequate context to make infer the correct decision.
Multi-Agent Orchestration
Multi-agent orchestration allows you to define a central orchestrator agent to coordinate other LLM agents with more tightly scoped roles, which results in higher quality work than a single generalist agent working sequentially in addition to the speed benefits of parallelization. Additionally, since each specialized agent has its own separate context window, this keeps the context window of the orchestrator agent lean, making it easier to stay on course and avoid drift. The downside of this architecture is that it is inherently hub and spoke, with the orchestrator as the single point of failure, or it could be a bottleneck. There’s added complexity with coordination tasks. Failures can be harder to track down. Several safeguards are necessary for robust orchestration. The orchestrator needs to provide detailed, explicit prompts to each subagent, limit the scope of what each agent can do, and be able to recover from subagent errors to avoid corrupting the whole task.
Next up: Domain 2, Tools & MCP.
