Agentic Search for Context Engineering — Leonie Monigatti, Elastic
Leonie Monigatti of Elastic argues that context engineering is roughly 80% agentic search — the search tools that decide what moves from context sources into the LLM's context window — and walks through choosing among semantic search, general-purpose query tools, and the shell/bash tool, plus why tool descriptions and parameter complexity make or break reliability.
AI Engineer63 minTranscript found
Quick learning frame
Read this before watching.
A context/search lesson is about getting the right evidence into the agent at the right time through indexes, search, memory, or knowledge graphs.
New playlist item from AI Engineer; queued for transcript-backed review, topic mapping, and a practical learning artifact.
Skill you build: The ability to curate the right stack of search tools for an agent and write tool descriptions and parameters that reliably get the agent to call the correct retrieval tool with the correct arguments.
Watch for the shift from claim to mechanism. The learning value is the point where the transcript reveals a repeatable action, tool boundary, context move, review habit, or artifact.
Concept diagram
Where this video fits.
01Work question
02Source inventory
03Index/search layer
04Retrieval rule
05Agent context
06Answer/proof
07Maintenance
Deep lesson
Turn this video into working knowledge.
8,373 cleaned transcript words reviewed across 2,489 timed caption segments.
Thesis
Agentic Search for Context Engineering — Leonie Monigatti, Elastic teaches a practical context/search move: Leonie Monigatti of Elastic argues that context engineering is roughly 80% agentic search — the search tools that decide what moves from context sources into the LLM's context window — and walks through choosing among semantic search, general-purpose query tools, and the shell/bash tool, plus why tool descriptions and parameter complexity make or break reliability.
The goal is not to remember the video. The goal is to extract the operating principle, tie it to timestamped evidence, test how far the claim transfers, and make something reusable.
1:16
Search is context engineering
“alternative to this one before. This is essentially what context engineering looks like. So context engineering when we talk about it is the art or engineering techniques about how from all of the possible context sources we have,...”
Context engineering is about deciding what goes from many context sources — local files, scratchpads, databases, the web, long-term memory — into the context window, and the arrow that powers that is the search tool. Leonie's hot take is that context engineering is roughly 80% agentic search because that search box is what actually curates the window. Draw your own agent's context sources and, for each, name the specific search tool (file search, semantic search, web search, memory tool, shell) that pulls context from it.
16:34
Descriptions and parameters
“Then we're defining a very simple system prompt. So the usual you are a search agent tasked with answering questions. Um you have access to different context retrieval tools and before answering a question oops decide whether or...”
Agentic search breaks in predictable ways: the agent calls no tool, calls the wrong tool, or generates wrong parameters. The fix is treating the tool description as most important — adding trigger conditions, when-not-to-use, and relationships — and remembering that parameter complexity (a simple get-customer-by-ID versus writing a full ESQL/SQL query from scratch) is itself a failure mode. Take one thin one-sentence tool description and rewrite it with a core purpose, explicit trigger conditions, when-not-to-use guidance, and any ordering relationships to other tools.
53:46
General-purpose first
“building the the demo. Um but then when the agent now runs in the next issue, then you start adding the next piece of documentation. then you can kind of start writing the entire ESQL documentmentation from scratch...”
Start with general-purpose tools like the shell/bash tool when you don't yet know your users' behavior, then log where it breaks and add purpose-built interfaces for those cases. In Vercel's 'is bash all you need' experiment, a hybrid agent that used the database tool and then verified results with the shell tool achieved the highest accuracy. Give a test agent only a shell/bash tool for a real task, log the queries where it fails, and list which of those failures justify building a dedicated purpose-built tool.
01
Work question
Start with this video's job: Leonie Monigatti of Elastic argues that context engineering is roughly 80% agentic search — the search tools that decide what moves from context sources into the LLM's context window — and walks through choosing among semantic search, general-purpose query tools, and the shell/bash tool, plus why tool descriptions and parameter complexity make or break reliability. Treat "Work question" as the outcome you are trying to make visible, not a topic label. Anchor it to 1:16, where the video says: “alternative to this one before. This is essentially what context engineering looks like. So context engineering when we talk about it is the art or engineering techniques about how from all of the possible context sources we have,...”
02
Source inventory
Use "Source inventory" to locate the part of the context/search mechanism the video is demonstrating. Ask what changes in your real setup if this claim is true. Anchor it to 16:34, where the video says: “Then we're defining a very simple system prompt. So the usual you are a search agent tasked with answering questions. Um you have access to different context retrieval tools and before answering a question oops decide whether or...”
03
Index/search layer
Turn "Index/search layer" into the reusable artifact for this lesson: A context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff. This is where watching becomes something you can inspect and reuse.
04
Retrieval rule
Use "Retrieval rule" as the application surface. Decide whether the idea touches a browser flow, a local file, a model choice, a source document, a UI, or a review step.
05
Agent context
Use "Agent context" to prove the lesson. The evidence should connect back to the video title, transcript anchors, and a concrete output, not a generic best-practice claim.
06
Answer/proof
Use "Answer/proof" to carry the idea forward: save the prompt, checklist, diagram, or operating rule that would make the next agent run better.
07
Maintenance
Connect "Maintenance" to Agentic Search for Context Engineering — Leonie Monigatti, Elastic by naming the claim, the evidence, and the artifact it should produce.
Example
Source-backed artifact packet
Convert the video into a scoped artifact request that includes the transcript claim, mechanism, acceptance criteria, and proof. The output should be a context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff..
Example
Context/search proof brief
Separate what the speaker claims, what the demo actually proves, and what still needs outside verification before you adopt the context/search pattern.
Example
Teach-back module
Transform the lesson into a definition, a Work question -> Source inventory -> Index/search layer -> Retrieval rule -> Agent context -> Answer/proof -> Maintenance diagram, one misconception, one practice exercise, and a check-for-understanding question.
Do not learn it wrong
Treating the title as the lesson without checking what the transcript actually says.
dumping all context
stale memory
retrieval with no proof trail
Letting the lesson drift into generic context-window advice.
Letting the lesson drift into memory hype without retrieval rules.
Letting the lesson drift into source claims without freshness checks.
Do not count this as learned until these are true.
01
State the transcript-backed claim in your own words: Leonie Monigatti of Elastic argues that context engineering is roughly 80% agentic search — the search tools that decide what moves from context sources into the LLM's context window — and walks through choosing among semantic search, general-purpose query tools, and the shell/bash tool, plus why tool descriptions and parameter complexity make or break reliability.
02
Explain the practical stakes without hype: New playlist item from AI Engineer; queued for transcript-backed review, topic mapping, and a practical learning artifact.
03
Map the idea onto the Work question -> Source inventory -> Index/search layer -> Retrieval rule -> Agent context -> Answer/proof -> Maintenance sequence and name the weakest link.
04
Produce the artifact and include the evidence that proves it: A context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff.
Put it into practice
Give this grounded prompt to Codex or Claude after watching.
You are helping me turn one specific YouTube video into real, durable learning.
Source video:
- Title: Agentic Search for Context Engineering — Leonie Monigatti, Elastic
- URL: https://www.youtube.com/watch?v=ynJyIKwjonM
- Topic: Interfaces + Open Design
- My current learning frame: Build a small agentic search agent over a local dataset with one semantic search tool, deliberately break it with an out-of-database question, then add a shell tool and compare which queries each tool handles best.
- Why this matters: New playlist item from AI Engineer; queued for transcript-backed review, topic mapping, and a practical learning artifact.
Transcript anchors from this exact video:
- 1:16 / Evidence 1: "alternative to this one before. This is essentially what context engineering looks like. So context engineering when we talk about it is the art or engineering techniques about how from all of the possible context sources we have,..."
- 4:34 / Evidence 2: "context lies in many different places, right? So, we have context sources in local files. So when you think about your coding agent, you probably have your um coding project in or code files laying around in your..."
- 16:34 / Evidence 3: "Then we're defining a very simple system prompt. So the usual you are a search agent tasked with answering questions. Um you have access to different context retrieval tools and before answering a question oops decide whether or..."
- 28:17 / Evidence 4: "give it a little bit more help on how to write better um parameters. I could re reinforce it in the system prompt, give it more instructions there. Or I could use an agent skill because you need..."
- 36:21 / Evidence 5: "instead of explaining how the data is structured in elastic search, I'm explaining how the data is structured in my local file system. Okay, so let's use the shell tool. I have to give you a disclaimer. Using..."
- 53:46 / Evidence 6: "building the the demo. Um but then when the agent now runs in the next issue, then you start adding the next piece of documentation. then you can kind of start writing the entire ESQL documentmentation from scratch..."
- 59:22 / Evidence 7: "tell you that I know for example I believe in cloud code they're using sub aents for doing specific search tasks. I think there was a blog post on how they're actually using a sub agent to um..."
Video-aware target:
- Prompt lane: Context/search
- Mechanism to extract: Extract how context is found, filtered, refreshed, and handed to the agent before it acts.
- Artifact to produce: A context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff.
- Artifact must include: source inventory; index/search layer; query rule; freshness check; agent handoff; proof behavior
Your task:
1. Use the transcript anchors above as the primary source packet. If you add outside context, label it clearly as outside context and keep it secondary.
2. Create a source-check table with columns: timestamp, claim, transcript support, what the demo proves, confidence, and what still needs verification.
3. Extract the actual teachable mechanism from the video: Extract how context is found, filtered, refreshed, and handed to the agent before it acts. Do not invent claims that are not supported by the title, lesson frame, or transcript anchors.
4. Build a reusable learning artifact: A context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff.
5. Include:
- a plain-English definition of the core idea
- a diagram or structured model using this sequence: Work question -> Source inventory -> Index/search layer -> Retrieval rule -> Agent context -> Answer/proof -> Maintenance
- answers to these source questions: What source is searched or indexed? | What query/retrieval rule is demonstrated? | How does the agent use the retrieved context?
- 3 concrete examples that apply the video idea to real agentic work, such as codebase memory; personal wiki retrieval; Elastic search context engineering
- 2 failure modes the video helps prevent, chosen from the transcript evidence and these likely risks: dumping all context; stale memory; retrieval with no proof trail
- a checklist for the next real workflow, focused on: sources, query, freshness, handoff, citation/proof
- one practical exercise with a clear done signal: Write three retrieval queries for one real project and define what each must return.
6. Add a "learning transfer" section: what changes in my workflow tomorrow if I actually learned this?
7. Add a "source check" section that cites which transcript anchor supports each major takeaway.
Quality bar:
- Make this specific to "Agentic Search for Context Engineering — Leonie Monigatti, Elastic", not a generic Interfaces + Open Design essay.
- Cite the transcript wherever the prompt names a task boundary, review habit, context move, or verification standard.
- Prefer operational examples, failure modes, and reusable artifacts over broad definitions.
- Call out uncertainty instead of smoothing over weak evidence.
- Avoid these generic drifts: generic context-window advice; memory hype without retrieval rules; source claims without freshness checks.
- If evidence is weak or missing, stop and say what transcript segment or timestamp needs review instead of guessing.
- Finish with a concise artifact I could paste into my learning app.
Misconceptions
What to stop believing.
A beautiful page is automatically a good learning tool.
Learning requires sequence, active recall, feedback, and application.
Generated UI should be accepted as-is.
Generated UI needs critique, revision, and browser verification.
Practice studio
Learning only counts when you make something.
01
Transcript evidence map
Separate what the video actually says from what you already believe about the topic.
3 source-backed takeaways with timestamps, confidence, and a transfer note.02
One useful artifact
Apply the video to a real workflow and produce a context retrieval map with source inventory, indexing/search path, query rules, freshness checks, and agent handoff..
A reusable artifact with a done signal and one verification step.03
Context/search teach-back card
Explain the context/search mechanism to someone who has not watched the video yet.
A 90-second explanation, one diagram, one example, and one misconception to avoid.
Recall check
Answer first, then reveal — without rewatching.
Why does Leonie claim context engineering is about 80% agentic search?
What are the three common ways agentic search breaks, and what is the first fix?
What tool-stack strategy does Leonie recommend when you don't yet know user behavior, and what did Vercel's experiment show?
Source shelf
Use the video as a doorway, then verify with primary sources.
