Appendix B — A Field Guide to the Frameworks
Chapter 19 taught the durable half of choosing a framework: the six services any harness must supply, the two axes along which the market’s noisy variety resolves, the disciplines that keep the exit lit, and the five questions to ask before a single candidate is let into the room. This appendix is the perishable other half — the snapshot of who currently occupies which position — written in the cheerful certainty that it is the part of the book most likely to be wrong by the time you read it. The preface set the odds honestly: the half-life of an agent framework falls somewhere between a mayfly’s and a supermarket prawn sandwich’s, and in the months this book was assembled one laboratory renamed its agent SDK, another shipped a 1.0, a third folded two flagship frameworks into one, and a fourth put its toolkit through a major version — every one of which is dated below. We apologise in advance to whichever entry has since had the poor manners to change, and offer the only defence available to a field guide in a field that will not hold still: read it as a worked example of the decomposition, not as a set of names to memorise.
That is the instruction which makes the appendix age gracefully, and it is Chapter 19’s: do not learn the frameworks, learn to read a framework, and let each new arrival place itself. Every entry below is therefore filed under its position on Section 19.3’s two axes and decomposed onto Section 19.1’s six services — the same grid laid over each candidate, so that the grid, and not the candidates, is what the reader carries away. The idioms are sketched, not taught; the runnable versions — the running coding team of Chapter 20 built three ways and scored on Chapter 19’s four columns — live in the companion repository’s frontier layer (Appendix C), which carries the burden of currency so the prose need not. Verify each tool against its own documentation before you depend on it, because the one claim this appendix can make with total confidence is that some of its claims have already expired.
B.1 Reading a Framework
To read a framework is to answer, of it, the two questions Chapter 19 made load-bearing, and then to fill in a short table. The first question is who holds the loop? — your code calling the framework’s parts, which is a library, or the framework calling your code in the slots it exposes, which is a framework in the strict sense. The second is asked six times over, once per service: for the loop, for typed state and persistence, for context assembly, for tool dispatch, for topology and messaging, and for observability — is this decision mine, or has it been made for me? Two coordinates fall out of the answers: how far the candidate sits from declaration toward construction, and how opinionated it is about the services it owns. Place it on both, itemise its six services, and you have read it — in about the five minutes Section 19.3 promised, and without watching a single demonstration.
The cleanest worked example is a family rather than a product, because a mature stack decomposes into strata that map almost line for line onto the six services. The LangChain ecosystem1 separates into four, separately adoptable and jointly marketed: LangChain itself, the component layer — model wrappers, tool bindings, retrievers, the single-agent chains of Part II and Chapter 6; LangGraph, the orchestration layer — the loop, the typed state, the topology, which is why the book teaches on it2; LangMem, the memory layer — extraction, consolidation, and retrieval, Chapter 7 sold as a component3; and LangSmith, the observability-and-evaluation layer — traces, token accounts, and Chapter 24’s evaluations delivered as a service4. The details are one company’s product history; the lesson is structural, and worth restating with the names attached — you may adopt the orchestration layer without its sibling memory layer, and every other mature stack, whatever its badging, converges on the same decomposition, because the anatomy demands it and not because the vendors are short of imagination.
| Layer | Role | Provides | Where the book teaches it |
|---|---|---|---|
| LangChain | Component library | Model wrappers, tool bindings, retrievers, single-agent chains | Part II; Chapter 6 |
| LangGraph | Orchestration | The loop, typed state, topology | Chapter 20, Chapter 21 |
| LangMem | Memory | Extraction, consolidation, retrieval | Chapter 7 |
| LangSmith | Observability & evaluation | Traces, token accounts, evaluations delivered as a service | Chapter 24 |
B.2 The Field Guide
The entries are grouped by position on the abstraction axis — graph runtimes in the middle, vendor SDKs toward the library end, declarative crews at the declarative end — because the axis, not the alphabet, is the useful order. Each is a type specimen: the clearest current occupant of its position, not an endorsement, and a newcomer that reads onto the same grid belongs in the same paragraph.
B.2.1 Graph Runtimes
LangGraph is the book’s own vehicle and the type specimen of the graph runtime.5 You declare a StateGraph — a typed state schema, nodes that are plain functions, edges (some conditional) that route between them — and compile it with a checkpointer; the framework then holds the loop, but the graph it runs is the one you drew, node for node. Its opinions are few and its control surface wide: reducers decide how concurrent writes to the shared state merge (Chapter 11’s lost update, made a declaration), a checkpointer makes a crashed run resume rather than restart (Chapter 20’s journal, as API), and an interrupt turns the human gate into a first-class pause. It sits mid-axis and low on opinionation, which is precisely why it reads so cleanly onto the classical concepts — Chapter 20’s from-scratch runtime is recognisably the same object with the graph drawn by hand.
Google’s Agent Development Kit (ADK) is a code-first Python toolkit that reached a graph-workflow 2.0 in 2026,6 occupying much the same middle ground as LangGraph with a Gemini-shaped accent and a heavier deployment story — a command-line tool that scaffolds, evaluates, and ships to Google’s cloud. Its workflow runtime offers the graph-runtime primitives the position implies (routing, fan-out and fan-in, loops, retries, human-in-the-loop) and a task API for structured agent-to-agent delegation. Read it as LangGraph’s neighbour on the axes, with the vendor’s gravity pulling toward one model family and one cloud — which is exactly the sort of opinion Section 19.5’s fifth question, the price of exit, exists to make you notice before you commit.
B.2.2 Vendor Agent SDKs
The Claude Agent SDK is Anthropic’s harness for its own models, and the book’s specimen of the low-abstraction, high-opinion quadrant Section 19.3 flagged as arguably the most valuable on the map.7 You hand a prompt and an options object to a query and receive an asynchronous stream of messages; you may own the loop, but the SDK carries a laboratory’s hard-won opinions about how its models are best harnessed — context assembly, tool-result handling, retry behaviour, sub-agent budgets — on the sound principle that opinions about a model’s harness are best bought from whoever trained the model. One dated idiosyncrasy earns the warning the companion repo learned the expensive way: the Python package drives the claude command-line tool as its runtime, so it inherits that tool’s local settings, hooks, and plugins unless explicitly told to ignore them, and it is the slowest of the frameworks the lab scored — by the margin of a subprocess.
The OpenAI Agents SDK sits at the same low-abstraction end with a small, sharp vocabulary.8 An Agent carries instructions and tools; a Runner executes it; handoffs pass control from one agent to another; guardrails validate what goes in and comes out; and sessions carry state across turns. Its hand-off primitive is the cleanest expression in any current SDK of Chapter 21’s delegation-with-relinquishment — the baton passed, state and responsibility with it — and its guardrails are Chapter 9’s validation relocated to the framework boundary. As with the Claude SDK, what you are buying is a vendor’s considered view of how its own models want to be driven, which is a good thing to buy and a bad thing to buy unknowingly.
B.2.3 Declarative Crews
CrewAI is the type specimen of the declarative crew, and the sharpest illustration in the field of Section 19.5’s headline about the lines-of-code column.9 You declare Agents by role, goal, and backstory, declare Tasks by description and expected output, assemble them into a Crew, and call kickoff; the framework decides the rest — who speaks when, what each sees, when the work is done. In the companion repo’s four-column lab it wins the lines-of-code column at a canter, a dozen lines against the graph runtime’s ninety, and the victory measures precisely the decisions it made on your behalf without asking. It reaches a running demonstration in an afternoon; whether it reaches your production requirements depends entirely on whether its hidden decisions happen to be the ones you would have made — and Chapter 16’s three-clause role test applies to every crew on the market with full force, because declaring an agent the Reviewer changes its prompt and nothing else until you wire the jurisdiction the title implies.
The Microsoft Agent Framework is the merger the preface alluded to, now consummated: AutoGen’s conversational multi-agent lineage and Semantic Kernel’s enterprise plumbing folded into one SDK that shipped a 1.0 in 2026.10 It spans more of the abstraction axis than a pure crew — AutoGen’s ChatAgent abstractions at the declarative end, graph-based workflows for explicit orchestration in the middle — and carries the enterprise services a lean crew omits: session state, middleware, telemetry, identity. Its very existence is a data point for Section 19.4. Two flagship frameworks a reader might reasonably have adopted in 2024 are now one, their separate idioms deprecated in favour of a third; the migration guides are the churn tax of Section 19.4, itemised and dated, and a standing argument for the thin adapter that lets a merger upstream be a small edit downstream rather than a rewrite.
B.3 The Interop Layer
Between the frameworks, and increasingly beneath them, run the protocols — not frameworks but the seams that frameworks plug into, and the subject Chapter 22 treats in full. Three altitudes, three current standards, and a framework’s support for them is worth reading as carefully as its idioms, because it is what decides whether the exit Section 19.4 prices leads anywhere. At the model interface — how a harness calls a model, hands it tools, and carries state — the market is settling on an Open Responses shape.11 At the tool interface — how a harness reaches capabilities — the Model Context Protocol has become the common tongue12: a server advertises its tools, resources, and prompts in one format, and a client of any framework may discover and invoke them, which is the ecosystem inversion Chapter 22 describes. And at the agent interface — how agents address one another as peers — the Agent2Agent protocol publishes an Agent Card at a well-known address and delegates typed tasks with an explicit lifecycle13. The frameworks above are increasingly clients of these three; the protocols, unlike the frameworks, are converging rather than multiplying, which is the one direction of travel in this appendix a reader may cautiously extrapolate.
B.4 A Dated Comparison
The table gathers the placements into a single view, version-dated in the only way honest about its own decay. Its columns are Chapter 19’s and will not move: the design-space position, who holds the loop, the service each is mainly bought for, and the version this book last checked. Its rows are the ones that spoil.
| Framework | Position | Loop held by | Bought mainly for | As of July 2026 |
|---|---|---|---|---|
| LangGraph | graph runtime | framework (you draw the graph) | loop, state, topology | 1.2.7 (tested) |
| Google ADK | graph runtime | framework | orchestration + deployment | 2.x |
| Claude Agent SDK | vendor SDK | you (intensely opinionated) | a Claude-tuned harness | 0.2.110 (tested) |
| OpenAI Agents SDK | vendor SDK | you (opinionated) | hand-offs, guardrails | 0.x |
| CrewAI | declarative crew | framework | fast declarative assembly | 1.15.1 (tested) |
| Microsoft Agent Framework | crew → workflow | framework | enterprise + AutoGen lineage | 1.0 |
Two cautions close the guide. First, the numbers are not the deliverable — Section 19.5’s method is: re-run its lab against whatever the market looks like on the day it matters, score the four columns yourself, and trust the failure-behaviour column over anything printed here or advertised anywhere, since it is the one no feature matrix publishes. Second, remember the appendix’s own place in the argument. Chapter 19 keeps the half of framework-choosing that does not expire, and this appendix keeps the half that does, cheerfully and by design — so that when the mayfly’s successor arrives, renamed and rearchitected and confident it is the permanent one, you will already know which of these paragraphs to cross out, and which grid to read it onto instead.
https://github.com/langchain-ai/langgraph; version 1.x as of press.↩︎
https://github.com/langchain-ai/langmem; young (2025) and the stratum most likely to move or be absorbed.↩︎
https://github.com/langchain-ai/langgraph; version 1.2 at press.↩︎
https://github.com/google/adk-python; ADK 2.x, general availability mid-2026.↩︎
https://github.com/anthropics/claude-agent-sdk-python; version 0.2 at press.↩︎
https://github.com/openai/openai-agents-python; version 0.x at press.↩︎
https://github.com/crewAIInc/crewAI; version 1.15 at press.↩︎
https://learn.microsoft.com/agent-framework/; Agent Framework 1.0 (April 2026), the declared successor to both AutoGen and Semantic Kernel.↩︎
https://modelcontextprotocol.io; the
mcpPython package, 1.x at press.↩︎https://a2a-protocol.org; stewarded, with MCP, by the Linux Foundation’s Agentic AI Foundation.↩︎