Agentic Search as an Agile Engineering Process

Search is usually framed as retrieval: given a query, return the most relevant documents. Today, that framing is breaking down.

Agentic search systems do more than retrieve: they plan, decompose, execute, verify, and refine. They behave less like function calls and more like software engineering teams pursuing goals under uncertainty.

Once you see this, a natural question follows: if agentic search is a form of engineering, what methodology should guide it? Agile software engineering offers a compelling answer — not just as an analogy, but as a control system.

Search as engineering without a specification

A traditional software project starts with a specification. Search does not. A query is an incomplete, often ambiguous description of a goal. The system must infer intent, explore interpretations, and iteratively construct an answer.

From this perspective:

• The query is a partial specification.
• Retrieval and reasoning comprise implementation.
• Results represent candidate solutions.
• Interaction becomes a form of evaluation.

Search is what engineering looks like when the specification is missing.

Agentic search as managing a workflow

Traditional search executes in a single pass. Agentic systems do not. Agentic search:

• Breaks problems into subtasks.
• Delegates subtasks to tools.
• Explores multiple paths.
• Refines based on intermediate results.

Agentic search no longer just executes a query. It manages a workflow. And this is a process that benefits from agile software development methods.

Iteration as uncertainty reduction

Agile development is fundamentally about reducing uncertainty through iteration. The same is true for agentic search. Each step should be evaluated not only by what it produces, but by how much uncertainty it removes relative to its cost. This reframes the agentic search process as a sequence of uncertainty-reducing experiments.

The tradeoff: scope, cost, quality

Perhaps the most important foundation of software engineering is the project management triangle: you want to optimize a project's scope, time, and quality, but you cannot achieve all three. At most, you can pick two.

In agentic search, we can translate engineering time into cost, so the tradeoff becomes:

• Scope — how much of the problem space the search covers.
• Cost — aggregate spend on tokens, tool calls, and other computation.
• Quality — a combination of correctness, completeness, and confidence.

As in software engineering, it is always possible to mitigate uncertainty by reducing scope. However, the critical constraint is likely to be cost, since projects have finite budgets. In any case, these three levers represent the tradeoff facing every agentic search workflow.

The triangle in practice

Three common strategies for managing this tradeoff:

• Treat cost and quality as fixed, and reduce scope. Take a narrow focus, only explore high-confidence paths, and stop early. The default strategy for most agentic search.
• Treat scope and quality as fixed, and increase cost. Broader exploration, aggressive verification, and conflict resolution. Agents typically call this "deep research".
• Treat scope and cost as fixed, and sacrifice quality. Skim content, summarize, accept lower confidence. Agents typically call this their "quick overview" mode.

Each strategy makes a different tradeoff and can produce dramatically different results. Unlike in most software engineering contexts, the tradeoffs can be adjusted dynamically throughout the process.

Searchers as product owners, agents as engineers

In agile software development, there are two key roles. The product owner defines and prioritizes goals. Engineers own all aspects of execution. In agentic search, the searcher is the product owner, while agents fill the roles of engineers.

However, much as can happen with software development, searchers may not know what they want until they see it. The process is iterative: requirements evolve as results come in. While iterations in software development projects are sprints measured in days, the iterations in agentic search are measured in minutes or even seconds. This makes the loop tighter, faster, and less predictable.

Task sizing: a critical challenge

A central challenge in both agile and agentic systems is decomposition. Larger tasks can increase efficiency, especially by reducing the costs and delays of interacting with the searcher / product owner, but they also increase risk. Smaller tasks reduce risk but decrease efficiency.

The optimal tradeoff balances the cost of coordination against the expected cost of errors. This determines:

• How many steps an agent takes.
• How much reasoning the agent packs into each step.
• How often the agent verifies that it is on the right path.

This is one of the most important — and underexplored — design decisions in agentic search workflows.

An uncomfortable and inconvenient truth

One of the classic frustrations with agile software development — especially for product managers — is its lack of predictability. It is impossible to know exactly when a project will finish. Agentic search inherits and amplifies this property.

The searcher does not know:

• How many steps are required.
• How many branches will be explored.
• What the key sources of uncertainty are.

However, as with software engineering, trying to force predictability leads to worse outcomes:

• Premature stopping.
• Shallow exploration.
• Lower-quality results.

Predictability is not the goal for which agentic search can or should optimize.

Replacing predictability with evaluability

Agile development replaces predictable completion with predictable progress. Agentic search takes this idea one step further: it does not define "done" upfront; instead, it detects completion using evaluation. The question is never "How many steps remain?" but "Is further work worth the cost?"

An agentic system is "done" when spending more is not expected to improve the quality of the outcome — when the expected marginal gain no longer justifies the marginal cost.

Testing is the definition of done

In software engineering, "done" is defined by passing tests. In agentic search, evaluation replaces this definition of done. What needs to be evaluated?

• Outcome — correctness, completeness, and usefulness.
• Process — validation of exploration and verification strategies.
• Efficiency — maximization of ROI, minimization of wasted effort.

While some of this evaluation can be automated, the searcher plays a critical role in evaluating outcomes.

Testing replaces explainability

People like explainability. Unfortunately, we have learned from the evolution of AI-powered search that explainability is incompatible with the modern neural methods that achieve the best performance. We have largely accepted reduced explainability in exchange for better outcomes, and that holds true for agentic search. What we need is not explainability, but the ability to test the process — to evaluate outcomes and audit processes.

Putting it all together

Agentic search brings together three interacting layers:

• An agile, iterative workflow to reduce uncertainty.
• The constraints and tradeoffs of the scope–cost–quality triangle.
• An evaluation process that establishes a definition of done.

Together, these form a control system for reasoning under uncertainty. This framing suggests concrete design principles:

• Prioritize steps that maximize uncertainty reduction per unit of spend.
• Dynamically adjust scope based on budget and confidence.
• Size tasks to balance coordination costs against expected costs of errors.
• Integrate verification into the iteration and refinement processes.
• Define and enforce evaluation-driven stopping criteria.

Final thought

The agile development methodology recognizes and accepts that we cannot predict exactly when the work will be complete. Agentic search goes further: it is not just a question of whether the process is complete, but rather whether the results are good enough and further effort does not justify the cost. This shift — from execution to evaluation — is what turns search into engineering and motivates an agile approach.