SearchOS keeps search state outside the model and agents stop looping

When a search agent starts going in circles

Web search agents all have the same old problem: the longer the task, the faster they lose track of what they have already found, what they still haven't, and where they were heading in the first place. The opening stretch looks impressive — the model searches, opens pages, writes out facts, assembles an answer. Then the familiar part begins. The same queries. The same sites. The same dead ends. The search budget burns down and the answer is still full of holes.

The authors of SearchOS are not proposing one more clever agent. They are proposing something closer to an operating system for search. The idea is simple: stop keeping the course of a search inside the conversation with the model, and move it into explicit, shared, persistent state that every agent can read. That is the paper's central bet.

Why does this matter? Because the next step for AI search is not answering a single question but assembling large, verifiable, structured answers: lists, tables, comparisons, summaries across dozens of sources. For work like that, one smart head is no longer enough. It takes coordination, memory and control.

What the authors actually propose

SearchOS treats search not as a free-flowing stream of queries but as filling in a relational schema grounded in sources. That sounds dry. In practice it is very practical.

Picture the task: compile a list of companies with their revenue, their executives, their founding date and links to the sources that confirm each one. Instead of an abstract go-find-all-of-this-online, the system builds tables made of cells. Each cell is one concrete fact that has to be filled in — and not merely filled in, but attached to a URL and to the span of text where the fact is visible.

Open-ended search becomes a task with legible progress: which rows are found, which fields are empty, where the data conflicts, and where the search has already hit a wall.

The SearchOS architecture: the orchestrator, shared search memory, subagents and the tool control layer.

SearchOS has several key parts.

But the roles are not the important part. The important part is the shared search memory, which the authors call search context management.

Memory that does not live inside the model's head

SearchOS keeps the state of a search in four explicit structures. This is arguably the paper's core idea.

This seems almost obvious: if an agent searches for a long time, its progress has to be stored somewhere. Yet plenty of current systems still lean on the dialogue history and the model's own local memory. On short tasks that is tolerable. On long ones it is not.

SearchOS has one important consequence: agents stop guessing from context and start working off a shared map of the terrain. One agent will not walk back into a place where another already found nothing. The orchestrator sees the real gaps instead of trying to reconstruct them from a long transcript.

How the control layer intervenes in a search agent's loop: it feeds in context, extracts evidence and breaks the loop when the agent starts repeating itself.

Why this needs a search OS and not just more agents

The usual multi-agent pitch is speed: run several agents in parallel. In practice that turns into chaos easily. Two agents search for the same thing. A third waits. A fourth gets stuck on a slow site and the whole batch of tasks stalls behind it.

The authors borrow an idea from training large models on GPUs: pipeline parallelism. Instead of dispatching work in batches and waiting for every participant to finish, SearchOS drops a new subtask into a slot the moment it frees up.

It is a small engineering decision with a large effect. Less idle time. More useful work per unit of time. And, crucially, the new tasks are not picked at random — they come off the map of coverage that is still missing.

The system does not simply keep idle hands busy. It aims at the actual holes in the answer.

The authors show that running this way cuts average run time by roughly a quarter, reduces the number of LLM calls, and improves the quality of the final table at the same time. This is a rare case where efficiency and quality rise together rather than trading against each other.

The most interesting layer: intercepting tools and policing behavior

Another interesting piece of the paper is the tool control layer. It is essentially a shim between the model and the search tools.

What is it for? Because you cannot count on the model to stay disciplined on its own, least of all over a long run. It can forget the budget limit, skip an important fact, repeat a useless query, or keep spinning in a loop.

This layer does three things.

This matters. Control moves out of the prompt and into the infrastructure. It is probably the paper's most useful lesson for the agent industry as a whole. Reliability is not something you ask the model for in words. It has to be built into the system.

Skills: not relearning how to search every time

SearchOS also carries a skill library. The authors split it into two levels.

This is another practical point. Real search takes more than the ability to reason. You have to know how specific places on the web are built. Where a site keeps its catalog. Where the filters are. Where structured data is easiest to pull. Procedures like these can be reused across tasks instead of being reinvented each time.

By the authors' numbers, skills buy not only quality but noticeable savings: fewer search calls, fewer pages opened, less time per session. The system wanders less.

Trajectories with the control layer intervening: once stagnation is detected, the search starts advancing coverage and finding entities again.

What the experiments show

The authors test SearchOS on two open-ended search benchmarks: WideSearch and GISA. Neither is built around short answers; both target long, structured, verifiable results.

The main metric here is not simply whether the answer is right but recall and precision over the cells and rows of the tables. That is harsher and more honest: one mistake in a row can make the whole row count as wrong.

The results look strong. SearchOS beats both single-agent systems and other multi-agent approaches. The gain in recall is the one that stands out — the ability not to miss facts that belong in the answer.

What jumps out:

Why did set-type tasks improve the most? Because there it is not enough to find a couple of correct answers — you have to assemble the complete set. A coverage map and explicit gap tracking hit exactly that target.

The authors also run a curious analysis of schemas, comparing fixed table structures against planning the schema dynamically during the search. It turns out there is no universal structure. Sometimes one table works better, sometimes several linked ones. Which is why building the schema on the fly beats committing to a format in advance.

What is genuinely new here

Strip away the implementation details and the main contribution of SearchOS fits in one line: search became a state management problem, not only a text generation problem.

That sounds simple, and it changes almost everything:

Against a field racing toward ever smarter agents, this is a fairly down-to-earth, engineering-minded turn. Which is exactly why it is convincing.

Limits and what could go wrong

For all the optimism, the approach is not free. It is more complex than a plain agent in nearly every dimension: architecture, synchronization, state tracking, update rules, conflict handling. A system like this demands good engineering and can be heavy in production.

Quality also still depends on the outside world: whether sites are reachable, how pages are structured, how well facts are extracted, how well they can be matched to the schema. If a source is closed off, broken or ambiguous, no amount of elegant architecture fully cancels that out.

There is a methodological caveat as well: the authors report the best result out of three runs. That is useful for gauging potential, but in real deployment average stability matters too.

Takeaways

Long-running web search for an agent is bottlenecked less by intelligence than by how the work is organized. Once a system explicitly stores its gaps, its evidence, its conflicts and its failures, it searches noticeably more reliably.

The paper's main idea — move the state of the search out of the model's head and into shared infrastructure — looks very workable. It helps on several fronts at once: recall goes up, repetition goes down, parallel work becomes meaningful, and the result becomes checkable.

For the agent market this may be one of the most useful approaches on the table right now. The next jump in quality on hard tasks may come not only from stronger LLMs but from systems that remember, coordinate and control the search process better. SearchOS is exactly that.