Live Steering & Follow-ups
Follow-ups now wake a waiting Orchestrator immediately, so it can act on your request while sub-agents are still running.
How live steering worksA research workspace for the Web and your documents. Coordinate agents, follow original sources, and turn research methods into reusable skills.
SearchOS maintains tasks, evidence, coverage, and research methods as persistent system state. Agents can continue from known facts, inspect unresolved questions, and reuse source access methods across Web and local research.
Web and Hybrid research use an Orchestrator to plan and dispatch work against SOCM snapshots. Local questions use a document QA agent directly. Composable middleware manages context, evidence intake, budgets, and progress around agent execution.
A query q decomposes into a chain of sub-question nodes; each table Tm (an entity×attribute coverage grid) frames the nodes it grounds. Two shapes recur: tables partition the chain to cover breadth, or tables overlap so that the node(s) framed by all of them form the answer set satisfying every constraint.
E* (the intersection).A worked case: q = “Compare leading 2025 LLMs — context window, price, benchmark”. Swimlanes per agent, time flows left→right. Solid arrows = dispatch / trigger (control); dashed arrows = return result.
explore_agent — Disambiguation / candidate enumerationsearch_agent — Web or local evidence collectionwriter_agent — Optional structured draftingThe Orchestrator normally produces the final answer. Local mode uses a dedicated document QA flow.
./install.sh
source .venv/bin/activate
python -m pip install -e ".[local-docs]"
searchos --setup
./web/start.sh
Turn papers, reports, spreadsheets, and images into a knowledge library. Ask about selected documents or the whole library, then follow each citation back to the original material.
Read the workflow guideImport files, browse topics in a list or graph, and edit document names and topic memberships.
Use Local for your files. Choose Hybrid when the question also calls for Web research.
Inspect cited passages, pages, slides, or table regions, and keep useful sources for future questions.
Follow-ups now wake a waiting Orchestrator immediately, so it can act on your request while sub-agents are still running.
How live steering worksCreate and update skills from tasks and traces, then export SKILL.md packages and CLI scripts for reuse in compatible harnesses.
Context management, evidence extraction, and budget and progress checks can now be assembled as independent components for each agent.
Component guideOrganize documents and saved Web sources by topic, browse them in list or graph views, and choose files or a whole library for research.
Knowledge library guideSource reading extends to images and scanned documents, with citations tied to the relevant page or region.
Document parsing and citationsHybrid builds on Local Search to combine document reading and Web retrieval in one research workflow, with an explicit local source scope.
Watch Local SearchParallel research, shared evidence, and structured answers.
Follow the Web research workflow: connect providers, build a schema, inspect evidence, and export results. Available in English and Chinese.
How SearchOS’s five layers couple and collaborate — control, data, state, signal, and skill flow.
Click a legend button to isolate a flow type; hover a component to trace its connections.
Three parts make the diagram work: the agents that decide, the state they share, and the middleware that runs around every step.
For Web and Hybrid research, the Orchestrator plans work, dispatches source-specific tasks, and produces the final answer from shared evidence. Local mode uses a document QA agent directly.
When a question is vague, it does a quick reconnaissance pass — what's out there, which entities exist, where the ambiguities are — so the Orchestrator can draft a sensible plan. It writes no answer.
Given a research question or missing facts, each agent searches and reads within its assigned source scope. Web and local agents can work in parallel on independent parts of a Hybrid task.
exec. Local tasks use local_catalog, local_find, and local_open. Source middleware passes actual reading windows to evidence extraction.When enabled, the Writer uses collected evidence to draft a report section by section, with source citations. It is an optional delivery path; the Orchestrator normally writes the final answer.
write_section, read_coverage, and read_evidence. Its tool scope is drafting from collected evidence.The Orchestrator coordinates the research — it reads current state and decides what to dispatch, continue, or stop. Each sub-agent has its own execution context while committed findings remain available through shared state. Tap a card for the real tools & triggers.
The shared memory. Everything the agents learn is folded into four living objects — not a growing chat log.
A priority queue of search tasks. Each task moves pending → running → done (or blocked / cancelled), so the system always knows what's left to explore.
FrontierMemory of FrontierTask. Orchestrator pushes via enqueue_tasks; the Scheduler dispatches, unblocks, and reaps.Committed findings retain their sources and supporting passages. Evidence can come from Web pages, local documents, or saved skill results; competing values are checked before a conflict is confirmed.
EvidenceGraph. Source-specific middleware submits reading windows through ExtractionCoordinator; evidence retains its provenance.Entity × attribute tables track which questions have evidence and which need further research. New findings extend the tables without requiring agents to reconstruct them from conversation history.
CoverageMap of CoverageCell (CellStatus). Seeded by create_schema(), backfilled as evidence grows; drives gap detection and Writer structure.A record of what isn't working — repeated queries, dead-end sources — so the system stops digging in the same dry hole.
StrategyMemory (state attr strategy_log): StrategyPattern anti-patterns + FailureMemory. Feeds the Sensor layer and post-mortem distillation.All four are persisted to searchos_workspace/<session>/search_state.json with atomic file locking, so multiple sub-agents can update them in parallel without clobbering each other. Tap a card for the real class names.
Context, Sensor, and Extraction components are selected explicitly for each agent. Default pipelines supply common combinations; callers can assemble their own middleware lists.
Projects current research state into the prompt, manages reading history, and trims model input. Optional context compaction saves a continuation summary in checkpointed state.
SOCMContextMiddleware · SearchEpisodeMiddleware · DynamicTrimMiddleware · optional CompactionContextMiddleware.Tracks tool budgets, repeated queries, reading activity, and research progress. Components issue reminders or stop signals; the agent runtime applies the resulting controls.
BudgetMiddleware · QueryRepetitionMiddleware · ProgressGuardMiddleware · CoverageStallMiddleware. Mutable state is scoped to each agent.Turns actual reading windows into source-backed findings. Web, local, and final-summary intake can be selected separately, sharing an extraction coordinator when needed.
WebEvidenceMiddleware · LocalEvidenceMiddleware · optional FinalSummaryEvidenceMiddleware. Explicit extraction policies select task rows or schema-routed facts.Components share an explicit lifecycle. The runtime waits for triggered extraction before the next model step and settles remaining work on completion, failure, or cancellation. Model compatibility, telemetry, and execution control remain runtime responsibilities. Tap a card for the real class names.
Model and tool hooks apply the selected components. Source intake sends reading windows to the coordinator; the runtime owns synchronization and finalization.
Follow one question on its journey — from the moment it arrives to the finished report.md. Five milestones, one of them a loop.
A question arrives. SearchOS spins up a fresh workspace, starts with a blank slate of state, and wakes the Orchestrator — the single mind that will run the whole search.
The Orchestrator turns the question into a plan. When things are vague it sends a scout ahead first; then it draws a coverage map — a table of exactly which facts still need to be found.
The heart of it. Several search agents fan out in parallel, read pages, and evidence is captured automatically into the graph and the map. The Orchestrator checks progress and keeps dispatching — round after round — until coverage is enough.
Once the map is full enough, the writer agent reads the collected evidence and drafts the answer section by section — every claim tied back to its sources, conflicts flagged rather than hidden.
The harness assembles the final document and always guarantees a report.md — falling back through simpler synthesis modes if needed, so a session never ends empty-handed.
SearchOS-V1 results from the paper, covering Web research benchmarks.
| Benchmark | Metric | Single Agent | Multi‑Agent System | ||||
|---|---|---|---|---|---|---|---|
| ReAct | Plan‑and‑Solve | Table‑as‑Search | A‑MapReduce | Web2BigTable | Ours | ||
| WideSearch | Item · Precision | 82.9 | 83.8 | 82.4 | 83.1 | 78.3 | 83.9 |
| Item · Recall | 70.2 | 72.9 | 73.5 | 74.2 | 73.4 | 79.7 | |
| Item · F1 | 72.9 | 75.2 | 75.4 | 76.0 | 73.8 | 80.3 | |
| Row · Precision | 58.0 | 58.7 | 57.1 | 56.9 | 57.5 | 59.0 | |
| Row · Recall | 48.8 | 50.2 | 51.6 | 49.8 | 54.0 | 55.8 | |
| Row · F1 | 50.9 | 52.2 | 52.7 | 51.4 | 54.5 | 56.5 | |
| GISA | Table · Item · F1 | 74.8 | 71.2 | 73.4 | 72.5 | 68.1 | 76.9 |
| Table · Row · F1 | 58.1 | 50.7 | 54.1 | 52.1 | 45.3 | 59.7 | |
| Set · F1 | 61.6 | 63.1 | 60.9 | 62.5 | 56.7 | 76.5 | |
| List · F1 | 67.1 | 53.8 | 54.2 | 57.4 | 65.5 | 68.1 | |
| Item · EM | 0.0 | 16.7 | 16.7 | 33.3 | 50.0 | 50.0 | |
Walkthroughs and real runs — more demos landing soon.
@article{zhang2026searchos,
title={SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration},
author={Zhang, Yuyao and Gao, Junjie and Wu, Zhengxian and Fan, Jiaming and Zhang, Jin and Ma, Shihan and Yao, Yao and Qi, Weiran and Jin, Chuyan and Ma, Guiyu and others},
journal={arXiv preprint arXiv:2607.15257},
year={2026}
}