Agent Architecture

Agent Architecture is the structural half of building an agent, and it carries 4.5 percent of the CCDV-F blueprint. On a 53-question paper that is close to two scored questions, so treat it as a topic you must be able to reason through rather than one you can memorise your way past.

The sub-skill sits one level above implementation. Nothing here is about which method call drives the loop; everything is about the shape of the system that loop runs inside. Four structural questions recur. Who owns conversation state, your process or a hosted service? Does the work fit one agent with one context window, or does it fan out to workers with their own? Which parts of the flow are decided by the model at run time, and which are fixed in code you can read and test? And where does knowledge that outlives a single context window live?

That last question is where marks are lost, because three different mechanisms address memory and they do genuinely different things. Clearing removes old blocks outright. Summarising replaces them with a condensed record. Externalising writes durable notes the agent can read back later. Choosing between them is an architecture decision rather than a tuning knob, and a well-written scenario contains one detail that eliminates two of the three.

What the exam tests here

• •Which parts of a flow belong in deterministic code and which are safe to leave to model judgement
• •Choosing a single-agent topology over a fan-out of workers, and the briefing cost of each hand-off
• •Where durable state lives when a task outlasts one context window
• •The difference between clearing stale blocks, summarising history, and writing to external memory
• •Which build approaches supply only a harness and which also supply the hosting underneath it
• •Designing the tool surface so that risky steps are inspectable before they run

Draw the deterministic boundary first

An agent architecture is mostly a decision about what the model is **not** allowed to decide. Sequencing that never varies, authorisation checks, schema validation, idempotency keys and rollback paths belong in code, because code can be unit tested and read by a reviewer six months later. Model judgement belongs where the input space is genuinely open.

A useful design habit is to sketch the flow and mark every arrow the model chooses. Each marked arrow is a place where behaviour can change without a deploy, so each one needs either a cheap recovery path or a gate in front of it. Architectures that fail in production usually have too many marked arrows, not too few tools.

Topology: one context window or several

Fan-out is the second structural choice. A single agent holds one continuous window and can refer back to anything it has seen. Delegating to workers gives each branch a fresh window and returns a short report, which is the only reliable way to stop a reading-heavy task from crowding out the work that matters.

The cost is a briefing. A worker starts knowing nothing about what the coordinator learned, so the instruction has to carry the paths, the constraints and the required output shape in full. The break-even is roughly whether a delegated branch reads far more than it reports. A branch that reports nearly everything it read has bought you a round trip and nothing else.

Three memory mechanisms, three different meanings

Long-running agents need a story for content that no longer fits, and the platform exposes three distinct answers.

Context editing clears old tool results or reasoning blocks out of the request before the model sees it, so those tokens simply disappear. Server-side compaction summarises earlier turns and returns a compaction block that you must append back along with the rest of the response content, because that block is what stands in for the history on the next call. A memory tool gives the agent an explicit read and write surface outside the window, so findings survive the session entirely.

Clearing loses detail permanently, summarising loses fidelity, and external memory costs a tool call. Pick by what the task cannot afford to lose.

Harness and hosting are separate axes

Candidates conflate the ways of building an agent because they compare them on one dimension. Two dimensions separate them cleanly: who supplies the harness (the loop and the context handling), and who supplies the deployment (the machine the agent and its tools run on).

Writing the loop yourself supplies neither. An SDK tool runner supplies a harness over tools you define and leaves hosting to you. The Claude Agent SDK also supplies a harness, a fuller one carrying built-in file and shell tools, and still leaves hosting to you. Only the managed agent platform supplies both, provisioning a workspace container per session. Place a scenario on both axes and the intended answer usually falls out.

Where candidates go wrong

Common questions