Advanced Patterns

Once the fundamentals hold, a handful of patterns push agents further — reflection, tool retrieval at scale, subagents, and code-execution. Each is powerful and each has a cost. The advanced skill isn't knowing they exist; it's knowing the specific situation each earns its keep, and measuring that it did.

Reflection / self-critique — quality for steps

Reflection adds a step where the agent critiques its own draft before finalizing: "Does this answer the question? Is every claim supported? What's missing?" then revises. On tasks with quality that's hard to get right in one pass — complex reasoning, code, structured outputs — reflection measurably lifts quality. On a set of code-generation tasks, a single reflection pass raised correctness from roughly 68% to 82%. But it isn't free: it's at least one extra model call (often more), so it adds latency and cost to every task, including the ones that were already right. The discipline: apply reflection where a measured quality lift justifies the extra step, not reflexively. On simple tasks it's pure overhead — and over-reflection can even talk a correct answer into a wrong "improvement."

Tool retrieval — when the agent has too many tools

Everything in Chapter 2 assumed a handful of tools. Real systems can have hundreds, and you can't put 200 tool definitions in every prompt — it bloats context, slows the model, and degrades selection (more choices, more confusion). The fix mirrors RAG: keep tools in a store and retrieve the relevant few for each query, exposing only those to the model. An agent that selects poorly among 60 always-loaded tools often selects well among the 5 retrieved for the specific task — same model, smaller, sharper menu. Tool retrieval is how agent engineering and search engineering converge.

Subagents as a tool

A clean way to manage complexity: expose an entire agent as a tool to another agent. The parent calls research_agent(query) like any tool; the child runs its own loop with its own tools and clean context and returns a result. This is orchestrator–worker (Ch. 6) framed as composition, and it inherits both the benefit (isolation, focus) and the cost (token multiplication). Used judiciously it keeps each agent's context small and its job legible; used everywhere it's an expensive tangle.

Code execution — the highest-leverage tool

Giving an agent a sandboxed code interpreter is often worth more than a dozen bespoke tools: instead of you predicting every operation and building a tool for it, the agent writes and runs code to do arbitrary computation, data manipulation, and analysis. It turns "I need a tool for that" into "the agent writes it." The cost is real: a code-execution tool is a serious security boundary (arbitrary code!) that must be sandboxed, resource-limited, and network-restricted. It's the pattern behind data-analysis and coding agents — enormous capability, gated behind serious isolation.

Starter code

# Per task: (correct_without, correct_with_reflection, base_steps)
TASKS = [(True,True,3),(False,True,3),(True,True,2),(False,True,4),
         (True,True,3),(False,False,4),(True,True,2),(True,True,3)]

def score(reflect):
    correct = sum((cw if reflect else c0) for c0,cw,_ in TASKS)/len(TASKS)
    steps   = sum(s + (1 if reflect else 0) for _,_,s in TASKS)/len(TASKS)
    return correct, steps

# TODO: print both configs; compute how many tasks reflection fixed and the
# extra steps spent across ALL tasks to fix them.

c0,s0 = score(False); c1,s1 = score(True)
fixed = sum((not a) and b for a,b,_ in TASKS)
print(f"no-reflect {c0:.0%} @ {s0:.1f} steps")
print(f"reflect    {c1:.0%} @ {s1:.1f} steps  (+1 step on ALL {len(TASKS)} tasks, fixed {fixed})")
# => no-reflect 62% @ 3.0 steps
#    reflect    88% @ 4.0 steps  (+1 step on ALL 8 tasks, fixed 3)