Agent patterns and frameworks

What you’ll be able to do

Select an agent framework on criteria rather than popularity
Name the tradeoffs LangGraph, PydanticAI, and Strands represent
Weigh team familiarity as a legitimate factor
Recognise framework questions as selection, not loyalty, questions

What you need to know

These appear as selection questions, never loyalty questions

LangGraph, PydanticAI, and Strands show up by name on the blueprint. No question asks which is best, because there isn't an answer. Every question asks which fits a described situation.

Answers that pick on popularity, recency, or star count are wrong by construction — and they're always on offer, because they're what people actually say in real arguments.

The four criteria that decide it

State management needs — does the workflow need explicit, inspectable state across many steps, or is it mostly stateless calls?
Control granularity — how much of the loop do you need to reach into and override?
Ecosystem fit — does it sit naturally with what's already in the stack?
Team familiarity — a legitimate engineering factor, not a soft one. A framework nobody knows has a real ramp cost and a real incident-response cost.

What each one represents

Loosely, and enough for the exam's purposes:

LangGraph — graph-based orchestration with explicit state. Fits when the flow has branches, cycles, and state worth inspecting between steps.
PydanticAI — typed, schema-first, validation-centric. Fits a team already invested in typed Python and strict output contracts.
Strands — lighter-weight agent construction. Fits when the SDK's own loop is close to what you want.

Don't over-memorise feature lists. The exam tests whether you reason from the described need to a fit, not whether you can recite a comparison table.

A worked selection

ScenarioA team is building a multi-step research agent. They need structured, inspectable state across steps, they're already using a graph-based orchestration style elsewhere in their platform, and two of four engineers have shipped with it before.

Three of the four criteria point the same direction: state needs, ecosystem fit, and team familiarity all favour the graph-based option. Notice the reasoning never mentions which framework is most popular or most recently released — and an answer that did would be wrong even if it named the same framework.

Key concept

Framework choice is decided by state management needs, control granularity, ecosystem fit, and team familiarity. Popularity and recency are distractors the exam includes deliberately.

Practice scenario

ScenarioA senior engineer argues for the framework with the most GitHub stars. Another argues for writing a custom loop because "frameworks are bloat."

Work it through, then open this

Neither argument engages the criteria. Stars measure popularity, and “frameworks are bloat” is a preference, not a requirement — a custom loop is a real maintenance commitment that needs its own justification. Score both against state management needs, control granularity, ecosystem fit, and team familiarity, and let that decide.

Build exercise — Choose a framework on paper, not by reputation

Beginner · 20 min

What you’ll learn

Turning a vague preference into explicit selection criteria
Why team familiarity is an engineering factor, not a soft one

Write down a real agent you’d build. Score it 1–5 on each criterion: how much explicit state it needs, how much of the loop you need to override, how well each option fits your current stack, and how many of your engineers have shipped with it.
- Why: These four are the criteria the exam tests. Scoring forces you to separate them instead of collapsing into a gut call.
- You should see: A grid where one option leads on three of four — or an honest tie, which is itself informative.
Now write one sentence justifying your pick without naming popularity, recency, or GitHub stars.
- Why: If you can’t, your reasoning was reputation dressed as analysis — which is exactly the wrong answer the exam plants.
- You should see: A sentence that references state, control, fit or familiarity, and nothing else.
Write the counter-case: what would have to be true about this project for a different option to win?
- Why: Selection criteria only mean something if you can say what would flip them.
- You should see: A concrete condition — ‘if we needed to override the loop mid-step’ — not a vague ‘if requirements changed’.

Exam traps

Choosing on popularity, stars, or recency

These are wrong by construction. The exam tests selection criteria, not brand preference.

Dismissing team familiarity as a soft factor

It carries real ramp and incident-response cost and is a legitimate engineering criterion.

Defaulting to a custom implementation to avoid choosing

That is also a choice, with its own maintenance burden, and it needs the same justification as any framework.