Evidence at a glance

7 。Evidence
7 11 。Evidence
。5
Approx. , , , 。Evidence
, URL 。Evidence
or use 。Evidence

Production Search Starts by Defining Done

Two TinyFish engineering articles examine agentic search for production AI agents: systems that search the web, browse sites, collect evidence from multiple sources, and use it to produce cited reports. One lays out a search-control architecture; the other revisits design choices in a deep research system, especially around planning, context, and subtask orchestration. The goal is not simply to make a model search more often, but to make results verifiable and failures recognizable.

The articles are useful to technical leads not because they introduce another Agent label, but because they shift the question from “Can the model find an answer?” to “What lets the system decide the answer is sufficient?” Research is iterative, users ask follow-up questions, and pages may be inaccessible. Search quality therefore cannot be judged only by whether the final prose sounds convincing; it also depends on evidence coverage, source quality, and when the system chooses to stop. One caveat: the supplied source excerpt is mostly cookie text. The architectural details here come from the accompanying research material’s account of the two TinyFish articles, so the full articles and their production performance cannot be independently verified from the excerpt.

An Evidence Contract Makes Search Testable

The production-architecture article uses “evidence contract” for the requirements attached to a search task. It specifies which facts or fields are needed, what sources and freshness are acceptable, whether citations are required, what format the result should take, and which outcomes count as complete, partial, failed, or in need of human review. TinyFish says this is a working term used in the article, not an established industry standard. Its practical value is to turn “find relevant pages” into a deliverable that can be checked.

Those requirements run through a seven-phase workflow, expanded in the article into eleven actions: define the task and evidence requirements; break down information needs and dependencies; generate queries and choose an initial tool; discover, filter, and retrieve sources; assess sufficiency; retry or escalate access according to the failure; then stop and verify. The number of phases is no guarantee of quality. But the structure forces planning, retrieval, evaluation, and termination into one control flow instead of leaving citation as a final prompt instruction.

Choose Tools According to the Evidence Gap

The key is not to connect search, fetching, browsers, and Web Agents indiscriminately, but to route according to what evidence is missing. Search when the source is unknown; fetch directly when a URL is known; use a browser when page interaction or session state matters; and use a Web Agent when autonomous decisions across multiple pages are required. This makes tool use a reasoned access strategy and avoids escalating every webpage task into the heaviest Agent workflow.

After retrieval, an evaluator checks evidence coverage, source quality, freshness, and conflicts. The materials identify five assessment states: sufficient, incomplete, conflicting, inaccessible, and budget exhausted. These distinctions matter because incomplete evidence should not be presented as a definite answer, and conflicting sources should not simply be averaged away. The system should use the state to decide whether to revise a query, try another source or access method, or report that the question remains unresolved.

Removing a Separate Planner Does Not Remove Planning

TinyFish’s deep research retrospective explains why it changed the component boundary. In an early version, a separate planner generated subquestions, queries, and a research strategy for the orchestrator to execute. As research became iterative and users asked follow-up questions, the orchestrator had the conversation history, earlier reports, and intermediate findings. A newly invoked planner received only structured state and could miss important context. The problem may not have been planning capability itself, but planning and execution operating with different views of the task state.

TinyFish later moved planning into the orchestrator’s reasoning loop and stopped launching a subagent for every query. It instead used tools for deterministic sorting, classification, and evidence extraction, then returned the organized results to the orchestrator. So the production architecture’s planner responsibility does not contradict the retrospective’s removal of a planner: one describes a function the workflow needs, the other describes no longer packaging that function as a separate component. This is a trade-off about context continuity, not a general rule that fewer Agents are always better.

Bounded Retries Must Leave Room to Stop

When evidence is insufficient, the system can revise a query, change sources, or escalate the access method, but retries should target a specific failure and have a limit. The materials do not disclose the limit or provide before-and-after latency and cost figures for merging the planner or removing per-query subagents. TinyFish says the changes reduced context use, latency, and cost, but the available account supports only a qualitative report from the authors. It does not establish the size of the improvement or show that the same design suits every research task.

For teams with existing research agents, the actionable move is not to copy a component diagram. First check whether tasks have explicit evidence contracts, routing rules, failure states, and stopping conditions, and whether the system repeats retrieval or becomes overconfident when evidence is thin. Teams can compare separate planning with planning in the main loop, or subagents with deterministic tool-based organization, on their own workloads while tracking evidence coverage, latency, cost, and unresolved outcomes. Access limits, budgets, and source conflicts may still leave a task only partially complete. Production readiness does not guarantee a complete answer every time; it means the system can recognize when it cannot claim completion.