Domain 1: Agentic architecture and orchestration

Hand an agent a long task and sometimes it comes back early, cheerful, with half the work done. Hand another the same kind of job and it never comes back at all. The first instinct is to rewrite the prompt, or give the agent more room to run. On the CCAR-F, the wrong answers are built to catch both instincts.

Agentic Architecture & Orchestration is the heaviest domain on the exam, at 27%, or about 16 questions. It is also the domain the other four keep borrowing from. Configuration questions in Domain 3, review questions in Domain 4 and failure questions in Domain 5 all assume you have this one straight, so time spent here pays more than once.

It comes back to one field

An agent is a loop. You send a request with the conversation so far, read what comes back, run whatever tools it asked for, add the results to the conversation, and send again. The decision to go round once more is made by a single field on the response, stop_reason. Nothing the model says in its text decides it.

Picture a travel assistant built on Claude. In one reply it writes "Great, I've found you a flight" and, in the same response, asks to call the seat-selection tool. A loop that scans the text for signs of being finished stops there, and the traveller gets a flight with no seat. A loop that reads the field carries on. A question may phrase this as a complaint from a user, and the job is to work out which signal the loop was trusting.

The tempting fix is a higher iteration cap. A cap is a safety net for an agent that runs away. It does not decide when the work is done. Raise it and the early stops are still there, with a bigger budget behind them.

Hold on to the loop and the rest of the domain gets easier to place, because nearly everything else either runs more of these loops at once or puts limits on one.

More loops: who talks to whom

Multi-agent orchestration (1.2) starts with a choice of arrangement. There are a handful of standard ones, and reciting them earns nothing. The task is to look at a workload and see what depends on what. If one step needs another's output, they can't run side by side. If they share nothing, making them wait for each other buys only latency. And when nobody can map the path in advance, the model has to choose the next step itself.

The arrangement to know best is a coordinator with specialists around it, and it has one rule that is easy to forget. The specialists never talk to each other. Imagine a due-diligence system where one subagent reads the contracts and another reads the accounts. The contracts agent finds a pending lawsuit that changes how the accounts should be read. The accounts agent will never hear about it unless the coordinator passes it on. When a system like that produces a thin result, look at the coordinator first, even if every specialist did exactly what it was asked.

Subagent context (1.3) is the same fact from the other side. A subagent starts with an empty context window. It has not seen the coordinator's conversation or its siblings' findings, and no amount of good prompting changes that. Anything it relies on must be handed over, in a shape that keeps its metadata attached. If a finding loses its source on the way up, nothing downstream can cite it.

Task decomposition (1.6) covers what happens when a model spreads its attention across too many things. Ask a model to summarise every chapter of a long manual in a single request and the early chapters get a careful page each while the later ones get a line. The model has spread one budget of attention across too many things. Splitting the job into one pass per item, plus one pass that looks across them all, is the structural answer. A bigger context window is the tempting option here, and it does not fix how attention was spread.

Fewer surprises: putting limits on the loop

Say an agent merges pull requests, and it has been told to run the tests first. It does, nearly every time, and the question is whether that is enough.

Workflow enforcement (1.4) is built around that gap, and the answer depends on whether the time it skips the tests is a failure you can live with. If a skipped step costs money, breaks a regulation or can't be undone, no wording of the instruction is ever enough. A prompt makes a step likely and code makes it certain. The module also covers what happens after the code says no: handing the case to a person, and the particular shape that handover has to take, since the person picking it up gets no transcript.

The code that does the enforcing is Agent SDK hooks (1.5). Hooks run at fixed points around a tool call and around a subagent being spawned, and they run whatever the model decides. Anything that has to stop an action runs before it. Anything that tidies up or records a result runs after. Both hooks are real, both appear in the options, and putting the right one on the wrong side of the call drops the mark.

Then there is Session state (1.7), the quiet one. Claude Code can resume a session, fork it, or start fresh, and the difference is what each carries forward. Suppose a teammate merged a large refactor on Friday and on Monday you resume Thursday's session. Its history still holds what the files said on Thursday, and those old readings keep leaking into the advice even after you point it at the new code. The module is about noticing when history has gone stale, and deciding what to bring into a fresh session instead.

Where marks go

• Trusting the model's words over the response's field, or treating a higher cap as a fix.
• Blaming the agent that produced thin work, when the gap was in what it was handed or how the work was split.
• Choosing the right hook for the job and putting it on the wrong side of the call.
• Reaching for a bigger budget when attention ran thin or a session went stale. Claude Certified Architect wrong-answer patterns covers why the capacity fix keeps turning up.

These mistakes come from failing to recognise which situation you are in, under time pressure, when two options both sound like something a sensible engineer would do. You get good at that by being asked, getting it wrong, and being asked again a few days later.

What you won't find here

Each of the seven modules has its mechanism drawn out, the rules that separate it from the look-alike answers, and the traps the exam builds around it. This post does not say which workload each arrangement fits, does not give the shape of the handover, and does not list the full set of hooks. Spaced teaches every module in full, then brings each idea back at gaps that widen as it sticks, capped so nothing returns after the exam, and files every miss under the principle behind it, so you can see which corner of the domain is still shaky.

Domain 1 is free in full on Spaced. If you want to know whether the method suits you, this is a good domain to try it on, because the rest of the exam leans on it.