Agent Design Patterns: Memory, Context Management & Third-Party Frameworks.

Anthropic draws a hard structural line: a workflow orchestrates LLMs and tools through predefined code paths, while an agent is a system where the model dynamically directs its own process and tool usage. The mechanism that makes an agent an agent is the tool-use loop - the model calls a tool, receives environmental feedback ("ground truth" it did not generate itself), and repeats until the task converges. That loop is costlier and harder to bound than a fixed pipeline precisely because the number of iterations is not known in advance - see the workflow-vs-agent page for the full tier decision (augmented LLM vs. workflow vs. agent) and the five named workflow patterns; this page assumes that decision is already made and focuses on what production agent systems need on top of the raw loop.

Three things typically sit on top of a bare tool-use loop in a production system: sub-agents (isolated-context delegates that keep detailed exploration out of the coordinator's window), memory (persistence that survives outside the context window, since context is finite scratch space, not infinite storage), and explicit context-window management (because signal quality decays as a window fills, not just capacity). Third-party agentic abstraction frameworks - Strands, LangGraph, PydanticAI - wrap this same loop with state management, tool-schema typing, and control-flow helpers, without changing what the loop fundamentally does.

Memory and context-window management break into three named techniques, per Anthropic's effective-context-engineering guidance. Compaction: summarize a conversation approaching its context limit and reinitiate a fresh window from that summary. "The art of compaction lies in the selection of what to keep versus what to discard, as overly aggressive compaction can result in the loss of subtle but critical context" - Claude Code's own implementation "preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages," and the recommended iteration order is maximize recall first, then tighten precision. Best fit: long, continuous back-and-forth sessions. Structured note-taking / agentic memory: the agent regularly writes notes to storage outside the active context window and re-reads them as needed - Anthropic ships a public-beta memory tool on the Claude Developer Platform that does this via a file-based system, with no explicit memory-structure prompting required (Anthropic's Pokémon-playing agent maintains maps of explored regions, tracked achievements, and strategic notes entirely through this pattern). This enables "long-horizon strategies that would be impossible when keeping all the information in the LLM's context window alone." Best fit: milestone-driven, iterative work spanning many sessions. Sub-agent architectures: a coordinator delegates focused exploration to sub-agents with clean context windows; each sub-agent "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)" - achieving "clear separation of concerns" since the detailed search context stays isolated inside the sub-agent and never pollutes the coordinator's window. Best fit: parallel research or investigation where multiple independent angles need deep exploration.

These three techniques are not mutually exclusive tiers - they compose. A long-running coding-assistant session routinely combines all three: sub-agents for isolated deep code search (each returning a condensed summary), structured note-taking to track a multi-step migration's progress across sessions, and compaction only as a fallback when the primary thread nears its window limit. Picking one is a per-workload decision, not a single architectural label for the whole system - the same discipline that governs picking a workflow pattern (start simple, escalate only when the simpler technique demonstrably fails).

Multi-agent orchestration is a platform primitive, not purely a DIY pattern. Claude's Managed Agents platform documents multi-agent sessions where one agent coordinates others acting in parallel with isolated context - the same coordinator/isolated-delegate shape as a hand-rolled sub-agent architecture, but running on Anthropic's hosted infrastructure rather than your own process. Which runtime hosts the coordination changes the mechanics of state and governance (see the Agent SDK vs. Managed Agents page) but not the underlying design pattern.

Third-party frameworks abstract the tool-use-loop plumbing; none of them are Anthropic products, and their attributions matter for the exam. Strands Agents is an open-source SDK originally released by AWS - model-driven and multi-vendor, supporting Bedrock, Anthropic, and OpenAI models. LangGraph is published by LangChain - a low-level orchestration framework/runtime that models agent workflows as graphs, adding durable execution, streaming, and human-in-the-loop control on top of that graph structure. PydanticAI is published by the Pydantic team - a Python-first, type-safe agent framework built directly on Pydantic's schema/validation model, aimed at teams who want strong, structured RUNTIME validation of tool inputs/outputs (Python's dynamic typing means Pydantic checks and coerces data as the program executes, not at a compile step - the type hints give you editor/IDE-level static-analysis benefit, but the actual guarantee on a live tool call is enforced at runtime). All three sit *on top of* model APIs including Claude's; "agentic abstraction framework" means they abstract the loop's plumbing (state, tool schemas, control flow, typing), not that they redefine or replace the loop itself - swapping frameworks does not change whether a system is a workflow or an agent underneath.

Framework selection is a fit-for-purpose question, the same instinct as tool-surface selection. Reach for a graph-structured orchestration layer with built-in durable execution and human-in-the-loop checkpoints when the workflow genuinely needs that structure (LangGraph). Reach for a multi-vendor, model-driven SDK when the deployment must support several model providers behind one interface (Strands). Reach for strict Python typing and validation on tool schemas when correctness-by-construction matters more than orchestration features (PydanticAI). None of these choices is required to build an agent at all - the raw Agent SDK or Client SDK plus a hand-rolled loop remains a fully valid, framework-free path, and is often the simpler one for a single-vendor, Claude-only deployment.