Agentic Search

Agentic search is search performed by an agent that decides for itself whether to search, what query to use, whether the results are good enough, and whether to search again — across several context sources, each with its own native search tool. It is the middle and current stage in a three-step evolution laid out by Leonie Monigatti in agentic-search-context-engineering.

The starting point was fixed-pipeline RAG (see rag-limitations): take the user's message, run one vector search, staple the chunks onto the prompt, generate. It works for narrow Q&A and breaks in three predictable ways, all because it retrieves exactly once — it retrieves when no retrieval was needed, it can't correct a bad query with a second pass, and it can't do multi-hop where the first results only tell you what to search for next. Agentic RAG fixes this by making retrieval a tool the agent chooses to call, re-run, or rewrite. Context engineering then generalizes it: an agent now reaches many sources — local files and scratch pads, databases, the web, long-term memory — and each has a native search tool (file search, skill loading, database query tools, web search, memory tools).

One tool cuts across most of those sources: the shell tool (LangChain's name; Anthropic calls it the bash tool, OpenClaw the exec tool). Because so much is reachable from a CLI — grep and ls for files, database CLIs and curl for services and the web — a single "run this command" tool covers a lot of ground, which is why "Bash + Filesystem is all you need" keeps getting proposed. It has a real limit at semantic search. An agent asked a conceptual question over text files will "cheat" by chaining grep for synonyms (regulat, then compliance, constraints, GDPR, governance) until something hits. That works surprisingly often but doesn't scale to open-ended meaning — asked for "movies with animal superheroes" it would have to enumerate every animal. Semantic-grep CLIs exist to close that gap: LlamaIndex's semtools, LightOn's colgrep, Jina AI's jina-grep-cli (grep-compatible flags plus cosine --threshold and --top-k).

The design question, then, isn't shell tool versus everything else. It's which search tools belong in your stack given your latency and quality requirements — a general-purpose query tool handles harder, ambiguous queries but costs more and needs a stronger model, while a narrow semantic tool is cheap but fails on keyword-exact queries. This sits inside the broader context-engineering problem, and the tension between loading capable general tools versus cheap specific ones connects to mcp-vs-skills and hybrid-search.