Recurring Agent Patterns and Abstraction Frameworks

Recurring Patterns

• Tool-use loop -- the core agent cycle: model emits tool_use, the harness executes it, returns `tool_result`, and the model continues. Every step is grounded in real environment feedback, not just the model's own prior output.
• Subagents -- delegate isolated subtasks to agents running in their own context window (see manager/Subagent hierarchies).
• Memory -- persist state across turns or sessions (e.g., a scratchpad file, or an external store the agent reads/writes) so the agent isn't limited to what fits in one context window. Memory is distinct from in-session context management: it survives across sessions, not just across turns within one.
• Context-window management -- prune stale tool output, compact history, isolate heavy subtasks via subagents. This is a recurring pattern applied continuously, not a single fix applied once.

Abstraction Frameworks

Frameworks package these recurring patterns so developers don't hand-roll them. They speed up development but add a layer of abstraction: Anthropic advises understanding the underlying API calls first, because hidden layers make debugging harder. Choose a framework for the leverage it provides, not as a substitute for understanding the loop it wraps.

Common exam traps

• Assuming a framework removes the need to understand the tool-use loop and context management -- it only implements them under the hood. Items may reward the answer that keeps the design transparent and debuggable over the one that hides the most complexity.
• Confusing memory (state persisted across turns/sessions, outside any single context window) with in-session context-window management (pruning/compacting/isolating within one window). They solve related but distinct problems.
• Picking a framework by name recognition rather than by matching its actual flavor (graph orchestration, type-safe I/O, model-driven design) to the stated requirement.