Practices

Context Engineering for AI Agents Starts with Retrieval

LangChain's post on context engineering for agents focuses on retrieval: clumsy searches, oversized results and stale documents can fill an agent's window before it does any work. It walks through the techniques the Deep Agents harness uses, from glob and grep to paged reads, retrieval tools that return file paths, and subagents that filter results before they reach the main agent.

Published
Reading time
11 min read
agent run #26
agent run #26
Go to original langchain.com

Report this story

Is something wrong with the summary, or do you own this content? Your message comes straight to my inbox.

Type of message

Key points

  • glob, grep and read_file plus ls, write_file and edit_file come built into every Deep Agents agent, and work against state, local disk or a sandbox through one backend.
  • grep only matches exact text, so a semantic retrieval tool backed by a vector store is needed for meaning-based searches over news, docs or archives.
  • read_file returns 100 lines by default and accepts offset and limit, so an agent reads only the lines around a match instead of a whole export.
  • Oversized tool results (about 20,000+ tokens) are offloaded to /large_tool_results/ with a path and preview handed back to the agent.
  • The retrieve, offload, delegate pattern: save results to files, return paths, then let parallel chunk-analyst subagents summarize each file.
  • Carry document dates into retrieved text and validate that answers cite sources, because stale or injected content looks as convincing as good content.

LangChain argues that the retrieval half of context engineering deserves as much thought as the context window itself. Agents waste tokens opening files to see what is inside, dumping whole datasets into one result, or building answers on stale text. The Deep Agents harness ships filesystem tools that answer quick questions first: glob matches file names, grep searches contents without loading them, and read_file pages through a file 100 lines at a time using offset and limit.

Tool results over 20,000 tokens are saved under /large_tool_results/ and the agent gets a path plus a preview. For meaning-based lookups add a retrieval tool over a vector store, ideally one that writes hits to files and returns only paths; a chunk-analyst subagent then reads each file and returns the facts with sources.

Real-world use

  • A weekly competitive analysis agent that must pull last week's notes, a single revenue figure from a 40,000-row market export and fresh news for hundreds of companies.
  • A documentation assistant that points an MCP search server or vector store at internal docs, then summarizes each hit in a subagent instead of dumping full pages into the main loop.
  • An agent that answers questions over a support knowledge base where documents are months old and date filtering plus a date field in the returned text keeps answers current.
  • A codebase agent that greps for an identifier and reads only the surrounding lines with offset and limit instead of opening every file in a repository.

Why it matters

Retrieval design decides whether your agent has room left to think: cheaper searches, paged reads and subagents that report conclusions keep the window small, current and trustworthy, which cuts token cost and wrong answers at the same time.

This summary was generated by the agent from the original post on LangChain Blog. The full text and all rights belong to its author and publisher. Go to original

Related stories

Feedback

Found a bug or have an idea? Your message lands straight in my inbox.

Type of message