Search-and-Run Pattern

How the Search-and-Run Pattern Works

The search-and-run pattern splits agent tool use into two stages: first, the agent searches for relevant capabilities, then it executes only a small, filtered set. That keeps the active context smaller and makes the toolchain easier to reason about during runtime.

This is different from preloading every available tool into the prompt. Instead of assuming the agent should consider the full capability set on every turn, the pattern treats tool discovery as a separate step and narrows the decision space before action.

Why It Improves Agent Control

The main value is control. When only a short list of candidate tools reaches the execution stage, it is easier to understand why the agent chose a tool, what alternatives were considered, and whether the chosen path matches policy or intent.

That reduction in context also lowers the chance that rarely used or sensitive capabilities will be invoked by default. In practice, the pattern helps teams separate broad discoverability from actual permission to act, which is a useful distinction in governed agent environments.

Where It Fits in Agent Design

Search-and-run is most useful when the tool catalog is large, capabilities change often, or the agent must operate with narrow task scopes. It works well when the system can search by function, metadata, policy tags, or semantic match before the execution step.

The pattern is especially helpful when teams want an agent to stay adaptable without turning the prompt into a permanent inventory of everything it could do. Used well, it becomes a design choice for capability routing, not just a prompt-optimization trick.

Common Failure Modes

The pattern can fail if search is too broad, too shallow, or too permissive. If the search stage returns weak candidates, the agent may still drift into the wrong action path, only with a false sense of discipline because the final list looked “filtered.”

It can also hide important capabilities from review if search criteria are poorly governed. When the search layer becomes the real decision-maker, teams need to ensure that selection rules, ranking signals, and exclusions are deliberate rather than accidental.

Risk and Threat Considerations

Search-and-run can reduce exposure, but it also creates a new control point: if search is manipulated, the agent may be shown the wrong tools or miss the right ones. That makes the discovery step part of the trust boundary, not just a convenience layer.

Failure mechanism: An attacker, poisoned index, or malformed tool description can bias search toward unsafe capabilities, obscure safer ones, or cause the agent to execute a tool that was never meant to be in the candidate set.

Impact: The result can be unauthorized actions, capability misuse, policy bypass, or harder-to-detect abuse because the agent appears to have followed a normal search-and-selection flow.

Practitioner Guidance

Why practitioners should care: Treat the search stage as a governed control surface, not a neutral pre-step. The quality of the candidate set determines whether the agent’s later action is explainable, constrained, and aligned with policy.

What to watch for: Review whether search results are stable, scoped, and auditable enough to support safe tool execution. If the candidate set changes unpredictably, the pattern can become harder to govern than a smaller static tool list.

Related resources from NHI Mgmt Group

• How should security teams eliminate DLL search-order hijacking in Windows services that run with elevated privileges?
• Why does DLL search-order hijacking create such serious risk in services that run as SYSTEM?
• Search Pattern
• How should security teams run access reviews for non-human identities?