Interfaces + Open Design / Foundation

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.

AI-native interfaces are control surfaces for intent, artifacts, context, preview, inspection, and iteration.

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.

01Intent
02Canvas
03Artifact
04Preview
05Feedback
06Iteration

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 interfaces + open design 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

Intent

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 "Intent" 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

Canvas

Use "Canvas" to locate the part of the interfaces + open design workflow 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

Artifact

Turn "Artifact" into the reusable artifact for this lesson: A UI critique sheet for judging whether an AI interface improves control. This is where watching becomes something you can inspect and reuse.

04

Preview

Use "Preview" 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

Feedback

Use "Feedback" 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

Iteration

Use "Iteration" to carry the idea forward: save the prompt, checklist, diagram, or operating rule that would make the next agent run better.

Example

Source-backed work packet

Convert the video into a scoped task that includes the transcript claim, target workflow, acceptance criteria, and proof. The output should be a ui critique sheet for judging whether an ai interface improves control..

Example

Claim vs. demo brief

Separate what the speaker claims, what the demo actually proves, and what still needs outside verification before you adopt the workflow.

Example

Teach-back module

Transform the lesson into a definition, a mechanism 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.
  • Letting the prompt drift into generic advice that could apply to any video in the playlist.
  • Copying the tool setup without identifying the operating principle that transfers to your own stack.
  • Skipping the artifact, which means the learning never becomes operational or inspectable.

Transcript-derived moments

Use timestamps to study the actual video.

Quality check

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 Intent -> Canvas -> Artifact -> Preview -> Feedback -> Iteration sequence and name the weakest link.

04

Produce the artifact and include the evidence that proves it: A UI critique sheet for judging whether an AI interface improves control.

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..."

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, what the demo proves, confidence, and what still needs verification.
3. Extract the actual teachable claims from the video. Do not invent claims that are not supported by the title, lesson frame, or transcript anchors.
4. Build a reusable learning artifact: A UI critique sheet for judging whether an AI interface improves control.
5. Include:
   - a plain-English definition of the core idea
   - a diagram or structured model using this sequence: Intent -> Canvas -> Artifact -> Preview -> Feedback -> Iteration
   - 3 concrete examples that apply the video idea to real agentic work
   - 2 failure modes the video helps prevent
   - a checklist I can use the next time I run Codex or Claude
   - one practical exercise with a clear done signal
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.
- Prefer operational examples, failure modes, and reusable artifacts over broad definitions.
- Call out uncertainty instead of smoothing over weak evidence.
- If evidence is weak, 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 ui critique sheet for judging whether an ai interface improves control..

A reusable artifact with a done signal and one verification step.
03

Teach-back card

Explain the lesson 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.

ReadingOpen Design Repogithub.com/open-design-dev/open-designReadingReact Docsreact.dev/