SearchOS reframes long-horizon web-search agents as filling a shared relational table with cited evidence, and moves plan, coverage, evidence, and failure logs out of chat history into system-owned state that a middleware layer updates and polices. On GISA Set questions, this lifts F1 by +13.4 points over the strongest baseline.
You’ve shipped a research-assistant agent that gathers, say, every Series-B fintech in EMEA with founders, HQ, and last raise. It spawns four sub-agents. Two hours in, one is re-Googling a company another already found. One is stuck re-opening a paywalled Bloomberg page. The final report is missing five companies and nobody knows which. Today’s fix is more scaffolding on top of ReAct or a bigger orchestrator prompt, hoping the agents remember what’s done. SearchOS argues the whole approach of keeping progress inside the conversation is the bug.
The reframe: treat the user’s request as a database-completion task. The system builds a schema of tables (entities as rows, attributes as columns), and every filled cell must carry a URL plus the exact quoted span that supports it. That gives a concrete definition of “done” and “still missing.”
Around that schema sit four externalized state objects, collectively called Search-Oriented Context Management (Search-Oriented Context Management (SOCM)): a Frontier Task queue of pending gaps with dependencies, an Evidence Graph of atomic findings with support/conflict/refine links, a Coverage Map tracking each cell’s status, and a Failure Memory recording exhausted queries and dead sources so no agent retries them. Agents never see the full state. Each role (orchestrator, explorer, searcher, writer) gets a projection filtered to what it needs.
Scheduling is continuous, not batched. Inspired by Pipeline Parallelism in GPU training, whenever a sub-agent slot frees, the orchestrator immediately refills it with the highest-priority unresolved gap, rather than waiting for a whole batch to finish.
The Search Tool Middleware Harness wraps every model and tool call. It injects the right state slice into context, extracts and anchors evidence from browser observations before committing to the graph, and runs a Sensor that watches whether coverage or evidence count grew over a window. If both are flat, it declares a stall and forces a strategy switch or stops the branch. Agents don’t have to remember to check budgets or notice they’re looping; the harness does.
while not orchestrator.done(state):
ready = frontier.ready_tasks(state)
for slot in free_slots():
task = pick_top_priority(ready)
agent = spawn(task.role, project(state, task))
obs = agent.run_with_middleware() # context+evidence+sensor
state = commit_atomic(state, obs) # evidence graph + coverage
if sensor.stalled(state) or over_budget():
harness.intervene(agent) # switch skill, drain, or stop
A library of 280 pre-built skills sits alongside, split into strategy skills (how to search, source-independent) and access skills (site-specific extractors, e.g. one for Senate.gov that ships a typed Python executor).
The prevailing multi-agent recipe is: give each worker a role prompt, let them chat, hope the shared history preserves what’s been found. This paper shows the opposite. Search state, coverage, evidence provenance, and failed attempts belong to the system, not to any conversation, and safeguards belong in middleware, not in prompts. The evidence that carries the thesis is not the headline F1 win but the ablations: continuous dispatch, the skill layer, and the schema-planning study each move numbers independently, showing the state layer is doing the work rather than a stronger base model or better prompts.
The most load-bearing result is the scheduling ablation. Swapping only the scheduling policy (batched vs. continuous) on the same queries and concurrency cap of 8 workers, continuous dispatch cut end-to-end time by 24.3%, used fewer LLM calls, and still improved Item F1. That isolates pipeline-parallel refill as the source of efficiency, not the base model.
•
On WideSearch, 80.3 Item F1 and 56.5 Row F1, both best in table, with gains concentrated in recall as the coverage-driven design predicts.
•
On GISA, best F1 on every question type. The largest gap is Set questions (76.5 vs. 63.1, +13.4), which is exactly where enumerating a complete answer set benefits from an explicit Coverage Map.
•
Turning off the hierarchical skill library drops Row F1 by 3.4 points and simultaneously raises session time by 36.6%, search calls by 39.1%, page fetches by 42.7%. Skills buy quality and efficiency together.
•
On 40 tasks with hand-built fixed schemas, letting SearchOS plan the schema at search time beats even an oracle that picks the better fixed schema per case by 8.2 Item F1.
Reach for this pattern when you’re building a broad-collection agent, e.g. “list every X with attributes Y, Z, W and cite each.” Instead of one big prompt-chain, define a small relational schema up front, keep a Coverage Map and Evidence Graph in a database your workers read/write through a middleware, and have the orchestrator dispatch the next-highest-priority missing cell whenever a worker frees. Add a stall detector that fires on flat coverage over a window and forces the agent to change source or skill rather than retry the same query.
The paper evaluates on WideSearch (200 curated broad-collection queries) and GISA (373 queries scored in item/set/list/table formats), both of which are useful if you want to benchmark similar systems. The backbone is GLM-5 for agent roles and Qwen3.5-35B-A3B for evidence extraction. The paper doesn’t mention a code release or link to a repository.
Put the agent’s memory in the database, not the conversation. Progress, evidence, and failures are system state that middleware should maintain and enforce. Prompts are the wrong place to hold long-horizon truth.
•
The results use strong Chinese-lab backbones (GLM-5 plus a Qwen extractor) and a hand-curated library of 280 skills including bespoke site executors. How much of the win survives with a weaker base model and no skill library is not directly measured; the skill ablation removes all layers together.
•
Both benchmarks target broad-collection tasks that map naturally onto tables. For open-ended synthesis, comparison essays, or tasks without a clean schema, the reframing may not fit, and the paper doesn’t test that setting.
•
Scores are reported as Max@3 (best of three runs) scaled by 100. That inflates apparent reliability relative to a single-shot deployment where you don’t get to pick the best trajectory.