Home / CCA-F / Agentic Architecture
DWG 01 — 27% OF EXAM

Agentic Architecture

What this domain covers

Defining agentic systems, task decomposition and planning, multi-agent orchestration, and reliability and human oversight — the foundation every other domain builds on.

1.1Foundations

An agentic system is defined by three things working together: autonomy over multiple steps, the ability to call tools that act on the world, and an action loop that lets it observe the result of one action before deciding the next. Take away any one of those and you have something else — a single-shot completion, a fixed pipeline, or a chatbot.

The exam draws a hard line between three patterns: a conversational system responds turn by turn with no independent action loop; a workflow executes a fixed, predetermined sequence of steps regardless of what it finds along the way; an agent decides its own next step based on what the previous step returned.

Reach for agentic architecture only when the task's shape can't be known in advance — variable-length research, open-ended debugging, multi-system orchestration. It costs more in latency, tokens, and predictability than a workflow, so a fixed pipeline is usually the better engineering choice whenever the steps are actually known ahead of time.

Key distinctions
  • Workflow = fixed steps, known in advance, cheap and predictable.
  • Agent = the model decides the next step from the last result — variable path, higher cost, needed only when the task truly requires it.
  • The action loop (act → observe → decide) is what turns a tool-using model into an agent.

Full breakdown & examples → 1.1 Foundations

1.2Task Decomposition and Planning

Before an agent acts, it has to break an ambiguous goal into concrete steps. Good decomposition separates steps that must happen in order from steps that are genuinely independent, so independent work can run in parallel instead of serially burning time and tokens.

Plans should not be treated as fixed once written. Dynamic replanning — revising the plan when a step returns something unexpected — is what separates a resilient agent from one that marches confidently down a plan built on a now-false assumption.

Ambiguity handling is a design decision, not an accident: an agent can ask a clarifying question, pick the most reasonable interpretation and proceed, or spawn parallel exploratory paths. Which is right depends on the cost of being wrong versus the cost of stopping to ask.

Key distinctions
  • Sequential steps have a dependency; parallel steps don't — decomposition should surface which is which.
  • Replanning after new information beats rigidly executing a stale plan.
  • Ambiguity should be resolved deliberately (ask, assume-and-state, or explore), not silently.

Full breakdown & examples → 1.2 Task Decomposition and Planning

1.3Multi-Agent Orchestration

The dominant production pattern is orchestrator–subagent: a lead agent holds the overall goal and coordinates, while subagents each get a narrow, well-scoped task and their own isolated context window. Isolation matters — a subagent that inherits the entire parent transcript wastes tokens and dilutes its own focus.

Three topologies come up repeatedly: hub-and-spoke (one coordinator, many independent subagents reporting back — the most common and easiest to reason about), pipeline (each agent's output is the next agent's input, good for staged transformations), and peer-to-peer (agents communicate directly with each other — powerful but much harder to keep predictable and to debug).

Handoff design is where most orchestration bugs live: what exactly does a subagent return to the coordinator, in what format, and how much of it survives versus gets discarded? A subagent that returns a wall of raw output instead of a condensed, structured summary defeats the purpose of isolating it in the first place.

Key distinctions
  • Hub-and-spoke: simplest to reason about, coordinator owns all state.
  • Pipeline: staged, each stage transforms the last stage's output.
  • Peer-to-peer: most flexible, least predictable — use sparingly.
  • Subagents should return condensed, structured summaries, not their full raw context.

Full breakdown & examples → 1.3 Multi-Agent Orchestration

1.4Reliability and Human Oversight

Agentic systems fail in characteristic ways: looping on a task that can't succeed, taking an action based on a hallucinated premise, or silently treating a failed step as if it had succeeded. Mitigation is layered — timeouts and step limits catch the first, grounding and verification steps catch the second, and explicit success criteria catch the third.

Checkpoints pause the agent before high-consequence or irreversible actions (sending an email, deleting data, committing a purchase) and require explicit approval before continuing. Where to place a checkpoint is an architectural decision that trades safety against friction — too many and the agent is barely autonomous; too few and a bad decision compounds before a human ever sees it.

Monitoring an agentic system means more than logging final output: it means capturing the intermediate steps, tool calls, and decisions so a failure can be diagnosed after the fact, and building evaluation sets that catch regressions before they reach production.

Key distinctions
  • Failure modes: infinite/unproductive looping, hallucinated premises, silent failure treated as success.
  • Checkpoints belong before irreversible or high-stakes actions — not sprinkled evenly through a task.
  • Guardrails include step/tool-call limits, explicit success criteria, and grounding steps.

Full breakdown & examples → 1.4 Reliability and Human Oversight


Check yourself
1.A support agent needs to look up an order, check a refund policy, and issue a refund up to $50 without asking, but must pause for approval above $50. What kind of design decision is this?
Show answer
A checkpoint placed at a specific threshold — it trades autonomy for oversight exactly where the consequence of a wrong decision (an unauthorized large refund) becomes serious enough to warrant it.
2.You're building a system to fetch three independent web pages and summarize each. Should this be a workflow or an agent?
Show answer
A workflow. The steps are known in advance and don't depend on each other's results — running an agent to decide something already fixed adds cost and unpredictability without benefit.
3.A subagent researching "competitor pricing" returns its entire 40-tool-call transcript to the coordinator instead of a summary. What orchestration principle does this violate?
Show answer
Context isolation / condensed handoff. Subagents should return a distilled, structured result to the coordinator — returning the full raw context defeats the purpose of isolating the subagent's work in the first place.

Claude Certified Architect — Study NotesDWG 01