Agent Patterns and Frameworks

The tool-use loop is the pattern underneath the others

Every richer pattern still reduces to the same cycle. The application sends messages and tool definitions. If stop_reason is tool_use, it runs the calls and appends tool results. If stop_reason is end_turn, it stops. Prompt chaining, routing, and an evaluator that checks a draft are workflows or agents wrapped around that cycle, depending on who chooses the next node.

Anthropic's workflow patterns stay relevant here even when you later wrap them in a framework. Chaining is fixed stages. Routing sends the input to a specialist. Parallelisation fans out independent calls. An orchestrator-worker pair is the supervisor from 1.1. An evaluator-optimizer loop drafts, checks, and revises. Use them when they match the dependency. A framework is how you express the graph, not a reason to add a graph.

Subagents and context isolation

A subagent has its own message list. It does not inherit the parent transcript. You pass the goal, the inputs, and any findings it must not rediscover. It returns a final message. The search queries, file bodies, and dead ends stay in the worker. That is context isolation: the parent's window is spent on the decision, not on the search.

Isolation fails in two familiar ways. The prompt is too thin, so the worker repeats work the parent already did, or it answers without the constraint that mattered. Or the parent pastes the worker's entire trace "so nothing is lost," which deletes the benefit. Pass structured findings. If the parent must audit a particular tool call, ask for that call in the return contract instead of merging histories.

Independent subagents run together when the parent emits several delegations in one turn. A worker that needs a sibling's output waits. Nested workers are a depth limit you should set, because a tree of investigators will fill a budget before the supervisor writes the answer.

Memory is not the context window

The Messages API does not remember a session for you. Whatever you resend is the working context. That window holds instructions, the dialogue, and tool results, and it bounds both the conversation and the response. Durable memory is different: a file, a database row, or an agent-memory note that survives the process and is loaded back in later on purpose.

Memory helps when a fact should outlive the chat: the customer's preferred language, a decision already made, a summary of yesterday's investigation. It does not enlarge the window. If you load every note on every turn, you have rebuilt the full transcript under another name. Retrieve the slice that this turn needs. Treat memory writes as a tool with a schema, not as a diary the model appends without a reason.

Managing the window

Tool output is usually what fills the window. A directory listing, a retrieved page, or a test log can dwarf the user message. Keep the raw artifact outside the transcript when you can: store it, and put a short, cited excerpt in the tool result. When the history itself is long, compact the older turns into a structured summary and drop the verbatim middle. Keep the system prompt, the latest user goal, and the unresolved facts.

Subagents are the isolation valve for exploration. Compaction is the valve for a single thread that must continue. Pruning is the valve for one oversized tool result. Using all three at once without a rule produces a summary of a summary and a worker that lacks the source. Pick the valve that matches the object that grew.

Drift looks like contradictions and forgotten constraints near the end of a long run. The remedy is the same hygiene. Raising temperature, repeating the system prompt after every turn, or cutting max_tokens does not remove the stale tool output.

When a framework earns its weight

An agentic framework provides a graph or a state object for multi-step, tool-using work. It standardises three things teams otherwise rewrite: loop control, how state moves between steps, and how the run branches. The model's abilities stay the model's. A framework that "makes the agent smarter" is a distractor.

Adopt one when the orchestration is the maintenance burden: many branches, checkpoints, human interrupts, retries with state, or a graph you need to draw in review. Skip it when the job is one tool in a loop until end_turn. The Agent SDK already runs that loop. A graph library around a single node is overhead, and it is the same mistake as reaching for an agent when a workflow would do.

Strands, LangGraph, and PydanticAI

Strands is a model-driven agent library. You register tools and let the model run the loop, with a small amount of orchestration code. It fits when you want that loop, across model providers, and you do not want to draw every edge. The trade is less explicit control of the graph. Portability is relatively high because the agent is not tied to one vendor's state machine.

LangGraph represents the run as a stateful graph: nodes, edges, and conditional edges, with checkpoints. It fits when you need durable steps, a human interrupt, or a replay of a failed branch. The trade is ceremony and a closer tie to the LangChain ecosystem. You take it for control and auditability, not because the model will score higher.

PydanticAI is a typed Python agent layer. Dependencies and results are Pydantic models, so a bad structure fails in your code and can be retried with the validation error. It fits when the pain is typed outputs and injected services, not a large graph. It is the wrong purchase if you wanted checkpointed branches and bought a validator.

There is no universal winner. Choose on control, portability, and whether the built-in pattern matches the task. You can outgrow a choice. Starting on the heavy framework "to be future-proof" pays the cost now for a graph you may never need.

One tool, and a proposal to adopt LangGraph

The agent calls a product API in a loop until it can answer a stock question. A lead wants LangGraph "so the agent becomes more capable and future-proof." Capability will not change. The graph would contain one node. Keep the tool loop, or the Agent SDK. Revisit a graph when there are real branches, a checkpoint, or a human interrupt worth drawing.

A research parent that contradicts itself

After forty minutes the assistant denies a constraint from the first user message. The trace is mostly full-page fetches. The fix is to move each fetch into a subagent that returns a cited paragraph, and to compact the parent's older turns. A larger window would hold a few more pages and then fail the same way, at a higher cost.

Picking the library for a claims graph

A claims process has a typed decision record, a human interrupt on amounts over a threshold, and the ability to resume after a crash. PydanticAI fits the decision record. LangGraph fits the interrupt and the checkpoint. Using both is reasonable: typed results inside graph nodes. Strands fits a simpler investigator that only needs tools and a loop. The exam wants the matching pattern, not the brand you like.