Agentic Search for Context Engineering – Leonie Monigatti

This post is an edited long-form version of the workshop titled “Agentic Search for Context Engineering” I gave at AI Engineer Europe 2026 on April 8, 2026 in London. The slides, code, and diagrams are available in the workshop repository. If you prefer video, the full recording is available on YouTube:

If you’ve built an agent before, you know that context engineering is a cruical part of making an agent return meaningful responses.

Context engineering is the process of deciding what from all possible context sources actually goes into the agent’s context window so the LLM can generate the best response. This is also referred to as the process of “context curation”, which is depicted as the arrow from the possible context sources to the context window in the diagram below.

Context engineering is mostly agentic search: context sources, search tools, and the context window

I think we don’t give this context curation arrow enough credit because it does almost all of the heavy lifting. What hides behind it is a set of search tools the agent can decide to use. That’s why my personal hot take is that:

Context engineering is about 80% agentic search.

History

Let’s take a step back and look at how search in the AI stack has evolved from Retrieval-Augmented Generated (RAG), to agentic search/agentic RAG, and now to context engineering in the last three years. (If you’re interested I’ve also written about the evolution from RAG to agent memory.)

Retrieval-Augmented Generation

When we first started building with LLMs in 2024, we started implementing RAG systems with fixed retrieval pipelines:

The user message is used - more or less verbatim - as a search query (often vector search).

Chunks are pulled from a database once.

Retrieved chunks are combined with the user message in the prompt and fed to the LLM.

RAG uses a fixed retrieval pipeline before the LLM answers

This design is straightforward and still works for narrow Q&A. But it also breaks in predictable ways because you retrieve exactly once:

You retrieve once even when the model does not need external context, and irrelevant chunks can confuse it.

You retrieve once and have no option to correct the query. What if the returned results don’t contain the relevant information and you’d need to run a second search?

You retrieve once even when the question needs multi-hop retrieval. For example, the first batch of chunks might only tell you what to search for next, but the pipeline never runs a second pass.

Agentic RAG

To overcome these limitations, we replaced the fixed pipeline with a search tool and called it “agentic RAG”, “agentic retrieval”, or “agentic search”. In this scenario, the agent decides whether to call a search tool, whether results are relevant, whether to retrieve more, and whether to rewrite the search query.

Agentic RAG exposes retrieval as a tool the agent can call

In many setups this is straightforward because you often have only one or at least a limited amount of context sources and one retrieval tool.

Context engineering

In context engineering we now have many different context sources:

Local files (e.g., your repo, scratch pads with plan.md or todo.md files, or Agent Skills) on disk,

Databases (e.g., storing large-scale enterprise data),

Web,

Long-term memory (I left this ambiguous on purpose because whether memory lives in files or a database is still debated)

Context engineering spans many context sources

And depending on the context source, we often have a native search tool:

file search for local files,

skill loading for Agent Skills,

dedicated database tools (semantic search or query execution) for databases,

web search for the web, and

memory tools for long-term memory.

Context-source-native search tools map sources to retrieval interfaces

If that’s not overwhelming enough, we now also have a tool that lets the agent run terminal commands. This tool has many different names: LangChain calls it the “shell tool”, Anthropic the “bash tool”, OpenClaw the “exec tool”. In the following, we will refer to it as the “shell tool” .

The shell tool is a versatile tool because it can interact with most context sources: It can run against local files (ls, grep), databases (CLIs, scripts, curl to HTTPS APIs), and the web (curl).

The shell tool can reach many context sources through CLIs

That’s why currently, there’s been a lot of discussion whether a shell tool is all an agent needs. If you’re interested in a deep dive into this discussion, I’ve written about it in this blog titled “The shell tool is not a silver bullet for context engineering”. The TLDR of that blog and the core topic of this workshop is that the practical question is which search tools belong in your stack , not shell tool versus all others.

If you take away one thing from this workshop, let it be this:

Doing good search is difficult. That is why we have so many different search...