Agent Patterns and Frameworks

Agent Patterns and Frameworks carries 4.9 percent of the blueprint, landing between two and three questions on a 53-item paper. The framing that matters is that these patterns are vocabulary, not code. You will not be asked to implement one. You will be handed a paragraph describing a system somebody built and asked which pattern it is, or which pattern would fix the problem described.

That makes the discriminations far more valuable than the definitions. Two patterns split work across concurrent calls, and what separates them is whether the split was decided in advance or by a model at run time. Two patterns iterate towards quality, and what separates them is whether the verdict comes from a rubric or from something executable. Two patterns branch, and what separates them is whether the branch is a classification or a validation gate. Candidates who memorise five names in isolation get the easy question and lose the discriminating ones.

The frameworks half is a judgement question with a consistent shape. Something has to supply the loop, the retries, the state and the observability. The exam asks what you surrender when a library supplies them, and whether this particular scenario can afford that trade.

What the exam tests here

• •Reading a described system and naming the pattern behind its control flow
• •Separating parallel work split in advance from work a model decomposes at run time
• •Recognising when a critique loop has a usable success signal and when it will simply spin
• •Composing patterns, including nesting one inside a single step of another
• •What a framework abstracts away, and which of those abstractions you need visibility into when debugging
• •Matching the smallest amount of supplied machinery to what the scenario is actually missing

Fixed decomposition versus decomposition at run time

Splitting a job across concurrent calls looks identical from outside whether a developer or a model decided the split, and that is precisely the discrimination being tested.

If the subtasks are known before the request arrives (translating a document into four fixed languages, screening one input against six named policies), the decomposition lives in your code and the pattern is parallelization. If the number and shape of the subtasks depend on the input (a coordinating model reading a change request and working out which files need editing), the decomposition is dynamic and the pattern is orchestrator-workers.

The tell is usually visible in the scenario: a loop over a fixed list points one way, a model deciding what the pieces are points the other.

Voting and sectioning solve different problems

Inside parallelization sit two variants that share their mechanics and nothing else.

Sectioning divides a task into non-overlapping pieces and combines the answers, because each piece needs separate attention and the whole is the sum of them. Voting runs the same task repeatedly, often with differently worded prompts, and aggregates by agreement, because one sample is not trustworthy enough on its own.

Sectioning buys focus and wall-clock speed. Voting buys confidence and costs a multiple of the tokens for a single answer. Reviewing code against several distinct classes of defect is sectioning. Deciding whether content is harmful, where a false negative is expensive, is voting.

Critique loops need a signal that can actually fail

Pairing a generator with a critic that grades output and requests revisions is powerful inside a narrow band and wasteful outside it. Two preconditions decide which side you are on.

The criteria must be specific enough that the critic returns different verdicts on a good and a bad draft, and revision must genuinely improve the artefact, which holds for prose, translation and code and much less for a factual lookup. When the criteria collapse into a vague quality judgement, the critic approves nearly everything and the loop becomes an expensive pass-through.

The strongest version replaces the critic with something executable (tests, a compiler, a schema validator) so the verdict comes from a fact rather than another generation.

What a framework takes over, and what it hides

Any agent needs a loop, retry handling, state, tracing and a tool interface. A framework supplies all of them and prices that in visibility. The layer it abstracts is exactly the layer you need when behaviour is wrong: the bytes actually sent, the assembled prompt, the tool descriptions the model really saw, the point at which a retry re-sent something.

There is a middle position easy to miss on an exam paper. A tool runner in the official SDK supplies the loop without concealing the request, and still exposes per-turn interception. Reach for that when the loop is all you were missing, and keep a full framework for when you need the ecosystem around it too.

Where candidates go wrong

Common questions