Why Search Agents Need an Operating System: Inside the Open-Source SearchOS Framework

Background and Motivation

Using agents to browse the web for information is no longer novel. Over the past year, the capabilities of search agents have improved mainly through reinforcement learning that teaches models when to search, how to construct queries, how to invoke tools, and how to continue reasoning based on page content. However, these advances do not automatically solve systemic problems in long‑running tasks, where agents must discover hundreds of entities, fill many attributes, and verify facts across multiple sources. Limited context windows cause loss of confirmed facts, duplicate queries, inconsistent field interpretations, and difficulty tracking progress.

SearchOS Idea

SearchOS answers the question “how can a search agent stay long‑running, non‑redundant, and memory‑aware?” by turning the search state into a schedulable infrastructure. The authors propose a system‑level multi‑agent collaboration framework that externalizes search state from the dialogue history.

Method: Relational Search Schema

Inspired by relational database design, SearchOS redefines open‑domain information retrieval. Given a natural‑language request q, the system first creates a relational search schema where T_m defines the table schema, A_m lists columns to fill, P_m is the primary key distinguishing rows, and R captures relationships between tables. The schema structures the information to be collected, using primary keys to identify entities and foreign keys to link different object types. Simple tasks may need only a few rows; complex tasks can involve multiple tables linked by keys.

1. Search‑Oriented Context Management (SOCM)

The core judgment is that search state should exist in the system rather than in dialogue history. SOCM maintains a single retrieval task as four continuously evolving shared states:

Frontier Tasks : prioritized and dependency‑aware todo list indicating which tasks are running, waiting, or completed.

Evidence Graph : records findings, sources, confidence scores, and relationships among pieces of evidence.

Coverage Map : real‑time completeness of the relational schema, showing which entities, attributes, or cross‑table dependencies are still missing.

Failure Memory : logs invalid queries, inaccessible sources, and missing capabilities to prevent agents from repeating the same failure paths.

This mechanism acts as a shared progress board for all agents, indicating responsibilities, collected information, and dead‑end routes.

2. Pipeline Parallel Scheduling

With SOCM, SearchOS adopts the common orchestrator‑sub‑agent architecture. A long‑lived Orchestrator plans, schedules, and converges work. In the Explore phase it understands the problem, discovers candidate entities, builds the relational schema, and splits unfilled entities/attributes into tasks dispatched to short‑lived Search Agents.

Two AI‑infra scheduling ideas are used: (a) pipeline parallelism, where different frequency agents occupy different pipeline stages simultaneously; and (b) continuous dispatch, where a finished request immediately frees a slot for the next task instead of waiting for an entire batch. Each search sub‑task is treated as a micro‑batch; the search → open → find flow forms a pipeline. Faster agents free slots that are instantly refilled with new schema gaps, overlapping stages and avoiding bottlenecks, thereby improving slot utilization, overall throughput, and wall‑clock efficiency.

3. Search Tool Middleware Harness

Long‑running searches encounter lost task state, ignored constraints, tool errors, invalid outputs, loops, and budget limits. To keep control logic out of individual agents, SearchOS inserts a middleware layer between models and tools, consisting of:

Context Middleware : injects relevant state on demand and controls context size.

Sensor Middleware : detects loops, duplicate queries, and stagnation.

Evidence Extraction Middleware : performs structured extraction, unit normalization, citation anchoring, and evidence storage.

Thus each search agent handles only a local sub‑task, while state governance, evidence handling, and exception intervention are performed centrally.

4. Hierarchical Skill Library

SearchOS builds a hierarchical skill set for agents, categorised as orchestration, strategy, and access skills. The first open‑source release ships roughly 280 predefined skills. Strategy skills encode “how to search” methods such as ranking retrieval, multi‑hop search, and entity disambiguation. Access skills address “how to access” challenges like anti‑scraping, login walls, dynamic pages, and deep directory traversal. Skills can be routed and reused per task, evolve from successful or failed search traces, and run in isolated processes.

Experimental Evaluation

SearchOS was evaluated on two open‑domain retrieval benchmarks. WideSearch contains 200 handcrafted questions (100 Chinese, 100 English) across 15+ domains, requiring a verifiable complete table as answer. GISA includes 373 realistic retrieval questions with answer formats covering items, sets, lists, and tables, emphasizing comprehensive open‑world collection.

According to the reported max@3 results, SearchOS outperformed single‑agent and multi‑agent baselines on all F1 metrics: WideSearch Item F1 = 80.3, Row F1 = 56.5; GISA Table Item F1 = 76.9, Set F1 = 76.5. On the Set F1 metric, SearchOS led the second‑best baseline by 13.4 points, mainly due to the Coverage Map‑driven continual gap filling.

Additional experiments on 40 multi‑table questions showed that even when an oracle schema was provided, SearchOS still achieved higher Item F1 (‑8.2) and Row F1 (‑7.7) than the oracle, confirming the benefit of dynamically creating table structures as entities are discovered.

The pipeline‑parallel continuous‑dispatch mechanism significantly increased throughput, reduced model calls and runtime, and improved effectiveness. Case studies demonstrated that the Sensor middleware could intervene when search stalled at early, middle, or late stages, steering agents toward successful completion.

Pre‑built skills further shortened runtime and markedly lowered the number of Search and Jina API calls, reducing the cost of a single search task.

Conclusion

SearchOS does not aim to redesign a single search agent or algorithm; instead it tackles the more fundamental problem of what shared state agents should maintain and how the system should schedule, supervise, and converge them when search becomes a long‑running, multi‑role, evidence‑traceable task. The framework provides CLI, full‑screen TUI, and web workbench interfaces, supports multiple model providers and local deployment, and offers a configuration wizard for first‑time setup.

For use cases such as competitive research, product comparison, exhaustive enumeration, multi‑hop verification, or any consulting, investment‑research, BD, or academic investigation that requires “find everything with provenance,” the authors recommend trying the framework.